Chris C. wrote:
and make them overriable, and also allow access to the object through
the Pervasive. Problem here though, when writing a library we won’t
know that someone overrode a method somewhere else in the chain, so we
are stuck using the Pervasive a lot anyway. Why this isn’t a problem
now you might ask? Because we don’t have the Pervasive, so people are
less willing to override those methods. We still won’t have a good
looking #send that calls private methds. Well, we will, but it needs
a name. I am willing to write up the RCR on this one.
An RCR for Pervasives? If so I’d like to add a note…
Using Pervasives means an object won’t be able to trick you. Is that
good? If my class is a proxy then shouldn’t it be able to trick you?
I’m not sure about this, maybe that’s just foolish when it comes to
fundamental properties like class and id.
Also, if we have both pervasive methods PLUS the methods we presently
use, then we have the issue of inconsistancy. My object says it’s a
“PeterPiper” but Pervasives say it’s a “PickedPepper”. Obviously
Pervasives is right, so what’s the point of ever using the normal
method? Even if you know your own class in and out, you never know when
some one might come along and want to extend it. B/c of this Pervasives
would deservidely become common usage, so there should be a concise
syntax for it. “Pervasives.send obj, message” IMO is too long.