Leo Simons wrote: >>What are the objectives, if they are more than re-use? Can you identify >>them? >> >> > >stuff like: > >- clean code >- common program flow in code >- instant well-designed architecture >- speed > True, but hardly unique to the goals of Avalon. These are goals of any good software. Non COP coders claim these objectives as well, and the 2nd and 3rd are also attributes of Re-Use as well as mutually exclusive objectives.
><snip/> > >What you ask thus is "what are the objects of software architecture >design?" and "what are the benefits of component libraries?" The answers >are all over the place; many apply to avalon. > I guess I keep trying to differentiate between atttributes of good design, and specific objectives that differentiate the Avalon Framework from OO design. Most of these things, including all the patterns in use throughout the industry are all fantastic patterns and Avalon should have them too, as great attributes. But they are not the primary unique objective, as can be observed by viewing the defined by use cases, and by the fact that they apply equally to straight OO as to Avalon, which is anything but straight OO. Berin is on the money. The use cases are the key. What are the use cases for Avalon? What are use cases where Avalon is not appropriate? What is the common thread for each. If Peter Donald says that xxx is a stupid thing, and Stefano says yeah, that was pretty stupid, I agree, and he was the only one using xxxx, then it is a bad use case and attempting to accomodate it into the pattern at the expense of making the entire framework un-necessarily complex is pretty stupid. At least from that viewpoint. So you dumb it back down and quit trying to do something that is not the primary objective anyway. Seems something that Spock would +1 for. Simplification is not just a silly excercise, because what Berin has vocalized very well is the possibility for clean, well articulated design that can be adopted by less than geniuses. It may piss the geniuses off, they may want to be the only ones who understand it, but that's not the goal. What has been said here about "pretty soon it becomes another whole language unto itself" is true. The geniuses may not want to let their baby out of the lab. So be it. The goal is to get it down to the essence. Then add each complexity only as needed, and in direct relation to each value gained. Surely that is a doable deal. Doesn't mean there would be plenty of chances for fun arguments and lots of brandishing of very fancy swordsmanship. It is a belief that the framework can be reduced to it's essence first, and made understandable and syntactically secure, and then the swordsmanship can happen at the edges where it doesn't keep the core of A5 from the 99% of programmers who would love to share components if it were reduced to it's essence first, but won't because it isn't yet. Anyone can make something awkward and complex. It is true art to make it simple again. (don't look at me, I'm no artist either.). I've said it before. I'll say it again. Current Avalon developers have much much more of a cool thing here than they appear to grok. If you can make the move that Berin has hinted at, it could be a lot of fun for more than just you, and not at your expense either. But someone has to want it. I guess that would have to include me, because I would like to see this thing settle down into that very place. It can be done.
