[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] support for component API refactoring
- From: Ricky <ImmortalRick@xxxxxx>
- Date: Thu, 10 Nov 2005 10:55:37 +0100
- Delivered-to: email@example.com
- User-agent: Opera M2/8.50 (Linux, build 1358)
I am a developer with little experience so feel free to ignore by naive
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
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.