About at: and basicAt difference

Bijan Parsia bparsia at email.unc.edu
Sun Jan 13 23:29:55 UTC 2002


On Sun, 13 Jan 2002, Lex Spoon wrote:

> > I should have said that I knew that.
> > 
> > My point was that the text following the primitives is different in
> > Object>>at: and Object>>basicAt: while they both call the same primitive.
> 
> True, it would be nice if the comment made the distinction.  Would you
> like to post a changeset?  :)

There are other #basicFoo messages...what would be nice if one could
write a general comment about #basicFoo vs #foo messages (usually, this
info shows up in external material).

This is a great example of cross cutting concerns in *documentation* as
well as code.

> Also, puritanically, at: should probably call basicAt: instead of doing
> the primitive itself.  That will probably impact performance a little,

Or a lot! I'd like to see some profiles ;)

> but then again, calling #at: for one item at a time is likely to be slow
> anyway.

Perhaps, but there's slow and there's *slow* :)

Interesting issue...at (so to speak) first I thought that the difference
between the two was that #basicAt: deliberately left out some
errorchecking that #at: had, but that (on quick reflection) seemed
wrong. #basicAt: isn't necessarily *more primitive* (and the extra error
checking didn't seem *so* big as to warrent keeping it out of #basicAt:)

Interestingly, a whole lot of overiddings of #at: are to get at values in
a collection stored in an instance variable. The problem with this sort of
move is that invariably you expose only the tiniest of the ivar objects
protocol. #at: and maybe #at:put:. And yes, this is ratehr convenient, but
I would tend to avoid thinking about what other collection messages would
be useful (perhaps requiring the caller to grab the ivar object directly).

Some sort of delegation scheme would be nice, with a simple way to filter
messages (so you could block messages you wanted to massage first, or just
not use because they were inappropriate).

You'd want common methods actually generated (instead of staying in side a
DNU handler), I imagine.

Perhaps it could be like autogenerated accessors....

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list