On Fri, Nov 21, 2014 at 5:30 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> To be abstract, or to be concrete, that is the question.
>
> Coming back to Eliot's proposal:
>
> > modify class Float to be an abstract class, and add two subclasses,
> BoxedFloat and SmallFloat, such that existing boxed instances of Float
> outside the SmallFloat range will become instances of BoxedFloat and
> instances within that range will be replaced by references to the relevant
> SmallFloat.
> > [...]
> > An alternative [...] is to add a superclass, e.g. LimitedPrecisionReal,
> move most of the methods into it, and keep Float as Float, and add
> SmallFloat as a subclass of LimitedPrecisionReal.
>
>
> Float
>   |
>   +------- BoxedFloat
>   |
>   +------- SmallFloat
>
>
> LimitedPrecisionReal
>   |
>   +------- Float
>   |
>   +------- SmallFloat
>
>
> The actual question was if the class named "Float" (as used in expressions
> like "Float pi") should be concrete or abstract.
>
> I strongly agree with Eliot's assessment that making Float the abstract
> superclass is best. What we name the two concrete subclasses is
> bikeshedding, and I trust Eliot to pick something not too unreasonable.
>

Good.  I think I'll go with

Float
  |
  +------- BoxedDouble
  |
  +------- SmallDouble


ImmediateDouble is fine too, but I like the symmetry with SmallInteger.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141121/8d52eac9/attachment.htm