Hi Linus, 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. As mainly a module contributor, it is hard to follow the API changes and have enough steam to continue adding functionality as I have some time to do it.
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. Alas, ArgoUML isn't Eclipse and we haven't reached X > 0, so, we may argue that we don't need to thread carefully, but, there are at least some expectations of API stability... 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. Our developers are proficient with it and it isn't very complex to start hacking something based on Facade. This means - a clear proposal and decision should be made before starting changing things. Luís Linus Tolke wrote: > Hello Tom! > > The "support multiple loaded subsystems" requirement that you mention, > how can it best be solved? > > Because Andreas started discussion of the uml2 UMLFactory I am focused > on the createXXX() functions here. > > My first thought is that we need to have a mechanism providing the > information, when createXXX() is called, what model subsystem > implementation the newly created object belongs to. Either we need > several factories running at the same time and some way of knowing > which to use or we must remove the use of the createXXX() functions in > favor of the buildXXX(whatever) functions that create an object with > its relation to some other object. > > My second thought is that we would like to support cut'n'paste between > the model subsystems and that means that we will have the mechanism in > place to move objects between the model subsystem implementation. For > that reason it is not important if the object is created in the > correct or in the wrong subsystem. When the object is connected to the > model, it can be moved to the other one. We could even let the > createXXX() functions provide "empty" objects and create the object in > the implementation when the object is connected to the model (Lazy > Initialization pattern) but that would mean that we introduce an extra > object for each model object. > > > We are, as always in this discussion, torn between doing it right and > doing it in a simplest possible way. Because of our historical > experience of having two model repositories becoming unsupported, I > have some kind of mental block and would like to stick our layer of > interfaces. This to prepare for the next repository that we want to > integrate but it is appearant that this is extra work. > > /Linus > > > 2009/5/28 Tom Morris <[email protected] <mailto:[email protected]>> > > Perhaps the use of my name was only to catch my eye so I'd be tempted > to respond (in which case it worked!), but just to set the historical > record straight, the Model API was defined long before I joined the > project. > > As I understand it, it was created as a first step to isolate direct > access to the Novosoft UML 1.3 library (NSUML) which was scattered > throughout the code, in preparation for the move to UML 1.4. > > My major contributions were the UML 1.4 MDR implementation with > Ludovic, eliminating duplicate methods, extending the API to support > UML 1.4 functionality, beginning to extend it to UML 2.x, deprecating > obsolete methods, etc. In other words, maintenance and cleanup of > what was, for the most part, already defined. > > Because stability of the API is key, I did *not* change a lot of > things which arguably need fixing. If anyone is going to seriously > consider major compatibility breaking changes, I'd recommend starting > fresh with a clean sheet of paper, probably with an API largely > machine generated from the UML metamodel (which would, of course, lose > all your UML version isolation/compatibility). > > Some other things that need changing (but aren't worth the cost): > > - make the API more object oriented. The current "every element > handle is just an Object" style is a hack > - make the API more granular. Having huge interfaces like Facade > is crazy. > - make the API definition interface only with no required concrete > classes > > Something that I would like to see fixed to help with the migration to > UML 2.x by allowing both UML 1.4 and UML 2.x models to be open is: > > - support multiple loaded Model subsystems which can be selected at > runtime on a per-project/model basis > > Although all my major contributions are EPL licensed now, I'd be > willing to help collaborate on a BSD licensed version of the API which > supports this last goal (as well as needed UML 2.x extensions, of > course). That would allow Model subsystems which are written for > ArgoUML and those written for ArgoEclipse to continue to remain > compatible. > > Tom > > ------------------------------------------------------ > > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356334 > > <http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356334> > > To unsubscribe from this discussion, e-mail: > [[email protected] > <mailto:[email protected]>]. > To be allowed to post to the list contact the mailing list > moderator, email: [[email protected] <mailto:[email protected]>] > > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356665 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]]
