Renaming newEmpty/newSize: to new &capacity:

[Shaping]

>> 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.

I'm interested in factoring natural language, in the context of machine 
behavior, to a minimum set of words/concepts.  Capacity would be one of them.


Shaping