Design of intuitive interfaces

[Steven Schveighoffer]

On Mon, 22 Feb 2010 08:24:18 -0500, Lars T. Kyllingstad  
<public at kyllingen.nospamnet> wrote:

> Steven Schveighoffer wrote:
>> On Sun, 21 Feb 2010 16:21:29 -0500, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Walter Bright wrote:
>>>> Michel Fortin wrote:
>>>>> On 2010-02-21 02:15:23 -0500, Norbert Nemec  
>>>>> <Norbert at Nemec-online.de> said:
>>>>>> similarly, I would suggest
>>>>>>
>>>>>> "reverse" to sort in-place
>>>>>> "reversed" to return a modified copy
>>>>>
>>>>> I that's a not so bad solution, applicable to almost any word. There  
>>>>> are cases where it doesn't work ('split'), but probably not too much.
>>>>  "split" - to split in place
>>>> "splat" - to return a modified copy
>>>
>>> Just to clarify: there is some point being missed here. It's not about  
>>> in-place vs. copy. Please check retro's documentation.
>>  By copy he means it doesn't affect the original.  Retro returns a  
>> "virtual" copy :)
>
> But it's a valid point.  There are three degrees of freedom here, which  
> ideally should be reflected in the API: in-place, copy and view (or  
> virtual copy if you like).

As far as English terms go, how do you distinguish between a lazy and  
eager copy?  There are actually even more subtle possibilities.  For  
example, split could return an array of slices -- which is not a copy of  
the data, but is a unique copy of the split points.  I think it's not  
possible to have a rule to encompass all possibilities, but a rule to  
cover 80% of the most useful representations is good enough.

Also, I would think one would prefer a view whenever possible, because you  
can always make a hard copy from the view, but you can't do it the other  
way around.

-Steve