Renaming newEmpty/newSize: to new &capacity:

[Brian Rice]

On Jan 31, 2005, at 8:54 PM, Shaping wrote:

>>> 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.
>>
>> Well, first of all, Slate is dynamically-typed by default, so 
>> whatever object is passed in is accepted until an error is thrown or 
>> message not found when sent. But if you try allocating arrays of size 
>> 5 / 2 or 3.4, right now you will get an uncontrollable cascade of 
>> errors, which will immediately crash your image. Squeak, I note, 
>> raises primitiveFailed on the same request. There's just no logical 
>> response for it (although the image crashing is a bug we need to fix 
>> - basically ensuring the argument isSmallInt).
>>
>> Give me a use-case that matters, and I'll find a way to make the 
>> protocol more robust, but remember that it'd add some overhead, so 
>> there's a cost/benefit balance here.
>
> Yes, there is no logical reason for it, concerning memory allocations.
>
> I was thinking broadly about any problem domain requiring a capacity 
> concept.  A model for a glass of water, for example, can include the 
> number of ounces of liquid contained.  This number would being 
> continuous, not quantic, because we must measure, not count ounces of 
> liquid.  Capacity as a concept works in both quantic and continuous 
> cases.

Well, the dimensioned units library definitely WILL accept any 
Magnitude as a quantity, Integer, BigInteger, Fraction (with any 
numerator/denominator), and Floats. Or a Complex or anything else that 
responds to the right protocol.

You can even use arbitrary objects as units or unit components.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/