DMD 1.038 and 2.022 releases

John Reimer terminal.node at gmail.com
Mon Dec 22 13:45:10 PST 2008


Hello Lars,

> John Reimer wrote:
> 
>> Since I'm not a Java developer (or, to be honest, any kind of
>> developer
>> beyond a language enthusiast), I'd say I'm not in a good position to
>> question the design decision of Java source that uses cyclic
>> dependencies
>> (such as SWT).
>> All I can say is that I can agree that it looks like a bad idea
>> because
>> I can certainly see the painful problems it can produce.
> I haven't used SWT enough, and certainly not looked much at the
> internals, to say whether I consider this a problem there or not.
> However, I've been using GWT for a while, and there was this widget I
> wanted to use. Unfortunately for me it missed a feature (or the
> ability to turn off a feature really) that I needed. And since it
> wasn't possible to fix this by subclassing either, I had to
> reimplement it all. Now, this wouldn't be so bad, but as it turned out
> it depended on a few other classes, and 4 or 5 of those had a back
> dependency on the main widget, meaning I had to reimplement those too.
> As it was, the discerning functionality of the main widget could have
> (should have) been put into an interface, the helper classes depend on
> that interface instead, the feature exposed, and by that time it would
> already be of much higher quality. Some more work would probably be
> needed with regards to the helper classes, but in the original code
> all of them could as well have been private classes of the widget.
> 
> It is definately much more difficult to properly design code such that
> it has fewer cyclic dependencies, but I think that the choice between
> bottom-up or top-down approach will affect this a lot. If you start at
> the bottom, you're probably more likely to get a good result in this
> respect, just because there is only lower-level functionality to pick
> from when building the higher-level components. I do of course
> understand that bottom-up may not be the most obvious choice if
> high-level functionality is what you need in the first place.
> 



Thanks for the explanation.  I forgot about interfaces, which is probably 
a pretty big "OOP's" on my part ;-D.  I imagine it to be a good way to solve 
this particular import interdependency problem in D, although, depending 
on the project, the approach may prove insufficient.

Alas, this is the unforunate thing about porting large software projects 
and that one continues to urk me: you rarely can afford to change the design 
in such away that it adopts the most sane approach for a given situation 
(or the given language you've ported it to).  So it seems that the ideal 
of good design is sometimes stymied by project requirements and apparent 
language compromises for platform technologies.

My problem with most projects I work on is the (nearly) insatiable desire 
to have it done right or at least to look "right".  However, it is strangely 
apparent that "right" isn't always clear, but "wrong", done thoroughly, is 
horrifyingly obvious.  Porting software has been hard because I've dearly 
wanted to fixup all things that I perceive to be messy, even at the expense 
of "if it ain't broke, don't fix it".  This mentality, naturally, compromises 
productivity.  However, practicality inevitably overrides many decisions 
to indulge the ideal of productivity. :)

The good news is that, after seeing the problems incurred by design decisions, 
I feel more motivated to understand the meaning of the concept of "good design". 


-JJR




More information about the Digitalmars-d-announce mailing list