On Tue, 2002-10-01 at 11:30, Leo Sutic wrote: > > From: Leo Simons [mailto:[EMAIL PROTECTED]] > > > This makes your components (atm) > > phoenix-specific, it is also the way to a dll-like-hell if we > > keep adding meaning to core contracts that wasn't there before. > > > > What if I have an application deployed in phoenix 4.0 that > > just happens to postfix about half of its components with > > "#"? It will break in the next release. Granted, what are the > > chances....but the thing with contracts is you should be > > really strict about them. > > > > We could do the whole yada-yada on this again.... > > > > I'm not going to throw a -1 at it because I don't really feel > > like having to go over exactly the same discussions again. I > > feel like doing so though. > > > > Anyway, it makes me more sure that the only way to have > > avalon survive is to define that the minimum contracts > > defined in avalon framework are also the maximum ones........ > > Yes, but we repeatedly slam into discovering that the > contracts we specify aren't enough. > > Simply put - Avalon as it is is not mature enough to fulfill > its intended scope.
true. Avalon doesn't offer a convenient way to satisfy all use cases it wants to satisfy. There's a tradeoff between stability in a limited set of problem domains and not supporting all problem domains on the one hand, and unstability (ie framework 4.2, 4.3, 5, 6, 7....) with increasing support for different problem domains on the other hand. > We can keep trying to come up with the ultimate container, > but since no one of us knows what that container would need > for a feature set, we keep having diverging implementations > as each developer tries to solve his own problems. > > Good parts: It means that the framework is indeed evolving. > > Bad parts: Avalon as a dependency is less attractive. yup. I don't have a better answer than anyone else to this dilemma. All I know is that it would be very nice for me, and I think for many avalon users, to have only bugfixes, docs, testing etc for phoenix for like 6 months or so. The answer to questions like the one leading to the changes we're talking about now could be "we don't support this directly. Wait until phoenix 5 or so or solve at the application level". It's about choosing between stability/compatibility and continuous improvement. It seems I'm wrong in this particular case, but on a larger scale it is something where we need to shift the balance towards stability. cheers, Leo Simons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
