On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
