Hauke Duden wrote:

> I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating.

Don't worry about that: experience tells me that Walter hardly ever ignores important threads in this group. He just waits a little while before deciding whether a comment is necessary at all...

Hauke Duden wrote:

> It is nice that mixins are powerful enough to make a hack possible, but IMHO using this hack regularly is a bad idea.

Nothing to add there.

Hauke Duden wrote:

> I see the mixin workaround as an ugly hack. It is neither convenient when you write the code nor is it easy to understand what the writer intended when you read it.

I think it's a very elegant hack.  Very, very little extra code is needed, the full benefit is reaped, and undesirable side effects are nowhere in sight.  I agree that a few comments are in order to describe the rationale of what's going on, but it's a very easy concept to explain, and thus understand.

> Also, putting all code in a template just to improve "importability" makes red lights go off everywhere in my head. I suspect that it might increase compile time, it might obfuscate compiling error messages and it might make it difficult for the debugger to display the code that is currently executed. It will also confuse documentation programs like doxygen and may have a similar effect on some class tree parsers in IDEs.

DMD doesn't have much trouble with templates.  Besides, the template is only instantiated once, then it's compiled into an object file just like everything else.

Doxygen, debuggers, and editors will probably be thrown for a loop, but no more so than any other use of mixins.  The fact that D is so easy to parse means that this impact can be mitigated.

> It is nice that mixins are powerful enough to make a hack possible, but IMHO using this hack regularly is a bad idea.

Friends aren't needed so frequently that one would have to resort to this on a regular basis.  public imports will cut the mustard in 99 out of 100 cases.

 -- andy

Andy Friesen wrote:
> Hauke Duden wrote:
> 
>> I see the mixin workaround as an ugly hack. It is neither convenient when you write the code nor is it easy to understand what the writer intended when you read it.
> 
> 
> I think it's a very elegant hack.

I respectfully disagree. Strongly. This abuses D's module system, with dummy modules importing other modules and using mixins to work around the module-friend-barrier. I don't call that elegant. It is inventive and shows off the power of mixins but it is not an elegant solution to the friend problem.

It's a hack to patch in missing functionality in one of the languages most basic features.

>  Very, very little extra code is needed, the full benefit is reaped, and undesirable side effects are nowhere in sight.

Except for the ones I mentioned.

>  I agree that a few comments are in order to describe the rationale of what's going on, but it's a very easy concept to explain, and thus understand.

Is it? You need to understand templates, you need to unterstand friends, you need to understand why an import won't work, you need to understand mixins and that you need a template to do a mixin. I don't think this is particularly easy to explain to a rookie programmer. Too many advanced concepts involved.

But in any case, that wasn't what I meant. I meant that it isn't obvious why the code is inside a template. That the template has no use whatsoever except for allowing the code to be mixed in, which in turn allows the modules to access each other's friends is not immediately recognizable.

>> Also, putting all code in a template just to improve "importability" makes red lights go off everywhere in my head. I suspect that it might increase compile time, it might obfuscate compiling error messages and it might make it difficult for the debugger to display the code that is currently executed. It will also confuse documentation programs like doxygen and may have a similar effect on some class tree parsers in IDEs.
> 
> 
> DMD doesn't have much trouble with templates.  Besides, the template is only instantiated once, then it's compiled into an object file just like everything else.

Yeah, but does it increase compile time? Memory overhead? I don't know, but I think it might. Remember that the template'ed code would be pretty big.

> Doxygen, debuggers, and editors will probably be thrown for a loop, but no more so than any other use of mixins.  The fact that D is so easy to parse means that this impact can be mitigated.

This would require explicit support for D. Right now you can quite often use programs that are intended for C++, juggle around some configuration options and make them work reasonably well with D. This is a very useful property, since it means that there are lots of tools to choose from for this new language.

If these tools stop working just because I need to put a template block around everything that needs friends then this is a problem.

>> It is nice that mixins are powerful enough to make a hack possible, but IMHO using this hack regularly is a bad idea.
> 
> 
> Friends aren't needed so frequently that one would have to resort to this on a regular basis.  public imports will cut the mustard in 99 out of 100 cases.

