@disable this for structs

[Mike Parker]

On 2/28/2014 11:37 PM, Dicebot wrote:

>
> I'd write it this way:
>
> === something/bar.d ===
>
> interface Bar {}
>
> === something/barmanager.d ===
>
> import something.bar; // possibly public import
>
> void initialize();
> void terminate();
>
> === app.d ===
>
> import something.bar;
> import barmanager = something.barmanager;
>
> // refer to Bar directly and to init function via barmanager.initialize()
> =========
>
> Or, even better, turn bar into package and have something.bar.manager
> with same usage pattern.

And as a user of your library, I'm going to be extremely annoyed that I 
have to keep remembering to declare named imports to disambiguate all 
the intialize/terminate functions in all the modules that have them. If 
you're going to design your library that way, you should do it for me :)

I see modules, loosely, as a way to group immediate family and packages 
as a way to group extended family. To me, Bar and BarManager are closely 
related, so they belong in the same module. It also makes long-term 
maintenance simpler, since everything related to Bar is in one place. 
And then there's D's module-scope access to private methods/members, 
which at some level encourages this approach (and which I make good use 
of). If I were to break all of my modules up as you have in this 
example, it unnecessarily inflates the number of modules, increases the 
maintenance cost somewhat, and takes away my module access to private.

Anyway, I have a project I'm working on right now that I'll be putting 
up on github within a few weeks that serves as a more complete example. 
One of the great things about D is that it has enough room for both 
approaches.