thanks for the explanation. I will add this in the method comment and probably class comment http://code.google.com/p/pharo/issues/detail?id=1685 Stef On Dec 25, 2009, at 1:11 AM, Eliot Miranda wrote:
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project