As I said before, making everything public is possible. But it also defeats the use of access control. I won't start a discussion of why access control is a good thing as this is a topic that has been discussed for decades.

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c8ta6e$2vbd$1@digitaldaemon.com...
> Andy Friesen wrote:
> > Hauke Duden wrote:
> >
> >> I see the mixin workaround as an ugly hack. It is neither convenient when you write the code nor is it easy to understand what the writer intended when you read it.
> >
> >
> > I think it's a very elegant hack.
>
> I respectfully disagree. Strongly. This abuses D's module system, with dummy modules importing other modules and using mixins to work around the module-friend-barrier. I don't call that elegant. It is inventive and shows off the power of mixins but it is not an elegant solution to the friend problem.
>
> It's a hack to patch in missing functionality in one of the languages most basic features.
>

How about extending mixin something like this:


   -- foo/bar.d --
module foo.bar; // Required.
mixin import foo.bat; // Checks foo/bat.d's module statement and strips it.

   -- foo/bat.d --
private module foo.bar; // Required.

   -- test.d --
import foo.bat; // Error: private module.
import foo.bar; // OK.


This way the compiler doesn't let you import continued module files so you don't accidentally depend on implementation differences.

Hauke Duden wrote:
> Andy Friesen wrote:
> 
>> I think it's a very elegant hack.
> 
> I respectfully disagree. Strongly. This abuses D's module system, with dummy modules importing other modules and using mixins to work around the module-friend-barrier. I don't call that elegant. It is inventive and shows off the power of mixins but it is not an elegant solution to the friend problem.

I thought the whole point of this exercise was to be able to have those "dummy modules", in which case it is hard to label them as a side effect.

>>  I agree that a few comments are in order to describe the rationale of what's going on, but it's a very easy concept to explain, and thus understand.
> 
> Is it? You need to understand templates, you need to unterstand friends, you need to understand why an import won't work, you need to understand mixins and that you need a template to do a mixin. I don't think this is particularly easy to explain to a rookie programmer. Too many advanced concepts involved.

A rookie programmer is already in waaaaay over his head if he's using friend semantics in a language he doesn't understand. :)

> But in any case, that wasn't what I meant. I meant that it isn't obvious why the code is inside a template. That the template has no use whatsoever except for allowing the code to be mixed in, which in turn allows the modules to access each other's friends is not immediately recognizable.

But you described it quite completely already.

/* ... the template [is used] for allowing the code to be mixed in,
 * which in turn allows the modules to access each other's friends ...
 */

That wasn't so bad, now was it? :)

>> DMD doesn't have much trouble with templates.  Besides, the template is only instantiated once, then it's compiled into an object file just like everything else.
> 
> 
> Yeah, but does it increase compile time? Memory overhead? I don't know, but I think it might. Remember that the template'ed code would be pretty big.

Probably, but DMD is fast enough that we can afford to burn a bit of silicon.  Template metaprogrammers will do far, far worse.

>> Doxygen, debuggers, and editors will probably be thrown for a loop, but no more so than any other use of mixins.  The fact that D is so easy to parse means that this impact can be mitigated.
> 
> This would require explicit support for D. Right now you can quite often use programs that are intended for C++, juggle around some configuration options and make them work reasonably well with D. This is a very useful property, since it means that there are lots of tools to choose from for this new language.
> 
> If these tools stop working just because I need to put a template block around everything that needs friends then this is a problem.

It's a tradeoff.  dfilter can probably be made mixin-aware without much trouble.

>> Friends aren't needed so frequently that one would have to resort to this on a regular basis.  public imports will cut the mustard in 99 out of 100 cases.
> 
> As I said before, making everything public is possible. But it also defeats the use of access control. I won't start a discussion of why access control is a good thing as this is a topic that has been discussed for decades.

My statement had absolutely nothing to do with the virtue in access control.  If module A publicly imports module B, and module C imports A, then C has access to B, through A.  When class friendship isn't an issue (the vast majority of cases, I should hope), public imports work just fine.

 -- andy

Andy Friesen wrote:

> Hauke Duden wrote:
> 
>> I see the mixin workaround
>> as an ugly hack. It is neither convenient when you write the code nor is
>> it easy to understand what the writer intended when you read it.
> 
> I think it's a very elegant hack.  Very, very little extra code is needed, the full benefit is reaped, and undesirable side effects are nowhere in sight.  I agree that a few comments are in order to describe the rationale of what's going on, but it's a very easy concept to explain, and thus understand.

The "uglyness" comes from the fact, that suddenly, there are two competing concepts of importing: the elegant "import" working with clear interfaces, and the cut-and-paste, C-style include, realized by the proposed hack. It is like in the good old days, when C introduced clean loops. Of course, you could still use goto and many people did because they were so used to it. Sideffects? None! The only danger lies in using it without the necessary discipline.

