> + I want a little container that I can start with: > MyContainer myContainer = new MyContainer ();
This is the goal with Merlin as well. We factor out facilities that were put in more as a proof of concept which happen to be heavily intertwined so that it becomes a pluggable feature to a very small Kernel. > + give it a logger with: > myContainer.enableLogging (logger); > or: > myContainer.addAspect(new AvalonLogging (logger)); If this is not available already it should be very easily. > + configure with: > myContainer.configure (config); > + or with: > ComponentHandler handler = new > A4ComponentHandler(SomeClass.class, ...); > myContainer.addComponentHandler(handler); > > I don't want classloader management, command queues, > async-whatever, logkit configuration, repositories... Ok we then need to work together to trim down Merlin which Steve is already trying to do but we need to do it as a concerted team. We cannot leave this just up to Steve or else Merlin will be just as perverted as he is :-), you know with all that forking going on. > The thing with Merlin is that all that comes not only built-in, > but inseparable. And it appears like we're only getting more. > I'd start off by throwing out the model in Merlin. We need > something simpler to start with. Maybe then we can add: > > myContainer.addAspect(new DependencyValidation()); Now this is very interesting. You're suggesting that dependency checks are a feature of the container? I think I like this. It's a most excellent way to take an intertwined aspect of a container and separate it. See this is the kind of stuff we need to talk about and make Steve permeable to. This is exactly what I was referring to above about stripping out features and making it pluggable. We can do it. > (Point here is that you can use the container with or > without validation. You don't have to understand validation > if you don't want it. If you *do* want to validate dependencies, > you must understand how to do it, but that's something you > can study in isolation from all other aspects.) Yes this is a great point you're making. Let's make this happen with Merlin. > You talk about everyone influencing, evolving, etc. But what > if I start to evolve and influence in a direction that is > different from your goal? There is more than just Steve here. We have a new fresh crew. I think together as a team of people with open discussion we can influence each other. We need to be sincere with one another and stop presuming that everyone has some secret agenda. Let's drop the past and continue forward. > Will we compromise? Get some half-assed neither-here-nor-there > nightmare? Is this your answer to that?: > > > This is not about "which container" - that's a done deal. > > This is about accepting that its a done deal. The sooner > > we get past this point the better it will be for you, me, > > and everyone else. > > To drive this to the absurd limit - are you willing to start > with a clean slate? Throw away Merlin, and build something > new (where you can get bits and pieces from Merlin implemented)? > > I'm not saying that this is even a workable solution, but *I > do want to know just how attached to Merlin you are.* Because > it really influences the ability of others to, well, influence > and evolve. > > If it is "take it or leave it", then I'm not that inclined > to pitch in. > > If it is a "look, I've come across a lot of problems building > Merlin, I have solved them. I don't want to throw away > all that knowledge, and that's why I'm conservative. But I'd > throw away my solutions in an instant if better solutions > appeared" then I'm more up for it. I hope this is where Steve stands myself. > It's just that statements such as the one above doesn't really > read that way for me. Makes me wonder if I'm just free to > influence and evolve as long as I influence and evolve > the way you want me to. > > the other Leo simply hates the names I give things. > > The thing is this: I don't hate the names you give to things. > I hate the fact that so many names are needed. It makes me > think that there's something fundamentally wrong with the > system, since you need to understand so many concepts. The complexity is there mostly for the container developer and a bit for the component author. There are valid reasons for these concepts but the clean separation you talk about with isolation is missing. If we can make it so the concept can exist but be ok to ignore for those uninterested with the feature then we're golden right. Plus if these aspects/features were pluggable you could use your own implementation of the feature if you wanted to. This will give us developers more freedom to add features on our own without mass collaboration. To reach this end state we require your ideas of adding features in a pluggable fashion where they can be isolated and users can learn the concepts if they need the feature. > That's not "simply hating the names". Why this complexity? > Why are all those concepts one big ball of strings? If it > were eight concepts that I could have a go at in isolation > I'd be fine. But you have eight concepts that must be > grasped *at once*. That's *too much.* I would agree with you. It's a lot of stuff for container developers to grok. But we're not going to change anything unless we influence Steve and have him help us reach these goals. We need to take things one step at a time: 1). Make a list of these seperable features/aspects 2). Order wrt complexity of achieving separation 3). Adjust order with respect to possible dependencies 4). Take top most feature or setup goals and start re-factoring Merlin to make the feature pluggable and isolated. 5). Go to 4 until list is gone At the end of the day Merlin will be what we want it to be. > You've described the difference as the difference between > cowboys and city-guys. Make no mistake, the cowboys have been > at it as well. While you city guys are sketching out the > plans for the most model-mathematically correct layout of your > downtown N.Y., we've already reached the Pacific and are building > million-inhabitant cities every day. > > No, those cities aren't what *you'd* call perfect, but the quality > of living is great, they evolve much faster and *will* overtake > you. It's just a matter of time. > > So come on city boy! Get some dirt on that suit of yours. > > We'll build a Stetson-shaped container. > (http://www.stetsonhat.com/wstrn.htm) Please no more City Slickers references. There is no point to it. We're all one. There is no separation. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
