Extending a class and making the extended method available for connections

[Louis LaBrunda]

Hi,

There are times when I find it valuable to extend a class and making the extended method available for connections.  We can save the extended method in one of our apps but trying to define things for a connection needs to be saved in the app that "owns" the class.  It would be great if this could be changed so the connections info lived with the extended method.

Lou

[Marcus Wagner]

Hi Lou,

an inspiring idea, but unfortunately, it won't work without gound breaking redesign of abt (application builder technology) as it is.

My opinion is based on the study of how meta information for parts is realized. Let us have a look at the class side of every part.

You will detect a pragma defining a pool holding all names of interface specifications of its part.

Later are the anchor for any connection. This is the single point of reflection of a part.

In other words: as long as interface specs are kept in a single pool (per part) you are actually demanding for some sort of pool extendability.

I do not know any way to extend a pool.

That brings me to another point: an extendable pool (however it may look like) will impose high complexity in packaging.

We had this topic recently elsewhere.

Packaging assumes that the associations of the pool (key -> value) are part of the compiled method.

A particular reduction policy is based upon the fact that it can finally savely remove the pool dictionary from runtime code as the associations are held in the referencing methods.
This construction avoids any complexity of pool key lookup at run time.

Another example: NLS is also based on pools. Look at how complex it already is to preserve pool integrity without such an extension feature.

Thinking about other ways to represent the interface spec may lead us to pragmas/annotations.

May be that this Smalltalk language element did not exist or was not available when pools where designed to be the carrier of the interface spec.

Annotations were part of Ansi Smalltalk 1997, but abt was older.

Another idea is instead of extending a part, sometimes "subclassing" a part will help, assisted by a factory pattern.

Marcus