About at: and basicAt difference

Bijan Parsia bparsia at email.unc.edu
Sun Jan 13 17:34:13 UTC 2002


On Sun, 13 Jan 2002, ducasse wrote:

> I was thinking that Object>>at: and Object>>basicAt: would be exactly the
> same. This seems true from a primitive point of view but not from the code
> explaining the primitive.

Well, the code following the primitive doesn't necessarily *explain* the
primitive (as you well know) it provides default behavior in case of
primitive failure. This is especially true in this case. It looks like
some testing and argument coercision code is bopped out of the primitive
and only done on failure. I assume this speeds up correct #at: code,
though it would be interesing to see a profile.



> Can somebody explain me why? It is a "bug" that would never occur since at
> and basicAt are special primitives?
> Which one is in sync with the primitive 60
[snip]

The #at: method (according to the version on my system) is later code,
circa 1999, by Dan Ingalls. The main difference seems to be testing for
isVariableness. Clearly the *primative* doesn't assume that the receiver
isVariable, but that's no reason for the *method* to do so (espeically in
"recovery mode") (The comment is a little confusing on this front.)

I think this test should be added to #basicAt:. As it stands, basic
#at: is "riskier" and gives a less informative error message.

The archeological evidence suggests that the divergence is merely an
oversight.

Interestingly, Interpreter>>commonAt: has the following line:

	successFlag & (self isIntegerObject: rcvr) not ifFalse: [^ self
primitiveFail]

This is where you could import the receiver coercions. It'd prolly speed
up some (incorrect) cases, but I think it's better to control that in the
#at:/#basicAt: methods.

Ok, in other words, no, I think think that niether is "synched" with the
primitive, but that they should be synched with each other.

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list