On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard julliard@winehq.org wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
i would imagine that inefficient is the _last_ thing on the list of priorities. "technically correctly fulfilling the semantics" i would imagine would be the highest priority.
"efficient" and "nice" can always be done later, yes?
No, in many cases efficiency needs to be taken into account in the design phase. You can't just add it later.
sure you can. by redesigning.
and because the functionality is encapsulated, fulfilling the requirements behind a well-documented immutable API, other teams can move forward (even if they're complaining about speed) opening up entirely new areas of functionality and opportunities for Wine, bringing in more interested developers, one of whom _might_ be skilled enough and interested enough to go "that design - it's crap! i can do better!" and thus you get a better, more efficient and much more acceptable ...
_incremental_ improvement.
so by shutting the door on an idea because it's "inefficient" and "not nice" you risk losing my input, and an opportunity to get the ball rolling.
i'm not interested at this stage in making a "nice or efficient" design, i'm interested in getting a "technically correct" design - and a reliable, working implementation.
l.