opDollar

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Fri, Sep 12, 2008 at 11:10 AM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>> "Bill Baxter" wrote
>>> On Fri, Sep 12, 2008 at 2:28 AM, Steven Schveighoffer
>>>> For example, if you wanted to 'slice' an AA, you would use 2 keys for 
>>>> the
>>>> slice 'indexes', what if the keys are strings?
>>>
>>> I'd say opSize, ala STL.  They got it right.  Should .size for arrays
>>> too, not .length.  "Size" is a word that generalizes pretty well,
>>> "length" is not.
>>
>> size doesn't work for slices that don't use sequential integers as index.
>> i.e. imagine a sorted map (such as tree map) slice:
>>
>> TreeMap!(char[], char[]) tm;
>>
>> // create a slice of the treemap
>>
>> auto slice = tm["one".."two"];
>>
>> Replace the second with 'length' or 'size', and it looks weird:
>>
>> auto slice = tm["one"..length]
>> auto slice = tm["one"..size]
>>
>> I much prefer 'end' or 'last'.  It reads natural.  From the "one" element 
>> to
>> the end.
>
> Ok, so you want to change the meaning of $ altogether from being a
> number to something container dependent?
>
> I guess that may generalize better...  But then shouldn't it evaluate
> to an iterator?  Argh! :-)

I think it should evaluate to the same type as you would specify as the 
first argument to the slice.  If that happens to be an integer, it's an 
integer, if it happens to be a string, it should be a string :)  If 
iterators are supported for a given container, it makes logical sense that 
slicing based on iterators should be supported.  I support slicing based on 
'cursors,' which are basically iterators, in dcollections (well, only for 
ArrayList now, but I plan to do it for LinkedList and the tree types).

opLength/opSize implies that it should ALWAYS be an integer.  'sall I'm 
sayin.

-Steve