On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 24 Dec 2009, Eliot Miranda wrote:
>
> This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80
> derived Smalltalks:
>
> !Object methodsFor: 'accessing'!
> at: index
> � �"Answer the value of an indexable field in the receiver. Fail if the
> � �argument index is not an Integer or is out of bounds. Essential. See
> � �documentation in Object metaclass."
>
> � �<primitive: 60>
> � �index isInteger
> � � � �ifTrue: [self errorSubscriptBounds: index].
> � �(index isKindOf: Number)
> � � � �ifTrue: [^self at: index truncated]
> � � � �ifFalse: [self errorNonIntegerIndex]!
>
> It is also free in the sense that the failure code is only invoked when the
> primitive fails and so adds nothing to the cost of successful accesses,
> which are the high dynamic frequency operation. �It will also show up under
> profiling if one is concerned about efficiency, and so isn't a hidden cost.
>
> It is also in keeping with Smalltalk's mixed mode/arbitrary precision
> implicit coercion number system that one *can* use fractions or floats as
> indices.
>
> Stripping out coercions like this will make the system more brittle. �So
> please do *not* remove this "hack". �I think it's a feature and a useful
> one.

Can you give me an example that demonstrates the usefulness of this
feature?

| a r |
a := Array new: 10 withAll: 0.
r := Random new.
100 timesRepeat: [| v | v := r next * 10 + 1. a at: v put: (a at: v) + 1].
a

i.e. I didn't have to provide an explicit rounding step. �That's useful. �But in general anywhere where an index is derived by some calculation not having to provide the rounding step could be useful/helpful/more concise. �e.g.�(n roundTo: 0.1) * 10 vs ((n roundTo: 0.1) * 10) asInteger.

Some thought went into the original choice. �It is not a hack but there by intent. �The integers are simply a subset of the reals and forcing the programmer to use them is favouring the machine above the programmer.

But I think you should justify getting rid of it rather than my having to justify keeping it. �Getting rid of it risks breaking code. �If it is there but does not harm then why get rid of it?

best
Eliot


Levente

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project