[vwnc] Store extensions

Hello,

I have an idea for a possible improvement of Store.

Recently I got into a situation where I wanted to add an instance variable to ApplicationStandardSystemController. To do this, I had to override its class definition. Next, I wanted to have a pair of accessors for this variable: no problem, I can just add them in a separate package that is an extension on the class. Then I want to initialize the variable in the #initialize method. Unfortunately initialize is already implemented, so I have to override it like this:

initialize

      …existing code…

      self myVariable: …anObject…

Next I want to wrap some existing methods in the class with some code that looks like:

someExistingMethod

      ^self doSomethingNewWhile: […existing code…]

Again, I override #someExistingMethod.

The bad thing is that each time I override something, I get into trouble when a new version of VW (or some library) arrives. I need to go through all my overrides to see whether they’re still ok, simply because overrides completely replace the existing code with something else without any link whatsoever to the original. If someone adds an instvar the the class I have overridden, then I have to do the override again. The same for changes to the initialize method and #someMethod.

Here’s a proposal to overcome this kind of problem: instead of overriding one should be able to extend every kind of programming concept.

What does this mean? You should be able to do this:

-        add instvars by means of an extension, NOT by overriding a class definition

-        add class instvars via extensions (shared variables do this already)

-        extend existing methods

o        by appending code

o        by prepending code

o        by wrapping code around them

-        other?

My example could then be done as follows:

-        I add a new instvar to ApplicationStandardSystemController without overriding its definition

-        I add the accessing methods in an extension (this already exists)

-        I append a single line of code to the initialize method containing ‘self myVariable: anObject’, without completely overriding the #initialize method

-        I can wrap existing methods with something like:

o        ‘self doSomethingNewWhile: [@overridden_method@]’

o        Here @overridden_method@ is a special place holder that the compiler can replace with the original method.

With these constructs you can modify system classes/external library code, without having to worry too much about new versions. It’s a bit like aspect oriented programming or method wrappers. It won’t solve all problems related to modifying third party code, but it would work pretty good in a lot of cases and would certainly work a lot better than what we can do with the existing overrides.

Any thoughts on this?

-Mark

Dennis,

“On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.”

Perhaps a pseudo variable ‘overriddenMethod’ can be introduced (like #thisContext) and that responds to #value, #value:, #value:value: etc. Then you can write:

myOverriddenMethod: aString

      self firstDoSomethingDifferent.

      overriddenMethod value: aString.

      self doSomeOtherThings

That sounds interesting.

This technique can make the customisation of the development environment easier. For instance, instead of having to override a method to add a single new menu item (and losing menuitems in future updates), you could override it by doing:

menu

      ^overriddenMethod value addItem: <…item…>

Well I can see two (in different cases).

Some classes are referred to by name, particularly in
the UI subsystems, so to use a subclass you still have
to go and make a change to at least one other class.

Also, in the case of something like "Object", you cannot
subclass it to get what you want.

On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.

Stefan Schmiedl wrote:

On Wed, 19 Nov 2008 14:34:02 +0100

Mark Plas [hidden email] wrote:

Any thoughts on this?

What's the advantage over creating a subclass and refering

to the superclass implementation?

s.

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 

Dennis Smith                                   +1 416.798.7948

Cherniak Software Development Corporation   Fax: +1 416.798.0948

509-2001 Sheppard Avenue East        [hidden email]

Toronto, ON M2J 4Z8              <a href="sip:dennis@CherniakSoftware.com">sip:dennis@...

Canada                          http://www.CherniakSoftware.com

Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Hello Michel,

Is some of this code available in public?

Thanks,

Mark

Hello Mark,

Hi Paul,

I don’t have VA. Would it be possible to email a fileout of the code?

And does your technique handle multiple overrides of the same method?

Thanks,

Mark

The pseudo variable approach is interesting, but my experience is that it is easy to transiently exchange methods.

I implemented method override support for both VA and VW before it became a feature of VW. The way I did it preserves the original overridden method and allows it to be seen and executed. Overrides were explicitly declared rather than accidental.

Application code declares a new method named #override_myMethod to override a method named #myMethod. The framework recognizes the pattern #override_* and knows to rename a method equal to the the suffex (#myMethod) to #overridden_myMethod. The framework also transiently exchanges #myMethod in the method dictionary with #override_myMethod.

The overridden behavior can be explicitly called from within the override method. It worked well and changes were maintained properly through loads and such. Alas, the code is only available for ENVY-based images. I sure miss being able to execute overridden code with the current VW override support. Without the ability to refer to overridden code then you need to copy (and maintain) code that may change by others in the their next release.

The code is available as Public Domain here:

http://sourceforge.net/projects/methodoverride/

Paul Baumann 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Plas
Sent: Wednesday, November 19, 2008 10:44 AM
To: Dennis Smith
Cc: [hidden email]
Subject: Re: [vwnc] Store extensions

Dennis,

“On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.”

Perhaps a pseudo variable ‘overriddenMethod’ can be introduced (like #thisContext) and that responds to #value, #value:, #value:value: etc. Then you can write:

myOverriddenMethod: aString

      self firstDoSomethingDifferent.

      overriddenMethod value: aString.

      self doSomeOtherThings

That sounds interesting.

This technique can make the customisation of the development environment easier. For instance, instead of having to override a method to add a single new menu item (and losing menuitems in future updates), you could override it by doing:

menu

      ^overriddenMethod value addItem: <…item…>

Well I can see two (in different cases).

Some classes are referred to by name, particularly in
the UI subsystems, so to use a subclass you still have
to go and make a change to at least one other class.

Also, in the case of something like "Object", you cannot
subclass it to get what you want.

On the note of extending methods, one could do that
by making the overridden method available to be invoked
by the new method.

Stefan Schmiedl wrote:

On Wed, 19 Nov 2008 14:34:02 +0100

Mark Plas [hidden email] wrote:

Any thoughts on this?

What's the advantage over creating a subclass and refering

to the superclass implementation?

s.

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 

Dennis Smith                                   +1 416.798.7948

Cherniak Software Development Corporation   Fax: +1 416.798.0948

509-2001 Sheppard Avenue East        [hidden email]

Toronto, ON M2J 4Z8              <a href="sip:dennis@CherniakSoftware.com">sip:dennis@...

Canada                          http://www.CherniakSoftware.com

Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

Paul

And what happens if the overridden method refers to a renamed

instance variable?

On Wed, 19 Nov 2008 14:34:02 +0100

Mark Plas [hidden email] wrote:

What's the advantage over creating a subclass and refering

to the superclass implementation?

s.

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 

Dennis Smith                                   +1 416.798.7948

Cherniak Software Development Corporation   Fax: +1 416.798.0948

509-2001 Sheppard Avenue East        [hidden email]

Toronto, ON M2J 4Z8              <a href="sip:dennis@CherniakSoftware.com">sip:dennis@...

Canada                          http://www.CherniakSoftware.com

Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP