Renaming newEmpty/newSize: to new &capacity:

[Shaping]

 Capacity refers to a "hint" to the
> collection that it needs space for so-and-so many elements. The collection can 
> ignore it at will,

Why would it do so?  I would think that the collection would remember it, and 
refer to it before growing.

 which is what makes it a perfect
> candidate for optional parameters, and capacity is already a distinct variable 
> from size. A collection's size is the number of elements it contains. A 
> collection's capacity is the number it /can/ contain without growing (for 
> trees, it is LargeUnbounded, for obvious reasons).

Then capacity and size are distinct ideas.  The one does not replace the other, 
as I thought you were suggesting.  I did not understand your original statement 
below.  You seem to be developing two distinct protocols.  If that is so, then 
the choice is good.

>
> We have a unit library (src/lib/dimensioned.slate) which will not be used for 
> something this basic. "Units" are just indexable slots in this case. 
> #sizeInBytes just shows that you are thinking at totally the wrong abstraction 
> level.

The example was given to demonstate a more specific mode of counting, the form 
of measurement.

Is your capacity protocol only quantic (Integer-based)?  Will it be extented to 
continuous ideas (namely Floats)?  Slots are always counted, of course.  But the 
idea may be more flexible, without creating comprehension problems.


Shaping

>
>> #capacity is too abstract.  #newSize: and #size are correct in the general 
>> sense
>> of countable units.  If you want to designate a count of specific units, 
>> append
>> this modifier, prepositionally, as in:  #sizeInBytes.
>>
>> Shaping
>>
>> ----- Original Message ----- From: "Brian T. Rice" <water at tunes.org>
>> To: <slate at tunes.org>
>> Sent: Monday, January 17, 2005 20:07
>> Subject: Renaming newEmpty/newSize: to new &capacity:
>>
>>
>>> Hello,
>>>
>>> This is a quick notification of a change, and a poll as to whether this
>>> suggested renaming has any objections - I am considering altering the
>>> collection protocol so that #newEmpty and #newSize: will just be keyword
>>> variations on a method #new, the keyword being "capacity" since size is a
>>> misnomer.
>>>
>>> This has been under consideration for a long time, and we can keep the old
>>> methods in the image for another sub-point release for convenience, but it
>>> will require a full bootstrap and a ton of selector replacements in the
>>> source code (this is not hard, but can be a nuisance for contributors).
>>>
>>> Any comments/suggestions?
>>>
>>> -Brian
> --
> Brian T. Rice
> LOGOS Research and Development
> http://tunes.org/~water/
>
>