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.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

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

John Reimer wrote:
> Hello Derek,
>> Just thinking out aloud ...
>>
>> If two modules import each other and this can be 'fixed' by instead
>> having both modules as a single module, what is stopping the compiler
>> from just pretending that they are a single module for compilation
>> purposes?
>>
>> This does assume that they are to be compiled at the same time rather
>> than one-file-at-a-time.
>>
> 
> 
> Interesting idea. :)
> 
> Maybe there would be issues with module ctors and __FILE__/__LINE__ expressions too?
> Also it may mess up module info, debug, and other object attributes.
> 
> -JJR

This would work with two modules.

How would it work with more than that? You'd have to come up with a complete import graph (which you already need, I assume), search it for cycles, then, for each cycle, resolve it by combining static constructors.

It should work.