Submitted this question within <flamebait/> earlier, but it got ignored. It needs to be answered.
Is Avalon for ANY other purpose than *Component Re-Use* or not? That is certainly my only interest. It is arguably what attracts most people to it? True or false? If it is, then Berin's excellent viewpoints on simplicity and ease of use may still be valid, and it seems much more likely that an easy to learn, easy to code version of Avalon is still quite possible, or at least that a ratched complexity model of behaviour is attainable. If not, then what other purposes does Avalon serve? For example, if a component was NOT going to be re-used on another project, is there any reason whatsoever to Avalon it or should it just be instantiated as any other OO object ? Is Avalon then becoming complex and difficult to learn and use because of the inherently complex objectives, or is because it's objectives aren't clear, so a shotgun approach is required to make sure that every avenue is accounted for? What a nightmare. Without a very clear objective, solving it keeps appearing to be possible, but then evaporates as the details are discussed, not because of the details themselves, but because the participants are trying to solve different problems. It's a pot of gold at the end of a rainbow - closer you get..... Hence Stefano's commentary on Cocoon using Avalon where it shouldn't be used in the first place. Mark Shepard, a suit from TI was credited with the saying that "More than two objectives is no objectives at all". If you don't know where you are going, any road will get you there. Someone else said that. *Component Re-Use*. Is that the only objective or not? True or False. Make your stand now, and then stick to it. Not fair to cite SoC or IoC or Separation of Interface and Implementation. They still make sense, but only because the objective is assumed as common sense. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
