From: Matthias B. <inf...@mb...> - 2004-01-31 15:46:13
|
Hi, all, these arguments are strong enough to justify the change. Conceptually, I agree 100%. Emotionally, it's mixed - andromda-meta will lose much of its code (the architect in me says: that's good. the developer in me says: I could have saved time!). OK, so I think, I'll be able to do this till the end of next week. It will not change the useful portion of today's decorator API, the methods will remain the same, so you guys (as cartridge writers) can continue as planned. Cheers... Matthias > -----Original Message----- > From: and...@li...=20 > [mailto:and...@li...] On Behalf=20 > Of Chad Brandon > Sent: Saturday, January 31, 2004 3:46 PM > To: dra...@us...; Matthias Bohlen > Cc: 'Tony Mowers'; and...@li... > Subject: Re: [Andromda-devel] MMDs to MMD Facades >=20 >=20 >=20 > ----- Original Message -----=20 > From: "Wouter Zoons" <dra...@us...> > To: "Matthias Bohlen" <inf...@mb...> > Cc: "'Chad Brandon'" <chd...@ya...>; "'Tony Mowers'" > <to...@am...>; <and...@li...> > Sent: Friday, January 30, 2004 7:01 PM > Subject: Re: [Andromda-devel] MMDs to MMD Facades >=20 >=20 > > > > >Hi all, > > > > > >as usual, I'll sleep over this for one night because I am little=20 > > >frightened to throw away half of my code. :-) But if we=20 > decide to do=20 > > >it, I'd like to change andromda-meta myself. > > > > > > > > > > > very reasonable ... and I think we all agree that now is a=20 > good moment=20 > > for these kind of changes > > > > >About your points below: > > >1) Yes. > > >2) Should require almost no changes - the factory does not=20 > care about=20 > > >the quality of the objects it creates. > > >3) Should require almost no changes - the methods and=20 > associations in=20 > > >the model apply just the same to facades as to decorators. > > >4) Yes. > > > > > >Just one point: I'd like to hear feedback from the other people on=20 > > >the list, especially from Tony: > > >* Facades would hide most of the complicated nature of the=20 > metamodel.=20 > > >A facade does not "extend" the metaobject but encapsulates it. > > >* Do you think that this will spoil anything? >=20 > I don't think it will at all spoil anything, if a cartridge=20 > writer needs to expose some meta model information, he models=20 > his decorator/facades and then > provides access through these. It makes the templates even easier to > manage because it forces us to think about what we need to=20 > expose like Wouter says below. >=20 > > > > > > > > > > > > > A facade could even work on several metaobjects, I think=20 > the idea of=20 > > having an API to the metaobjects will not only improve=20 > usability but=20 > > it will also force us to think more clearly about the design of a=20 > > cartridge: /"what methods do we expose? what functionality is both=20 > > generic and practical?"/ > > > > with the MMDs we roughly exposed the complete metaobject plus some=20 > > extra methods, IMO Chad has a valid point when arguments for facades > > > > Matthias, on a conceptual level, do you agree with Chad ? Are you=20 > > afraid of compatibility issues with currently developed cartridges ? > > > > anyway, I vote for. > > > > >Chad: Maybe we need a few examples mailed to the list to=20 > tell people=20 > > >what's the difference. Then, we'll get more feedback. >=20 > This change would would also provide us some insulation from=20 > a change to another meta model (such as UML 2.0) we won't=20 > need to hunt down as many changes in the templates, which are=20 > a huge pain in comparison to changing java files (since the=20 > java compiler will find most of the issues for you). Another=20 > win is ease of understanding for a cartridge developer, in my=20 > opinion, decorators are much more complicated than facades. =20 > The only downside I can think of chaning out the decorators=20 > for facades is the fact that cartridge templates will not=20 > have access to the meta model...which in my opinion is=20 > exactly what we want to enforce. Matthias, what kinds of=20 > examples would you like to see? The only difference would be=20 > that your decorator operations would return facades, instead=20 > of meta model objects and the facade would no longer override=20 > every meta model operation. >=20 > > > > > > > > > > > > > >Good nite... > > >Matthias > > > > > > > > > > > > > bye > > Wouter. > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and=20 > Integration See the=20 > > breadth of Eclipse activity. February 3-5 in Anaheim, CA.=20 > > http://www.eclipsecon.org/osdn=20 > > _______________________________________________ > > Andromda-devel mailing list And...@li... > > https://lists.sourceforge.net/lists/listinfo/andromda-devel > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration=20 > See the breadth of Eclipse activity. February 3-5 in Anaheim,=20 > CA. http://www.eclipsecon.org/osdn=20 > _______________________________________________ > Andromda-devel mailing list And...@li... > https://lists.sourceforge.net/lists/listinfo/andromda-devel >=20 |