www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module with multiple files

reply "Vathix" <vathixSpamFix dprogramming.com> writes:
This is an idea that would allow modules to span multiple files. In
foo/bat.d source file, use:
   export module foo.bar;
and foo/bat.d will continue the module foo.bar.

The actual foo.bar module will have to (public) import this file to make it
accessible, or specify them in its module list like:
   module foo.bar, foo.bat, foo.etc;
or
   module foo.bar: foo.bat, foo.etc;

If any other module tries to import foo.bat, it will get an error message
something like:
   Cannot import foo.bat, import foo.bar instead.

foo/bat.d automatically gets the symbols of foo.bar as if it was imported,
and has access to its private parts; exactly like it was the same file.

Perhaps export isn't the best word to use, but I figured import/export sound
good together. Maybe it could be:
   continue module foo.bar;
:)

--
Christopher E. Miller
May 21 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Vathix" <vathixSpamFix dprogramming.com> wrote in message
news:c8mmgp$2ep6$1 digitaldaemon.com...
 This is an idea that would allow modules to span multiple files. In
 foo/bat.d source file, use:
    export module foo.bar;
 and foo/bat.d will continue the module foo.bar.

 The actual foo.bar module will have to (public) import this file to make
it
 accessible, or specify them in its module list like:
    module foo.bar, foo.bat, foo.etc;
 or
    module foo.bar: foo.bat, foo.etc;

 If any other module tries to import foo.bat, it will get an error message
 something like:
    Cannot import foo.bat, import foo.bar instead.

 foo/bat.d automatically gets the symbols of foo.bar as if it was imported,
 and has access to its private parts; exactly like it was the same file.

 Perhaps export isn't the best word to use, but I figured import/export
sound
 good together. Maybe it could be:
    continue module foo.bar;
 :)

 --
 Christopher E. Miller
Good idea. Unfortunately, the module/multiple file problem will not go away anytime soon.
May 22 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c8nkvp$rvi$1 digitaldaemon.com>, Achilleas Margaritis says...

Good idea. Unfortunately, the module/multiple file problem will not go away
anytime soon.
Last time I posted this, nobody commented, so I'll post this again. I *THINK* we can _already_ do multiple files per module, if my theory is correct. Here's the plan: --------------------------------------------------------------------- Title: Re: 'Package' access attribute is needed. Author: Arcane Jill <Arcane_member pathlink.com> Date: Thu, 20 May 2004 23:28:29 +0000 (UTC) Problem solved, I think. I haven't actually tried this, but I don't see any reason why it shouldn't work. Here's how you do it. Suppose you wish to have four separate source files, which we shall call call john.d, paul.d, george.d and ringo.d. You also wish that each of these source files should be able to access private data in each of the other source files, so that the collection of source files forms a single module, which we shall call beatles. Easy peasy. The content of john.d becomes:
       module john;

       template TJohn
       {
           public
           {
               // public declarations
           }

           private
           {
               // package-level declarations
           }
       }
That is, you wrap the WHOLE FILE inside a parameterless template declaration, and remove any import statements. The content of paul.d, george.d and ringo.d are similarly wrapped in a template declaration. Finally, you create one extra source file for the package as a whole - beatles.d - whose content is as follows:
       module beatles;

       // imports required by ANY of the other source files go here

       import john;
       import paul;
       import george;
       import ringo;

       mixin TJohn;
       mixin TPaul;
       mixin TGeorge;
       mixin TRingo;
I think that should do the trick. Arcane Jill
May 23 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:

 Last time I posted this, nobody commented, so I'll post this again. I
 *THINK* we can _already_ do multiple files per module, if my theory is
 correct. Here's the plan:
 
....
 
 I think that should do the trick.
That "trick" really looks like trying very hard to press some way of modularization onto D. If you can split a module into file so cleanly, you should really consider to split it into separate modules right from the beginning. If I understand the specs (http://www.digitalmars.com/d/module.html) correctly: -------------------------------------- If the import is private, such as: module abc; private import def; then def is not searched when another module imports abc. -------------------------------------- then a normal import will already reexport all the imported symbols. (This should perhaps be documented more clearly?) If a module grows too large for one file, you should just try to split out parts of it into different modules and import those.
May 24 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c8s75j$18u0$1 digitaldaemon.com>, Norbert Nemec says...

That "trick" really looks like trying very hard to press some way of
modularization onto D. If you can split a module into file so cleanly, you
should really consider to split it into separate modules right from the
beginning.
For the record, it was not I who wanted such a split - I merely proposed a way of doing it. My own project do not require, nor use, this trick. In effect, I'm using suggesting mixin as a poor person's #include. That is, instead of:
       #include "otherfile.c"
we can write:
       import otherfile;
       mixin TOtherFile;
providing that the contents of otherfile.d are wrapped inside template TOtherFile. But I didn't know about private imports. Thanks for bringing that one to my attention. Sounds like a good way to achieve something similar. Arcane Jill
May 24 2004
parent reply Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In article <c8s8ct$1ci3$1 digitaldaemon.com>, Arcane Jill says...
In article <c8s75j$18u0$1 digitaldaemon.com>, Norbert Nemec says...

That "trick" really looks like trying very hard to press some way of
modularization onto D. If you can split a module into file so cleanly, you
should really consider to split it into separate modules right from the
beginning.
For the record, it was not I who wanted such a split - I merely proposed a way of doing it. My own project do not require, nor use, this trick. In effect, I'm using suggesting mixin as a poor person's #include. That is, instead of:
       #include "otherfile.c"
we can write:
       import otherfile;
       mixin TOtherFile;
providing that the contents of otherfile.d are wrapped inside template TOtherFile. But I didn't know about private imports. Thanks for bringing that one to my attention. Sounds like a good way to achieve something similar. Arcane Jill
All the above posts lead me to one thought: multiple file/module needs direct support from the language. 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. It's like C++ and strings: every library has its own version.
May 24 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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)
May 24 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Norbert Nemec wrote:
 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.)
That is the whole point, of the discussion (at least for me): the need for "friend" code to be in the same module, hence in the same file. This just isn't practical. 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. But I'm repeating myself... I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating. Hauke
May 24 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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.
Or you could just try my sugguestion.
But I'm repeating myself...
But I'm repeating myself
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. Don't you see? The statements:
       mixin TStuffFromFile1
       mixin TStuffFromFile2
can achieve the same thing as #include in C. If the thing you are including contains stuff wrapped in the private attribute, then it becomes private in the including file. That is, the including file effectively becomes the concatenation of the included files. In other words - the compiler SEES one big file, in which the notion of private is spread across the whole of that conceptual file (so anything declared private in one file will be visible to any other similarly included file) - but you WRITE many files, which can be version-controlled separatly. When Walter invented mixins, he also solved this problem. This is a powerful language feature, and I'm not sure that its full power has been fully appreciated. Arcane Jill
May 24 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 24 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
May 24 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
May 24 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 24 2004
next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
"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.
May 24 2004
parent DemmeGod <me demmegod.com> writes:
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.
May 24 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
May 24 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 24 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
Jun 04 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
May 24 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
May 24 2004
next sibling parent DemmeGod <me demmegod.com> writes:
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.
May 24 2004
prev sibling next sibling parent "Zz" <Zz Zz.com> writes:
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
May 24 2004
prev sibling next sibling parent Brian H <Brian_member pathlink.com> writes:
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
May 24 2004
prev sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
May 25 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
Jun 04 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
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...
May 24 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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. :/
Jun 04 2004