Once in a while "goto" really is the best way for a problem. But at least we all know, that it only is the last resort and should be well-justified.

Andy Friesen wrote:
> Hauke Duden wrote:
> 
>> Andy Friesen wrote:
>>
>>> I think it's a very elegant hack.
>>
>>
>> I respectfully disagree. Strongly. This abuses D's module system, with dummy modules importing other modules and using mixins to work around the module-friend-barrier. I don't call that elegant. It is inventive and shows off the power of mixins but it is not an elegant solution to the friend problem.
> 
> 
> I thought the whole point of this exercise was to be able to have those "dummy modules", in which case it is hard to label them as a side effect.

No. I'd like the logical concept of a module to be separated from the "physical" concept of a file. My favored solution so far is to allow directories to become modules, with all the .d files in them making up the module contents.

Note that there is a considerable difference to templating all files and mixing them together.

>> But in any case, that wasn't what I meant. I meant that it isn't obvious why the code is inside a template. That the template has no use whatsoever except for allowing the code to be mixed in, which in turn allows the modules to access each other's friends is not immediately recognizable.
> 
> 
> But you described it quite completely already.
> 
> /* ... the template [is used] for allowing the code to be mixed in,
>  * which in turn allows the modules to access each other's friends ...
>  */
> 
> That wasn't so bad, now was it? :)

Except that this comment will almost never be there. I'm talking about the practical reality of big multi-programmer projects here ;).

>> As I said before, making everything public is possible. But it also defeats the use of access control. I won't start a discussion of why access control is a good thing as this is a topic that has been discussed for decades.
> 
> 
> My statement had absolutely nothing to do with the virtue in access control.  If module A publicly imports module B, and module C imports A, then C has access to B, through A.  When class friendship isn't an issue (the vast majority of cases, I should hope), public imports work just fine.

Sorry for the misunderstanding.

Anyway friends are not so rare in libraries that want to be as "bullet-proof" against misuse as possible. And the main issue isn't that the problem occurs often, but that when it occurs there is no good solution.

Hauke

On Mon, 24 May 2004 13:25:30 -0400, Vathix wrote:
> How about extending mixin something like this:
> 
> 
>    -- foo/bar.d --
> module foo.bar; // Required.
> mixin import foo.bat; // Checks foo/bat.d's module statement and strips
> it.
> 
>    -- foo/bat.d --
> private module foo.bar; // Required.

I would be nice if you could specify multiple modules, or an entire
package, eg:
private module foo.*;

Also, wouldn't one also need some mechanism to protect against mixing in the same template more than once?

I think I separate import/export mechanism is a cleaner solution.  I don't think mixins are much better (for this) than running a preprocessor to combine a few files.  With mixins, what happens if two different public modules mixin a common private class.  Wouldn't this basically duplicate the code?  Worse yet, what if these two public modules were made private instead.  What happens if a single public module mixins both these to privates?  Will the single private class appear twice, and thus produce a compile error?  Given, there are ways to avoid this with a different design, but a separate mechanism would allow greater flexibility.  Instead of making the programmer worry about where the code is being included into, (s)he may instead design a logical structure.

My two cents.

Norbert Nemec wrote:
> Andy Friesen wrote:
> 
> 
>>Hauke Duden wrote:
>>
>>
>>>I see the mixin workaround
>>>as an ugly hack. It is neither convenient when you write the code nor is
>>>it easy to understand what the writer intended when you read it.
>>
>>I think it's a very elegant hack.  Very, very little extra code is
>>needed, the full benefit is reaped, and undesirable side effects are
>>nowhere in sight.  I agree that a few comments are in order to describe
>>the rationale of what's going on, but it's a very easy concept to
>>explain, and thus understand.
> 
> 
> The "uglyness" comes from the fact, that suddenly, there are two competing
> concepts of importing: the elegant "import" working with clear interfaces,
> and the cut-and-paste, C-style include, realized by the proposed hack. It
> is like in the good old days, when C introduced clean loops. Of course, you
> could still use goto and many people did because they were so used to it.
> Sideffects? None! The only danger lies in using it without the necessary
> discipline.

Okay, I see the problem now.  However elegant it may be, it remains a hack.

Would an access modifier for package scope suffice?

 -- andy