[squeak-dev] sends of #class and #== considered harmful, may we please stop?
ma.chris.m at gmail.com
Sat Nov 24 20:06:59 UTC 2018
> >> > Basically, it comes down to Proxy's. I want them to work better in
> >> > Squeak. But every time we put another send to #class or #== in an
> >> > implementation of #=, since those methods are inlined, they're too
> >> > brittle to work with Proxy's. This causes hard-to-trackdown bugs in
> >> > applications and mini-messes to deal with them since the app is forced
> >> > to change its code to become "aware" of potential Proxy'iness of an
> >> > object before comparing it with #=.
> >> The disease is the inclining of #class and #==, not the use of these in comparison methods. In the VisualWorks vm I implemented a command-line/image header switch that enabled/disabled this inlining. It is easy to implement the same thing on Cog.
> >> If we did, then these methods would not be inlined if the flag is enabled, on a per-image basis.
> > Having consistent send properties among all messages would be cool.
> > Having said that, I do like performance, and there aren't that many
> > in-lined messages, and experience has trained me to recognize when I
> > use them and pay attention to the Proxy-dynamics. A "global switch"
> > approach would force the entire image to incur the overhead, even for
> > non-DB objects like the Morphs of the UI. A simple #yourself
> > strategically sprinkled here or there is not such a huge deal for me,
> > except that a lot of them could be trivially eliminated by nothing
> > more than a flexibility from my peers about their interpretations of
> > "equivalence".
> Perhaps if the method were called #ensureNonProxiedReceiver instead of
> #yourself, your peers would know why it is there.
Actually it is. Pretty close anyway, it's called
#realObjectIfMutatingProxy, but #yourself works too and I was trying
to keep the conversation simpler by sticking with standard familiar
> >> An alternative is Marcus Denker’s Opal compiler for Pharo which compiles #class and #== to normal sends, avoiding the inlined special selector bytecodes for these sends. That’s arguably an even better solution, because it retains the ability to inline. Although the mirror methods objectClass: and object:eqeq: can be used, with more overhead.
> >> In any case, instead of proposing to change a natural and comprehensible idiom, we can instead evolve the implementation to meet our needs.
> > Smalltalk is supposed to be about messages, not types. So why
> > shouldn't we let the _messages_ determine equivalence instead of
> > enforcing conformance to some specific "type"? You know we already
> > have several classes that use #isKindOf: rather than == otherObject
> > class. So, I think my proposal is natural and comprehensible too,
> > especially. from the aspect that it avoids the real-world bugs that
> > can sometimes seem incomprehensible.
> "foo isKindOf: Bar" is not a substitute for "foo class == Bar".
We're talking about defining a useful meaning for equivalence between
two complex objects, not making a substitute for identity checks. I
doubt you can articulate as clear a position against #isKindOf: in
> isMemberOf: Bar" is what you should use instead (if you really want worse
> performance :)).
I'm not sure if you're joking here, or not. :/ I'm open to all
More information about the Squeak-dev