On Oct 1, 5:16 pm, Christian Boos <cb...@neuf.fr> wrote: > Hello Itamar, > > Thanks for your interest on the topic. Let me shed some light on this. > First, some apologies for the "spaghetti" aspect, it's really because > this is all about notes which have been taken sporadically and ideas > which have evolved for now about 5 years, all starting in the > TracObjectModelProposal and consolidated during my practice of > maintaining Trac. > > [...major snip...] > > For the edits on the wiki, It's easy: they were mainly written by me ;-) > The discussion on Trac-Dev could never happen so far, as it was > "trolled" many times by comments like "-1", "this is a bad idea" and the > like. I think this won't happen again, as the people behind those > comments have not contributed anything to the project in years and it > would be very bold from them to just jump in now to try to derail this > effort. You never know, but if this happens, just ignore it. What we > need is a rationale development discussion, just as it often happen on > tickets, not hand waving.
Well, trolling... :-) It was never like that, but more that some of us do prefer the loosely coupled and explicit nature of objects calling each other with simple arguments to get work done. I, like many others, came into Trac because the simplicity of the Trac internals. I made plugins because they were easy, powerful and flexible. GenericTrac is a new "Framework" to be grafted into this structure, and it is not like a strong case has been made so far for it being a better way of doing things? Still, it is a philosophy thing, and about as useful to argue about as "red" being a better colour than "blue". GenericTrac can no doubt be made to work in code as well. I have no reason to believe that you will not make it work, it will be well designed, and it will look deceptively simple. Anything can be made to work, without the idea being either good or bad, or right or wrong. It would just be different. This "different" is fine until you need to really understand it. I contribute to Trac, but what I mainly do is mainly plugins. You and Remy are almost completely dedicated to core code (which is great of course), but I feel this "different" apect in ways you don't. 1. Complex classes. Formatter, Context, GenericObject (or whatever) contains an inner life and structure that I'd need to understand. Complex, nested in several layers. They have non-descript names and what they do and how they do it is not obvious by looking at them. "Flat is better than nested." 2. Complex classes. As a plugin developer I appreciate the fact that the internals are managed by me. The components that I write do what they do, and they don't support all kinds of facets and features that I don't want or need. My classes don't suddenly adapt and change behaviour just because and admin installed the latest Trac from trunk, which then morphed my features into something it is not made to support, or broke security by changing some internal assumptions. "Simple is better than complex." 2. Complex classes. Output from one call depends on the settings and input at some other facet of the object. Perhaps set at a different time, and in some other completely unrelated coding context for this object being reused or passed around. Say I'm writing a request filter or somethings else that detects and manipulates the structure, I'd need to fully understand all the ways this object can manifest itself. I'd need to understand what effect any change I make may have later when for instance the template calls MyObject.render_yourself(). Side- effects are hard to understand and debug for all but core developers. "Explicit is better than implicit." 3. Optional complex classes. So, we are to spread our already thin layer of effort into supporting two alternative usage "philosophies" indefinately? I don't think so, and that certainly does not make sense. If this is the way we go, then the rest of Trac would need to change to support this new and better model of how things are done. We can't do both - as illustrated by the ongoing db context refactoring. "There should be one-- and preferably only one --obvious way to do it." Five years as you say, and noone really understands what it means or involves to get it done or how exactly it will make things better... Christian, I really appreciate all the hard work you put in. However, as a word of advice, one of the problems I have with GenericTrac is how it is over-abused in tagging tickets and ideas with it. It is made out to be something that can solve all complex issues of aspected behaviour or relationships. Like this discussion about user management (which is a very positive thing!), gets "GenericTrac" tangled into it for no apparent reason other than that the project has given the impression that for all new structures, a generic way of doing things is the way to go. In discussions like this one, we need to decouple features from implementation to a much larger extent. "Sparse is better than dense." I've stayed with the project for a long time, and I'm planning to stay on. I'll respect the direction the majority want to take, and as you also said it is really only fair that when you write the code you have much more important say in what should be done and how. I have no problem with that. I do however want to use my voice to express my concerns about this direction. :::simon https://www.coderesort.com http://www.ohloh.net/accounts/osimons -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
