> -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch > > A perfect example of what I view to be a bad contract is the Meta package > in > the avalon module. It is unnecessarily strict in that any user of the > package > must supply any of the myriad of undocumented contracts that Merlin has > with it. > The contract is with the XML data format, the serialized format, etc. The > information is not stored with the class itself. A better contract is one > where > we supply the code for the attributes, but use something less restrictive > in > how to set up and use like Commons Attributes. You can still provide the > Attribute classes to provide strong contracts, but you are not locked into > only using the meta information defined by the meta package. Since you > are into > tools, there are some meta data that would help tools out but not really > be > useful at runtime. Do you want to really go to the mat with Stephen to > add > that meta data definition to the Meta package?
Ugh. I hate it when outlook messes up the formatting like that. Anyway, I hope everyone (including Stephen) see the meta package and ALL of current packages as something which can still be evolved and improved. The important part, as I see it, is not how the container sees the meta-info, but how the *users* see and set the meta-info. That's what should be consistent. I don't really care if there's a strong meta model or a simple tool like commons-attributes to retrieve it. To me, that's a container implementation issue. The more important aspect is a consistent pattern the component authors can use. > You can still provide strong typing and strong contracts without forcing > the > hand on a non-intuitive library. Are we getting closer to the same page > here? I think we are ALL getting closer to the same page here. In fact, I'm rather encouraged by all the discussion because I think we're starting to see a common way forward. Essentially, we all agree that: Components should be able to be loaded by any Avalon container without extra work by the component author. So the issue at hand is how is that specification defined. In other words, how do we plug any holes in the current framework? Got to run to another meeting... be back soon! J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
