[squeak-dev] sends of #class and #== considered harmful, may we please stop?
dionisiydk at gmail.com
Fri Nov 23 21:43:33 UTC 2018
Just for notice in Pharo #class is a normal message send for a long time. I
wonder that it is not true for Squeak.
чт, 22 нояб. 2018 г. в 17:21, Chris Muller <asqueaker at gmail.com>:
> Hi guys,
> Something I've been wanting to ask the community for years, but never
> had the gumption, was about changing how we write our #= and #hash
> methods, but now that we're combing through them anyway, I must!
> 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 #=.
> This is no surprise, since writing a send to #== instead of #= for no
> more than "performance" is actually breaking encapsulation in the
> first place...
> There is an easy solution. When writing #= and #hash implementations,
> use (#species or #xxxClass or #isKindOf: instead of #class) and #=
> instead #==. So, for example, Eliot, I want to upgrade your new
> Message>>#= to something like:
> = anObject
> ^self xxxClass = anObject xxxClass
> and: [selector = anObject selector "selector lookup is by identity"
> and: [lookupClass = anObject lookupClass
> and: [args literalEqual: anObject arguments]]]
> Or #species or #isKindOf:, like we do in many other methods. Now the
> method is Proxy-compatible.
> What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev