Best practice for overwriting methods in other classes
I have now twice in two different situations felt a need to "steal" a method in Nautilus and make that method an extension method in my own package. In situation A, I wanted to steal the #buildCommentPane to use a different Morph for class comments, In situation B, Sergio and I needed to redefine #getComments and #addComments:notifying: to fill out behaviour for package comments. What is the kosher way to work and contribute in such situations? I guess it will also pop up in situations outside of Nautilus. -- View this message in context: http://forum.world.st/Best-practice-for-overwriting-methods-in-other-classes... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 22 May 2015, at 07:08, Kasper Osterbye <kasper@itu.dk> wrote:
I have now twice in two different situations felt a need to "steal" a method in Nautilus and make that method an extension method in my own package.
In situation A, I wanted to steal the #buildCommentPane to use a different Morph for class comments, In situation B, Sergio and I needed to redefine #getComments and #addComments:notifying: to fill out behaviour for package comments.
What is the kosher way to work and contribute in such situations? I guess it will also pop up in situations outside of Nautilus.
Semantically, overrides are never âsaveâ as they do not compose: two packages overriding, which version is the correct one? In the past people tried to e.g. add support to monticello to install the original method when an override gets unloaded. But this all breaks down as soon as two packages override the same method. Overrides therefore should be used just for experimental code⦠what i do is to put it on *mypackage-override so I do not forget to find a solution later that does not need it. Marcus
On Fri, May 22, 2015 at 1:08 PM, Kasper Osterbye <kasper@itu.dk> wrote:
I have now twice in two different situations felt a need to "steal" a method in Nautilus and make that method an extension method in my own package.
In situation A, I wanted to steal the #buildCommentPane to use a different Morph for class comments,
I've not encountered this myself, but I guess the approach would be to get a change integrated into Pharo that allows an external package to configure it to use a different Morph -- though I'm not sure of the best approach to do that.
In situation B, Sergio and I needed to redefine #getComments and #addComments:notifying: to fill out behaviour for package comments.
In this case, I thought the aim of your package-comments work was to integrate it into Pharo, so actually you should be redefining the built-in methods as needed (??) cheers -ben What is the kosher way to work and contribute in such situations? I guess it
will also pop up in situations outside of Nautilus.
I have now twice in two different situations felt a need to "steal" a method in Nautilus and make that method an extension method in my own package.
In situation A, I wanted to steal the #buildCommentPane to use a different Morph for class comments, In situation B, Sergio and I needed to redefine #getComments and #addComments:notifying: to fill out behaviour for package comments.
It either means that - you override is temporal and that it should be integrated in Nautilus - or it means that nautilus should provide the correct plug (either with an attribute and accessor or announcements) and that such extensions should be pushed inside nautilus.
What is the kosher way to work and contribute in such situations? I guess it will also pop up in situations outside of Nautilus.
-- View this message in context: http://forum.world.st/Best-practice-for-overwriting-methods-in-other-classes... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Ben Coman -
Kasper Osterbye -
Marcus Denker -
stepharo