On Mon, 24 May 2004 14:53:58 -0700, Andy Friesen wrote:
> Okay, I see the problem now.  However elegant it may be, it remains a hack.
> 
> Would an access modifier for package scope suffice?
> 
>   -- andy

In my opinion, yes.

It's been some time since I last used modula-2, but following this thread I can see that Writh really got it right.

In case your interested:

Program Organization and Modules http://www.csc.twu.ca/rsbook/Ch6/index.html

What Did You Say a Module is? http://www.csc.twu.ca/rsbook/Ch6/index.html

Modules and Design Considerations http://www.csc.twu.ca/rsbook/Ch6/index.html

Draw you own conclusions.

Zz


"Andy Friesen" <andy@ikagames.com> wrote in message news:c8tqnd$p20$1@digitaldaemon.com...
> 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

>
>Okay, I see the problem now.  However elegant it may be, it remains a hack.
>
>Would an access modifier for package scope suffice?
>
>  -- andy

You mean there isn't one?  What do packages do if they don't allow modules to interact based on package membership?  I thought I had just missed something in the document on packages.  It makes them sound like nothing more than extra namespace for modules.

Brian

Andy Friesen 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?

Yes, I think that would be another good way to solve this.

Hauke

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8slh0$1v4j$1@digitaldaemon.com...
> Achilleas Margaritis wrote:
>
> > All the above posts lead me to one thought: multiple file/module needs direct support from the language.
>
> What would it be needed for? Just split your file in whatever way you like and import all parts into one module which is then offered for import in programs etc.
>
> The feature that might be interesting would be "friend" modules (which would be mostly similar to the recent proposal of package-private items.)
>
> > When every programmer offers his/her own version of a solution to the same problem, leading to various incompatibilities between libraries, then it is time for the language designer to take notice and solve the problem cleanly through a language modification/addition.
>
> If there is a clean solution possible with the current features of the language, it is just as good to promote that solution for general use.
>
> > It's like C++ and strings: every library has its own version.
>
> That's because C++ itself did not offer a clean solution for strings in the beginning. (basic_string just came too late)

Nor is it anywhere near good enough. :/

Agreed. We don't want D to become like C++, where problems are fixed by the most abstruse template meta-programming techniques. (Of course, I've just written a book covering many of the techniques for solving C++'s deficiencies, which I highly recommend you all to buy and read come September. But then I hope you'll be even more keen not to let D also end up as Wild Woman's (or man's!) Knitting.)

Percy the Promoter

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

-----------------------------------------------------


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c8suiu$2d3a$1@digitaldaemon.com...
> Arcane Jill wrote:
> >>It may look like a minor annoyance, but in everyday live this means that big projects will have to make all the "friend" stuff public, even if that is dangerous and allows misuse. The other alternative, having huge files with tens of thousands of lines of code, would be a major problem in a multi-programmer environment.
> >
> >>I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating.
> >
> >
> > The problem doesn't exist because mixins already solve it. The language can already do what you want.
>
> Not really. Don't take this personally, but 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.
>
> 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.
>
> It is nice that mixins are powerful enough to make a hack possible, but IMHO using this hack regularly is a bad idea.
>
> 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.
>
> >  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.

You don't even need these arguments. The foregoing points are compelling.