On Fri, May 29, 2009 at 1:44 AM, Luis Sergio Oliveira <[email protected]> wrote:
> I'm not into the whole details of doing things one way or the other, I > want just to express some concern related to potential big changes in > the model API. Hopefully my message wasn't interpreted as being in favor of this. I agree that backward compatibility is critical. I think that the current rules (when they're followed) provide a reasonable balance between stability and progress, ie no API breaking changes without deprecating first, no removing deprecated APIs for one full release (one year or more at the current release frequency). The problems are that a) not everyone follows the rules and b) even those who do follow the rules don't always understand when they're breaking things, particularly with regards to binary compatibility as opposed to source compatibility. To help with the latter I'm setting up the Eclipse API tooling for ArgoEclipse, but that just provides the mechanism, not the will/desire. > The open source projects I know that have grown to become "platform" are > all very conservative in changes that break backwards compatibility. > Eclipse is one example - the principle is: X.y will not break backward > compatibility while X doesn't change. There needs to be a balance and the balance is different for each project. Eclipse pays a high price for all the backward compatibility and it limits their flexibility to do interesting stuff. One of the things that their looking at for their next-gen 'e4' project is how much compatibility to drop to shake off some of this ossification. The other thing that feeds into this though is API design. ArgoUML has never really distinguished between public and private APIs very well and in particular has made no concerted effort to make sure that the public APIs are a) as small as possible and b) reviewed with a view towards longevity and extensibility. This is a cost that has to be paid up front when the APIs are designed and first implemented to save heartache down the road. If the API used by extension writers was smaller, it would be easier to focus on keeping it stable, but there are still going to be changes caused by things like below. > Concerning a critique of the current API, although it isn't the most > easier API to work with, it mainly comes to this as a natural thing due > to the complexity of the underlying UML. UML is a major issue when it comes to compatibility as well. The OMG has never made any attempt to have compatibility between versions of the UML spec and this bubbles up to the API. If the OMG renames something, the new name should really be added to the API so that new developers can find it easily. Now the old name could potentially be kept around forever, but this clutters the API and associated documentation making it more difficult to use, so my practice had been to deprecate the old name and remove it eventually. All this gets much more difficult when the change is not a simple renaming of something. When the semantics change, there's a limit to how much backward compatibility provide. For example, if they've got something silly like "add_only" for changeability which they then remove because they never really defined what it meant and it doesn't do anything useful, you're basically screwed as far as compatibility goes. You have the choice of removing it, breaking any application which references it, even if they don't really use it, or lying to the application and mapping it to something semantically different. Not really a very good choice either way, but a situation created by the OMG that tool writers just have to deal with. > This means - a clear proposal and decision should be made before > starting changing things. Absolutely. > Our developers are proficient > with it and it isn't very complex to start hacking something based on > Facade. ... > As mainly from the API user side, I would like to say that Facade is > easier to use than some XxxxHelper and XxxxFactory. This means - when I > was learning my way on ArgoUML I understood more quickly how to use > Facade than the other interfaces. It's almost always easier to use an API to reference/read existing objects as compared to creating new objects, but which of the following is easier? ArgoNamedElement foo; 1. String name = Model.getFacade().getName(foo); 2. String name = foo.getName(); particularly if you're using an IDE that lets you type "foo.get<meta key meaning show me all the options here>"? Now, this is *not* something that I'm proposing to change, but I've got an idea rattling around in the back of my head that style #2 could be implemented in a fashion similar to what MDR does by using the Java reflection API to inject Model API specific methods into MDR or eUML objects at run time. Tom ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356824 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
