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