2009/12/25 Levente Uzonyi <[email protected]>:
> 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?
>
>

I think the right question is:
- if we going to remove that, what alternative we're proposing?

Like:
throw a special exception class, so people may handle it and use
rounding in case of need?

And will it be more convenient to programmer? Less error prone?

> Levente
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to