I hope I did not leave the impression that stopping work on trunk was what I was seeking. I thought it was generally agreed some time ago that my work on properties should be integrated, for the simple reason that it is smaller and faster. It seems now that there are philosophical differences in the group about at least two issues - pull vs push parsing and design methodology (or lack of it).
[ Note that my properties handling runs faster in spite of the fact that pull parsing is *inherently* slower that push parsing. It is considerable smaller in spite of the fact that pull parsing *inherently* consumes more objects than push parsing.
I'm committed to it because it makes for more readily understood code. In this I agree with Microsoft, surprisingly enough. ]
Given that I was talking about the problems which arise from integration, including problems which I have since detected in my own properties implementations, I am surprised that I was misunderstood as seeking a switch to alt.design.
However, much of the burden of what I did say relates to the issue of what happens when the lead designer can't do it any more. I'm the one who wants better, moer readily undestandable documentation, better, more readily understood design discussion, better, more readily understood documentation of the implementation details. If you don't believe that, try looking at my (incomplete) documentation of alt.design, and my contributions in this list to design discussions.
The whole point of my urgings and example is to make it easier for new developers to come up to speed. Note that, indeed, "we have been in this situation before." We still are.
I repeat that hacking on the code is easier and more immediately rewarding than thinking through the design. The approaches are not mutually exclusive, and must be mixed, I think. But, here has been too much of the former and too little of the latter, IMO.
Welcome aboard.
Peter
Glen Mazza wrote:
Peter,
The decision to stop work in trunk--and to place all
efforts into alt-design, should be put to a vote first
by the committers. I'm quite reluctant for us to be
putting all our eggs in one basket at this time.
I want alt-design to "win" because it became the
better implementation over an optimized trunk
code--not because we kept purposefully trunk
incomplete, buggy and unoptimized so that six months
down the road we had no other choice but to go to
alt-design.
And if we kept trunk unimproved, what would happen should the "lead developer" on alt-design find out he doesn't have the time to complete his work? We've been in this situation before--this is a very time-consuming project and it could happen. We need a fallback.
What *does* work is continually modularizing the code so alt-design can better fit in component-by-component where possible, and also incorporating your findings within the trunk design so we can continually reduce the delta between the two branches.
(Besides...some of us happen to enjoy "hacking code" and optimizing it...Don't take away our fun! ;)
-- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
