(forgive the delay, better this is seen twice than not at all) Begin forwarded message:
|
Hi Eliot,
this is similar to Shout's #aboutToStyle:, which also cannot be an extension because of the unwanted dependencies. In general, #representsSameBrowseeAs: is kind of a model comparison that could also come handy in non-morphic scenarios. It's not like #= or #== but a third, tool-specific kind. I have a similar pattern in Vivide: https://github.com/hpi-swa/vivide/search?utf8=%E2%9C%93&q=isObject%3A&type=Code I use that ViArtifactContainer >> #isObject:, for example, to make instances of CompiledMethod and MethodReference equal on a code editing (= tool) level: https://github.com/hpi-swa/vivide/blob/019606e18670e389a845e46cb384436940cc58bf/repository/Vivide.package/ViMethodEditor.class/instance/isObject..st Best, Marcel |
Hi Marcel,
the message is from Nicolas, not me :) _,,,^..^,,,_ (phone) > On May 8, 2016, at 9:56 AM, marcel.taeumel <[hidden email]> wrote: > > Hi Eliot, > > this is similar to Shout's #aboutToStyle:, which also cannot be an extension > because of the unwanted dependencies. > > In general, #representsSameBrowseeAs: is kind of a model comparison that > could also come handy in non-morphic scenarios. It's not like #= or #== but > a third, tool-specific kind. I have a similar pattern in Vivide: > https://github.com/hpi-swa/vivide/search?utf8=%E2%9C%93&q=isObject%3A&type=Code > > I use that ViArtifactContainer >> #isObject:, for example, to make instances > of CompiledMethod and MethodReference equal on a code editing (= tool) > level: > https://github.com/hpi-swa/vivide/blob/019606e18670e389a845e46cb384436940cc58bf/repository/Vivide.package/ViMethodEditor.class/instance/isObject..st > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/Fwd-Vm-dev-Once-upon-time-representsSameBrowseeAs-was-moved-out-of-Morphic-tp4893915p4893949.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
Hi Eliot,
okay. I am sure that Nicolas will read it also. :-D I found another interesting pattern: SomeCoolMorph class >> #initialize self registerInFlapsRegistry. SomeCoolMorph class >> #registerInFlapsRegistry ... flapsRegistry registerQuad: ... SomeCoolMorph class >> #unload ... flapsRegistry unregisterQuadsWithReceiver: self ... Now, we cannot put #registerInFlapsRegistry in a Morphic extension because of the same dilemma. However, Flaps and Morphs need morphic anyway. So we are fine here. Can't we use our ServiceRegistry for such things in the future? (Me, *not* wanting to change flaps registration. *g*) Best, Marcel |
Free forum by Nabble | Edit this page |