[Vm-dev] Re: Float hierarchy for 64-bit Spur

Bert Freudenberg bert at freudenbergs.de
Fri Nov 21 13:30:59 UTC 2014


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.

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141121/8487b283/smime.bin


More information about the Vm-dev mailing list