Just my 2 cents but I think we need to spend a little time and focus on WHAT we want the framework/container (or Avalon# as a whole) to do before we start talking in too much detail about implementation details (the HOW) and schedule (WHEN). The bottom line is the container coding has already begun and is under way but if we go down this path of "starting over" (I know probably not the right term) then we have to first look at the framework and make sure it meets the needs for a componentized container, which I'm not sure it does right now. Right now the framework interfaces are in flux, which in turn affects the container so we need to nail down the framework before the container can really be stable.
Something I'd like to see done is just start developing a list of capabilities that we should meet. Now I agree with Berin's XP approach concepts that say you shouldn't have "hard and fast" requirements but a living set of capabilities is a good idea so it can foster a "common goal" in the team. I still believe that we should find a way to post these to some website (that is up-to-date) as we agree on them for historical purposes unless we just continually post updated sets to the list over and over again. Maybe some form of this already exists? > -----Original Message----- > From: hammett [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2003 10:40 AM > To: Avalon Developers List > Subject: Re: [RRT] Getting back to the basics (long) > > ----- Original Message ----- > From: "Berin Loritsch" <[EMAIL PROTECTED]> > > > > I was wondering about "type checking". Seems that every check occurs > in > the > > > type loading/initialization. Maybe this type checking could be done in > a > > > transparent way using ContextBoundObject/Interception in .Net. Then > just > a > > > simple "new" could fire every checking and no explicit type checking > would > > > be necessary. Anyway is too soon to say. If I'm in the right path > signalize > > > that and I would create some samples, tests, labs.. > > > > TO be honest, I wouldn't want to port it over to .NET. I think with > .NET > we > > can explore some new territory where we don't need an object model for > the > > meta information. Esp. since in .NET the attributes are part of the > class. > > In Java things are a bit different in the short term. > > Yes yes! I always thought in porting using attributes. No xinfo files, > etc. > The code could be something like: > > namespace Apache.Avalon.Playground > { > using System; > using Apache.Avalon.Attributes; > > [Component("primary-component", Lifestyle.Singleton)] > public class Primary : IPrimaryService, IContextualizable > { > [RequiredContextEntry("file", typeof(System.IO.File))] > public void Contextualize(Context context) > { > } > } > } > > > I just don't about the Version as .net handles side-by-side execution. Or > maybe the dependencies could be specified in a assembly full name way. > > > Part of the implications of the technical part of the RRT I put forth > was > that > > in an ideal world, the object model for meta information would not be > needed. > > In fact, it would be limiting the potential of what the container could > do. > > Maybe you're right. .Net assemblies includes dependency information, > version > and other things meta project included. > > > I think that .NET provides the clean slate we can start with to use the > ideas > > I set forth. > > How about ContextBoundObjects ? When the container code will start to be > written? > > > hammett > MCAD > Meet Polyethylene at http://polyethy.sourceforge.net/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
