[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] support for component API refactoring

I am a developer with little experience so feel free to ignore by naive thoughts.

Over time our API has become ladden with old methods, old package and
class names, old extension points, ...  The challenge is keeping the API
fresh, clean and clear while not breaking existing code which, according
to the assumption, cannot be changed.

So (compatible) changes in the API results in useless API methods and useless code. The aspect way only reduces the API clutter but introduces more code which is distributed among several decentralized aspects. IMHO the main problem is that there are no maintenance structures between aspects so how do deal with the clutter which arises from these new interactions? The problem of hiding complexity within the API is transferred to the problem of hiding the use of the API.


Maybe it is not possible to change something at the core and maintain an unchanged surface forever. Ok, thats not true it is possible but to the expense of increasing complexity to maintain the core. And this is severe. Look at IDocument till IDocumentExtension4 within eclipse and the nested if statements to handle them. And you see the insanity of this approach. Maintaining old client code _forever_ will result in similar structures.

- The producer of an API, for example, changes the name of a
package/class/method from A to B
- the producer also creates an aspect definition that "co-opts" all
consumers and modifies references to the old package/class/method to
reference the new package/class/method.
- this can capture package, class and mehod changes
- there are corner cases involving reflection and OSGi service lookup etc
that may be more challenging

As you indicated this approach will break down when it comes to reflection or non method API. The method signature is only a part of an API. Often dependencies between methods exist (bad but reality and there was a need for API change in the first place) or parameter/ return values have restrictions. The programmer uses the API contract and handles error situations or simple control flow with respect to the what is written in the JavaDoc. And this API handling can not be intercepeted by aspects while preserving semantics. To be more precise no aspect written by the producer can handle every use of API by a creative API consumer.


Another big problem area is the general back-to-the-roots approach which is noticeable in the Java comunity. Its called duck-typing which is a successful bystepping of the type system to infer the semantic of a method by its name and simply use the method in this way. This approach in itself breaks down easily (in SWT getSize().x and getLocation().x denote the width resp. the x offset of a widget) and dynamic method invocation can not be handled by aspects in general.

Is there any interest in looking at this problem (I'm thinking
specifically from the aspect folks).  Thisis a pretty mundane use of
aspects but it would be hugely useful.

Every approach to everything will break down at some point. But with this approach you do not have the effect of this break down (semantic clutter) under your control and you can not handle it as the problem is within the API client.


To end my foolish thoughs, when we stay in the OSGi world, what about plugin versions? It is possible to specify which version of a dependent package a plugin needs and they can be installed simultaneously. The general approach would be to not alter history (hidden API use rewrite) but to preserve every ancient version needed.

Ricky