Hi,
We need to extend a class A (from package P-1) with some behavior in another package (P-2). In the package extension we will add methods and an instance variable for A. Is there a clean way to put that I.V. in the class extension which is in package P-2? If not, which will be a dirty way to do it? -Just put it in the A class package P-1 -Adding a postLoad block to P-2 and then add it programmatically Thanks in advance, Lautaro Fernández PS: we are working with VW 7.6nc -- Luke LAut SkyFernadezWalker _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 10-Feb-10, at 9:31 AM, Lautaro Fernández wrote: Hi, If not, which will be a dirty way to do it? -Anthony _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
El 10 de febrero de 2010 11:59, Anthony Lander <[hidden email]> escribió:
It could be an option, but the code is separate in packages to choose how deep you want to get in the framework. Of course, make a subclass is a good idea but essentially is the same object with more behaviour, we would like to do something like traits does (with an instance variable in this case*). Lets see how this ends... Thanks Anthony. * If I'm not mistaken, traits does not support I.V. inside of them... but something like that is the general idea _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Lautaro Fernández
The normal and organized way is to create a class override. That is,
your extension package overrides the original class definition and adds the inst.var. Effectively, it's difficult to avoid an Override when changing the class definition in the scope of another package than the originally defining one. A post-load action will not change the pattern: While running the post-load, the loading package still has authority over registering code. The post-load action which adds the inst.var. should create the due class Override. Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 Lautaro Fernández schrieb: > Hi, > We need to extend a class A (from package P-1) with some behavior in > another package (P-2). In the package extension we will add methods > and an instance variable for A. > Is there a clean way to put that I.V. in the class extension which is > in package P-2? > > If not, which will be a dirty way to do it? > -Just put it in the A class package P-1 > -Adding a postLoad block to P-2 and then add it programmatically > > Thanks in advance, > Lautaro Fernández > > PS: we are working with VW 7.6nc > -- > Luke LAut SkyFernadezWalker > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Lautaro Fernández
Actually, the VW Traits package
does support adding an ivar. I also recall something
being added to VW to permit adding an ivar as a class extension, not
sure if it is 7.7 or 7.8. Terry From: [hidden email] [mailto:[hidden email]] On
Behalf Of Lautaro Fernández El 10 de febrero de 2010 11:59, Anthony Lander <[hidden email]> escribió: On 10-Feb-10, at 9:31 AM, Lautaro Fernández wrote:
Hi,
Well, another way would be to make a subclass with your
instance variable, and then use it instead of the superclass. If needed, you
could migrate existing instances of the superclass in the postload block using
#become:.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Lautaro Fernández
On Feb 10, 2010, at 6:31 AM, Lautaro Fernández wrote: > Hi, > We need to extend a class A (from package P-1) with some behavior in > another package (P-2). In the package extension we will add methods > and an instance variable for A. > Is there a clean way to put that I.V. in the class extension which > is in package P-2? > > If not, which will be a dirty way to do it? > -Just put it in the A class package P-1 > -Adding a postLoad block to P-2 and then add it programmatically The problem is more genrally "how can my new library/framework/module/ codecomponent add additional state to existing object structures. There are a couple different patterns/techniques for doing this, with varying amounts of code smell and consequences. 1) Use a Class Definition Override. You select your class. You select "Override>>In Package..." from the class menu. You put the overide in your package. You add the instance variable to the definition. One problem (among others) with this technique is that if the original changes, your override masks those new changes back out of the system. 2) Use the subclass trick. Make a subclass of the TargetClass object (where TargetClass means "the class we want to extend"). Add the instance variable. Change TargetClass>>new/basicNew so that it will always return an instance of your new subclass. There's no overrides in this solution. But it only works if TargetClass is a leaf class with no subclasses. 3) Use a "look aside" variable. You create a global EphemeronDictionary and store your state there. So you can add setter and getter methods for your new state that look like: newStateAccessor ^NewStateRegistry at: self ifAbsent: [] newStateSetter: anObject NewStateRegistry at: self put: anObject Requires managing the NewStateRegistry, and may run into performance problems if you have really really high loads of access for this new state. If you're lucky sometimes... you may find that you're trying to extend a class that already has a "generic storage" mechanism. Examples of these are VisualPart and CodeComponent, both of which have generic "properties" dictionaries. -- Travis Griggs Objologist "Every institution finally perishes by an excess of its own first principle." - Lord Acton _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Terry Raymond
On Feb 10, 2010, at 7:42 AM, Terry Raymond wrote: > Actually, the VW Traits package does support adding an ivar. > > I also recall something being added to VW to permit adding an ivar > as a class extension, not sure if it is 7.7 or 7.8. I experimented with turning inst var names into first class objects, and one of the things I played with as a result was defining them via <tagged> methods, so that they became extensible. This was not integrated into the system. Yet. Don't know if that's what you were remembering, or something different. -- Travis Griggs Objologist "No other topic generates more heat and less light than code formatting" --Kent Beck _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Travis Griggs-3
Thank you all for your responses, and after looking for different approaches seems that doing a class-extension will fit better for my needs.
Cheers, Lautaro El 10 de febrero de 2010 12:49, Travis Griggs <[hidden email]> escribió:
-- Luke LAut SkyFernadezWalker _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |