www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'Package' access attribute is needed.

reply Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In the GUI library I am making, I want to have one class per module, so as that
the programmer declares 'import bar.foo' with 'foo' being the name of the class;


But at the same time, I want class 'Foo' to access the private fields of another
class 'T'. This is impossible, because they are in different modules.

In other words, I want the analogy of modules to classes to be 1 to 1: it is
easier for the programmer (if he remembers the name of the class, then he
remembers the name of the module), and it is easier for me, as I keep source
files smaller.

Maybe D could have a 'package' access attribute which works just like in Java:
the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute, although
parameterized to the type of the class that is friend. I propose the following
grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it would
frustrate many developers who would want module names to correspond to class
names (and for gui libs, there are lots of classes). Again, this is a small
change and easily implementable, but it would save lots of developers from lots
of frustration.
May 14 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Achilleas Margaritis wrote:

In the GUI library I am making, I want to have one class per module, so as that
the programmer declares 'import bar.foo' with 'foo' being the name of the class;


But at the same time, I want class 'Foo' to access the private fields of another
class 'T'. This is impossible, because they are in different modules.

In other words, I want the analogy of modules to classes to be 1 to 1: it is
easier for the programmer (if he remembers the name of the class, then he
remembers the name of the module), and it is easier for me, as I keep source
files smaller.

Maybe D could have a 'package' access attribute which works just like in Java:
the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute, although
parameterized to the type of the class that is friend. I propose the following
grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it would
frustrate many developers who would want module names to correspond to class
names (and for gui libs, there are lots of classes). Again, this is a small
change and easily implementable, but it would save lots of developers from lots
of frustration.



  

module hidden; //Hidden data sharing here class pA {} class pB {} module A; private import hidden; class A : pA {} module B; private import hidden; class B : pB {} In other words, I suggest re-thinking your design. -- -Anderson: http://badmama.com.au/~anderson/
May 14 2004
next sibling parent reply Achilleas Margaritis <Achilleas_member pathlink.com> writes:
In article <c82l4b$gau$1 digitaldaemon.com>, J Anderson says...
Achilleas Margaritis wrote:

In the GUI library I am making, I want to have one class per module, so as that
the programmer declares 'import bar.foo' with 'foo' being the name of the class;


But at the same time, I want class 'Foo' to access the private fields of another
class 'T'. This is impossible, because they are in different modules.

In other words, I want the analogy of modules to classes to be 1 to 1: it is
easier for the programmer (if he remembers the name of the class, then he
remembers the name of the module), and it is easier for me, as I keep source
files smaller.

Maybe D could have a 'package' access attribute which works just like in Java:
the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute, although
parameterized to the type of the class that is friend. I propose the following
grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it would
frustrate many developers who would want module names to correspond to class
names (and for gui libs, there are lots of classes). Again, this is a small
change and easily implementable, but it would save lots of developers from lots
of frustration.



  

module hidden; //Hidden data sharing here class pA {} class pB {} module A; private import hidden; class A : pA {} module B; private import hidden; class B : pB {} In other words, I suggest re-thinking your design. -- -Anderson: http://badmama.com.au/~anderson/

I haven't thought of this solution. I might use it in the end, but it bothers me, because I want my code to be well-written.
May 14 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Achilleas Margaritis wrote:

I haven't thought of this solution. I might use it in the end, but it bothers
me, because I want my code to be well-written.
  

the programmer from making bad design decisions. -- -Anderson: http://badmama.com.au/~anderson/
May 14 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 This seems to be an oxymoron to me.  D's modules design tries to help
 the programmer from making bad design decisions.

Yet I can't have module == class.
May 15 2004
parent "Phill" <phill pacific.net.au> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c84ppl$kg5$1 digitaldaemon.com...
 This seems to be an oxymoron to me.  D's modules design tries to help
 the programmer from making bad design decisions.

Yet I can't have module == class.

module.
May 15 2004
prev sibling parent reply DemmeGod <me demmegod.com> writes:
J Anderson wrote:

 Achilleas Margaritis wrote:
 
In the GUI library I am making, I want to have one class per module, so as
that the programmer declares 'import bar.foo' with 'foo' being the name of
the class;


But at the same time, I want class 'Foo' to access the private fields of
another class 'T'. This is impossible, because they are in different
modules.

In other words, I want the analogy of modules to classes to be 1 to 1: it
is easier for the programmer (if he remembers the name of the class, then
he remembers the name of the module), and it is easier for me, as I keep
source files smaller.

Maybe D could have a 'package' access attribute which works just like in
Java: the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute,
although parameterized to the type of the class that is friend. I propose
the following grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it
would frustrate many developers who would want module names to correspond
to class names (and for gui libs, there are lots of classes). Again, this
is a small change and easily implementable, but it would save lots of
developers from lots of frustration.



  

module hidden; //Hidden data sharing here class pA {} class pB {} module A; private import hidden; class A : pA {} module B; private import hidden; class B : pB {} In other words, I suggest re-thinking your design.

Something like that doesn't stop a programmer using the API from importing hidden. I really like Ben's idea of: public (package or module) to expose a field (or class, why not?) to another package or module. I would even take it a step further, and say one should be able to specify a list of packages or modules. D, however, is not Java, which is really what an idea like this is for/from. The way I understand it, each module should be a separate and distinct entity, and this idea of sharing privates between modules is, for lack of a better word... wrong. This design methodology doesn't sit well with the Java guys since we like splitting things up into lots and lots of files. I see two solutions that seems to stay better in line with D design methodology: 1) Come up with some method of combining files into one module. I don't like this one however, since it breaks the idea of one module to one file. 2) Package access for modules. Make package access keyword that applies to modules. This way, programmers can clearly separate their API from the internal backend, should they choose to put it in separate files (modules.) Let's face it D guys: sometimes it makes a lot of sense for two modules to share an internal module. Not every module can be completely separate- layered programming, right? (Yeah, I just made up that term) I wonder what the ratio of Java guys to C/C++ guys involved in D is... DemmeGod Sorry if I reworded a lot... I was a manager in a past life.
May 14 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
DemmeGod wrote:

J Anderson wrote:

  

Achilleas Margaritis wrote:

    

In the GUI library I am making, I want to have one class per module, so as
that the programmer declares 'import bar.foo' with 'foo' being the name of
the class;


But at the same time, I want class 'Foo' to access the private fields of
another class 'T'. This is impossible, because they are in different
modules.

In other words, I want the analogy of modules to classes to be 1 to 1: it
is easier for the programmer (if he remembers the name of the class, then
he remembers the name of the module), and it is easier for me, as I keep
source files smaller.

Maybe D could have a 'package' access attribute which works just like in
Java: the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute,
although parameterized to the type of the class that is friend. I propose
the following grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it
would frustrate many developers who would want module names to correspond
to class names (and for gui libs, there are lots of classes). Again, this
is a small change and easily implementable, but it would save lots of
developers from lots of frustration.



 

      

module hidden; //Hidden data sharing here class pA {} class pB {} module A; private import hidden; class A : pA {} module B; private import hidden; class B : pB {} In other words, I suggest re-thinking your design.

Something like that doesn't stop a programmer using the API from importing hidden.

There is if you make it a library. -- -Anderson: http://badmama.com.au/~anderson/
May 14 2004
parent DemmeGod <me demmegod.com> writes:
J Anderson wrote:

 DemmeGod wrote:
 
J Anderson wrote:

  

Achilleas Margaritis wrote:

    

In the GUI library I am making, I want to have one class per module, so
as that the programmer declares 'import bar.foo' with 'foo' being the
name of the class;


But at the same time, I want class 'Foo' to access the private fields of
another class 'T'. This is impossible, because they are in different
modules.

In other words, I want the analogy of modules to classes to be 1 to 1:
it is easier for the programmer (if he remembers the name of the class,
then he remembers the name of the module), and it is easier for me, as I
keep source files smaller.

Maybe D could have a 'package' access attribute which works just like in
Java: the declaration can be accessed by anyone on the same module.

Another solution would be to introduce the 'friend' access attribute,
although parameterized to the type of the class that is friend. I
propose the following grammar:

FriendAttribute:
"friend" "(" IdentifierList ")"

Example:
class Foo {
friend(Bar, Other):
int m_data;
}

I think this is really needed in the language; as it is right now, it
would frustrate many developers who would want module names to
correspond to class names (and for gui libs, there are lots of classes).
Again, this is a small change and easily implementable, but it would
save lots of developers from lots of frustration.



 

      

module hidden; //Hidden data sharing here class pA {} class pB {} module A; private import hidden; class A : pA {} module B; private import hidden; class B : pB {} In other words, I suggest re-thinking your design.

Something like that doesn't stop a programmer using the API from importing hidden.

There is if you make it a library.

Good point... package access level is only important in programming libs, which is something I spend most of my time doing. A good library isn't just the stuff you expose, it's also the stuff you don't. If a library has a lot of it's internal stuff exposed and readily available, the whole library is made more confusing for the user (errr... programmer).
May 14 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 Something like that doesn't stop a programmer using the API from importing
 hidden.

 I really like Ben's idea of:
 public (package or module) to expose a field (or class, why not?) to

 package or module.  I would even take it a step further, and say one

 be able to specify a list of packages or modules.

I don't care if it is 'friend(identifier-list)' or 'public(identifier-list)' as long as it does the job.
 D, however, is not Java, which is really what an idea like this is

I don't think it is important for D not to be Java or to be Java. The most important thing is for D to the best language. The way I see it, there is a chance here for the programming language ever.
 The way I understand it, each module should be a separate and distinct
 entity, and this idea of sharing privates between modules is, for lack of

 better word... wrong.  This design methodology doesn't sit well with the
 Java guys since we like splitting things up into lots and lots of files.

So if modules sharing privates is wrong, D should allow me to import specific classes then.
May 15 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Achilleas Margaritis wrote:

The way I understand it, each module should be a separate and distinct
entity, and this idea of sharing privates between modules is, for lack of
    

better word... wrong.  This design methodology doesn't sit well with the
Java guys since we like splitting things up into lots and lots of files.
    

So if modules sharing privates is wrong, D should allow me to import specific classes then.

You can. Only if your sharing information between these classes is it *wrong* to expect these classes not to be visible. Its *wrong* to treat a module as a class. The idea is to try to reduce coupling, not create it. Its hard to explain but once you get the concept you'll thank us later. -- -Anderson: http://badmama.com.au/~anderson/
May 15 2004
prev sibling parent DemmeGod <me demmegod.com> writes:
Achilleas Margaritis wrote:

 Something like that doesn't stop a programmer using the API from
 importing hidden.

 I really like Ben's idea of:
 public (package or module) to expose a field (or class, why not?) to

 package or module.  I would even take it a step further, and say one

 be able to specify a list of packages or modules.

I don't care if it is 'friend(identifier-list)' or 'public(identifier-list)' as long as it does the job.
 D, however, is not Java, which is really what an idea like this is

I don't think it is important for D not to be Java or to be Java. The most important thing is for D to the best language. The way I see it, there is a chance here for the programming language ever.
 The way I understand it, each module should be a separate and distinct
 entity, and this idea of sharing privates between modules is, for lack of

 better word... wrong.  This design methodology doesn't sit well with the
 Java guys since we like splitting things up into lots and lots of files.

So if modules sharing privates is wrong, D should allow me to import specific classes then.

Not specific classes, but modules. You should be able to have private (or package, whatever) modules, which can only be imported by modules in the same package. This way, shared privates are clearly separated from the public stuff, or non-shared privates. I'm not saying that it seems to be perfectly inline with D design methodology, but it's closer to it than package-level access at the class or field level.
May 15 2004
prev sibling next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
[snip]
 Maybe D could have a 'package' access attribute which works just like in

 the declaration can be accessed by anyone on the same module.

You probably don't mean "module" since that is what private does. Remember a module in D is a file, not a directory of files.
 Another solution would be to introduce the 'friend' access attribute,

 parameterized to the type of the class that is friend. I propose the

 grammar:

 FriendAttribute:
 "friend" "(" IdentifierList ")"

 Example:
 class Foo {
 friend(Bar, Other):
 int m_data;
 }

 I think this is really needed in the language; as it is right now, it

 frustrate many developers who would want module names to correspond to

 names (and for gui libs, there are lots of classes). Again, this is a

 change and easily implementable, but it would save lots of developers from

 of frustration.

Instead of adding "friend" another option is to extend the concept of "public" to include a prefix like so public(identifier) ... When a module imports such a declaration if the string identifier is a prefix of the module name then the decaration is visible and otherwise it isn't. For example file pkg/cls.d module pkg.cls; public(pkg) int m_data; file pkg/cls2.d module pkg.cls2; import pkg.cls; // m_data is visible file cls3.d module cls3; import pkg.cls; // m_data is not visible The precedent for this syntax is the extern(LinkageType) syntax. A couple design issues I can think of is 1) if identifier~"." should be used as the prefix instead of just identifier. 2) use private(..) instead of public(..) I prefer using "public" over "private" because it gives "public" a reason for existing (since the default protection attribute is public the only use for "public" now is to document code for people who don't know the D default) and since the concept is easier to remember: public in blah vs private in not-blah
May 14 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
I totally agree. I posted about this a while back because I also like to 
have one class per file. Got no comment from Walter, so I guess he was 
waiting to see how important this issue is. Thanks for bringing it up 
again ;).

IMHO a JAVA-like package attribute is a good solution for this. Not as 
hackish as C++'s friend stuff and it integrates cleanly with the other 
access attributes.


Achilleas Margaritis wrote:
 In the GUI library I am making, I want to have one class per module, so as that
 the programmer declares 'import bar.foo' with 'foo' being the name of the
class;
 
 
 But at the same time, I want class 'Foo' to access the private fields of
another
 class 'T'. This is impossible, because they are in different modules.
 
 In other words, I want the analogy of modules to classes to be 1 to 1: it is
 easier for the programmer (if he remembers the name of the class, then he
 remembers the name of the module), and it is easier for me, as I keep source
 files smaller.
 
 Maybe D could have a 'package' access attribute which works just like in Java:
 the declaration can be accessed by anyone on the same module.
 
 Another solution would be to introduce the 'friend' access attribute, although
 parameterized to the type of the class that is friend. I propose the following
 grammar:
 
 FriendAttribute:
 "friend" "(" IdentifierList ")"
 
 Example:
 class Foo {
 friend(Bar, Other):
 int m_data;
 }
 
 I think this is really needed in the language; as it is right now, it would
 frustrate many developers who would want module names to correspond to class
 names (and for gui libs, there are lots of classes). Again, this is a small
 change and easily implementable, but it would save lots of developers from lots
 of frustration.
 
 
 

May 14 2004
next sibling parent reply mike parker <mike aldacron.com> writes:
Hauke Duden wrote:
 I think this is really needed in the language; as it is right now, it 
 would
 frustrate many developers who would want module names to correspond to 
 class
 names (and for gui libs, there are lots of classes). Again, this is a 
 small
 change and easily implementable, but it would save lots of developers 
 from lots
 of frustration.


I think it's not needed at all. When coding in Java, I don't think in C++. D isn't Java, and it isn't C++. When designing a D app, think in D. It's not that hard of an adjustment to get used to using module-levle privates in place of package protection and friends. The whole idea of one class per file in Java is not necessarily because it's a better design, but because it's the convention when using Java (it's possible to have more than one class per file in Java actually). We use package protection in Java because that's the mechanism provided. Likewise the friend keyword in C++. D provides the same functionality. If you adjust your train of thought (think in D!) you can accomplish what you need easily without frustration.
May 14 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
mike parker wrote:
 The whole idea of one class per file in Java is not necessarily because 
 it's a better design, but because it's the convention when using Java 
 (it's possible to have more than one class per file in Java actually). 
 We use package protection in Java because that's the mechanism provided. 
 Likewise the friend keyword in C++. D provides the same functionality. 
 If you adjust your train of thought (think in D!) you can accomplish 
 what you need easily without frustration.

My whole idea of using one class per file is that I can easily find the file that contains a specific class and that the files do not grow to tens of thousands of lines. Sourcecode control systems also work better with many smaller files, since then they don't have to merge that often. My reasons for wanting this are simple code maintenance issues. These kinds of things become important for big projects. Hauke
May 14 2004
next sibling parent reply mike parker <mike aldacron.com> writes:
Hauke Duden wrote:

 My whole idea of using one class per file is that I can easily find the 
 file that contains a specific class and that the files do not grow to 
 tens of thousands of lines.
 
 Sourcecode control systems also work better with many smaller files, 
 since then they don't have to merge that often.
 
 My reasons for wanting this are simple code maintenance issues. These 
 kinds of things become important for big projects.

From this perspective I will grudgingly agree ;-) I'll admit, in a project I'm currently working on I stumbled into a situation where package level protection would have been real handy. Even so, I'm starting to grow accustomed to the D way. I like cutting down on the number of files. It seems that right now the concept of a package in D is nothing more than a namespace for modules. The question is, would a keyword for package protection add more utility without causing a breakdown in the intended use of modules? I don't think that's possible. Give us the keyword, and soon D packages will be treated as 'modules', while the original module idea slowly fades away. Considering that the majority of us are coming from C++ and Java, the idea of one class per file is something we've grown accustomed too (for maintenance, readability, desgin paradigms, or whatever reason). If we can do it easily, we will.
May 15 2004
next sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 It seems that right now the concept of a package in D is nothing more
 than a namespace for modules. The question is, would a keyword for
 package protection add more utility without causing a breakdown in the
 intended use of modules? I don't think that's possible. Give us the
 keyword, and soon D packages will be treated as 'modules', while the
 original module idea slowly fades away.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed. Walter originally thought "one module contains everything it needs". I totally agree with that. The problem is that a module is not equal to a file. Why does it have to be ? a module is nothing more than a collection of code and data that are closely related...(also a property of classes, by the way). But why should all the code reside in one file ? there is no real reason. In fact, there are many reasons why module code should be in different files...and maintenance/source control is one of them, and a very important one, at least for software companies. To give you a real-world example: the Linux kernel is thousands of lines of code, in hundrends of files, and many files contain nothing more than one declaration or two. Do you think this is by accident ? it is not. In fact, it is easier to maintain the kernel that way. Imagine if the Linux kernel would be made in D: tens of files, each one with thousands of lines of code...a real source control nightmare. I think this is a major problem for D and it needs to be addressed as soon as possible. I am sure Walter has big plans for D (i.e. to be used in big and serious projects).
May 15 2004
next sibling parent "Phill" <phill pacific.net.au> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:c84rni$mtv$1 digitaldaemon.com...
 It seems that right now the concept of a package in D is nothing more
 than a namespace for modules. The question is, would a keyword for
 package protection add more utility without causing a breakdown in the
 intended use of modules? I don't think that's possible. Give us the
 keyword, and soon D packages will be treated as 'modules', while the
 original module idea slowly fades away.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed. Walter originally thought "one module contains everything it needs". I totally agree with that. The problem is that a module is not equal to a file. Why does it have to

 ? a module is nothing more than a collection of code and data that are
 closely related...(also a property of classes, by the way). But why should
 all the code reside in one file ? there is no real reason. In fact, there
 are many reasons why module code should be in different files...and
 maintenance/source control is one of them, and a very important one, at
 least for software companies.

 To give you a real-world example: the Linux kernel is thousands of lines

 code, in hundrends of files, and many files contain nothing more than one
 declaration or two. Do you think this is by accident ? it is not. In fact,
 it is easier to maintain the kernel that way.

 Imagine if the Linux kernel would be made in D: tens of files, each one

 thousands of lines of code...a real source control nightmare.

 I think this is a major problem for D and it needs to be addressed as soon

It is up to the developer how small he breaks down his problem and therefore how small he makes his modules. You dont need to have large modules anymore than you have to have large methods. In Java you can have one class per file or one thousand classes(or more) per file. Same as D. Its all up to you!
May 15 2004
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
On Sat, 15 May 2004 13:34:25 +0300, Achilleas Margaritis wrote:

 It seems that right now the concept of a package in D is nothing more
 than a namespace for modules. The question is, would a keyword for
 package protection add more utility without causing a breakdown in the
 intended use of modules? I don't think that's possible. Give us the
 keyword, and soon D packages will be treated as 'modules', while the
 original module idea slowly fades away.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed.

Agreed.
 Walter originally thought "one module contains everything it needs". I
 totally agree with that.

Me too.
 The problem is that a module is not equal to a file. Why does it have to be
 ? a module is nothing more than a collection of code and data that are
 closely related...(also a property of classes, by the way). But why should
 all the code reside in one file ? there is no real reason. In fact, there
 are many reasons why module code should be in different files...and
 maintenance/source control is one of them, and a very important one, at
 least for software companies.

I agree here too. The 'module' is a concept and the 'file' is a physical. To make files be a metaphor for modules is artifical. A module is a collection of related code and data. A file is just a device to contain source code. There is no essential reason that a module must be constrained to a single file. This is just a design decision b Walter. Hopefully it has merit in most cases, but I think the argument concerning source code control systems might need further investigating.
 To give you a real-world example: the Linux kernel is thousands of lines of
 code, in hundrends of files, and many files contain nothing more than one
 declaration or two. Do you think this is by accident ? it is not. In fact,
 it is easier to maintain the kernel that way.
 
 Imagine if the Linux kernel would be made in D: tens of files, each one with
 thousands of lines of code...a real source control nightmare.
 
 I think this is a major problem for D and it needs to be addressed as soon
 as possible. I am sure Walter has big plans for D (i.e. to be used in big
 and serious projects).

I can't see much merit in a module needing to have unrestricted access to private data elements contained in other modules. This just sounds like a bug or two waiting to happen. It is generally accepted that modules need to be as decoupled as possible to achieve quality systems. -- Derek Melbourne, Australia
May 15 2004
prev sibling next sibling parent mike parker <mike aldacron.com> writes:
Achilleas Margaritis wrote:

It seems that right now the concept of a package in D is nothing more
than a namespace for modules. The question is, would a keyword for
package protection add more utility without causing a breakdown in the
intended use of modules? I don't think that's possible. Give us the
keyword, and soon D packages will be treated as 'modules', while the
original module idea slowly fades away.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed.

It was not my intent to imply anything religious ;) A zealot I'm not. What I'm getting at is that this sort of change is not just a minor feature addition, but really would be a major paradigm shift.
May 15 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
Achilleas Margaritis wrote:

It seems that right now the concept of a package in D is nothing more
than a namespace for modules. The question is, would a keyword for
package protection add more utility without causing a breakdown in the
intended use of modules? I don't think that's possible. Give us the
keyword, and soon D packages will be treated as 'modules', while the
original module idea slowly fades away.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed. Walter originally thought "one module contains everything it needs". I totally agree with that. The problem is that a module is not equal to a file. Why does it have to be ? a module is nothing more than a collection of code and data that are closely related...(also a property of classes, by the way). But why should all the code reside in one file ? there is no real reason. In fact, there are many reasons why module code should be in different files...and maintenance/source control is one of them, and a very important one, at least for software companies. To give you a real-world example: the Linux kernel is thousands of lines of code, in hundrends of files, and many files contain nothing more than one declaration or two. Do you think this is by accident ? it is not. In fact, it is easier to maintain the kernel that way. Imagine if the Linux kernel would be made in D: tens of files, each one with thousands of lines of code...a real source control nightmare.

Does it have to be one of the other? Can we have two files with 20 lines of code each and then every other file can contain a few hundred lines? I think this is an issue of personal preference, but I cringe when I'm looking through a set of code and every file I open seems to have about 5 lines of code. I'd prefer to have longer modules if I could have fewer of them.
 
 I think this is a major problem for D and it needs to be addressed as soon
 as possible. I am sure Walter has big plans for D (i.e. to be used in big
 and serious projects).

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 15 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
mike parker wrote:
 Hauke Duden wrote:
 
 My whole idea of using one class per file is that I can easily find 
 the file that contains a specific class and that the files do not grow 
 to tens of thousands of lines.

 Sourcecode control systems also work better with many smaller files, 
 since then they don't have to merge that often.

 My reasons for wanting this are simple code maintenance issues. These 
 kinds of things become important for big projects.

From this perspective I will grudgingly agree ;-) I'll admit, in a project I'm currently working on I stumbled into a situation where package level protection would have been real handy. Even so, I'm starting to grow accustomed to the D way. I like cutting down on the number of files. It seems that right now the concept of a package in D is nothing more than a namespace for modules. The question is, would a keyword for package protection add more utility without causing a breakdown in the intended use of modules? I don't think that's possible. Give us the keyword, and soon D packages will be treated as 'modules', while the original module idea slowly fades away. Considering that the majority of us are coming from C++ and Java, the idea of one class per file is something we've grown accustomed too (for maintenance, readability, desgin paradigms, or whatever reason). If we can do it easily, we will.

Another (very simple) solution would be to allow a module to be a directory. The module import mechanism could then be just as it is, "friends" could be handled the same way and the file layout would nevertheless be in the hands of the programmer. A super-simple way to do this would be to modify the module importing algorithms like this: - searching for module A - if there is a file A.d import that - if there is no file A.d search for a directory A.dmodule - if there is a directory A.dmodule import all .d files in it. - if there is no directory A.dmodule then the module is not found. Hauke
May 15 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sat, 15 May 2004 13:12:02 +0200, Hauke Duden <H.NS.Duden gmx.net> wrote:
 mike parker wrote:
 Hauke Duden wrote:

 My whole idea of using one class per file is that I can easily find 
 the file that contains a specific class and that the files do not grow 
 to tens of thousands of lines.

 Sourcecode control systems also work better with many smaller files, 
 since then they don't have to merge that often.

 My reasons for wanting this are simple code maintenance issues. These 
 kinds of things become important for big projects.

From this perspective I will grudgingly agree ;-) I'll admit, in a project I'm currently working on I stumbled into a situation where package level protection would have been real handy. Even so, I'm starting to grow accustomed to the D way. I like cutting down on the number of files. It seems that right now the concept of a package in D is nothing more than a namespace for modules. The question is, would a keyword for package protection add more utility without causing a breakdown in the intended use of modules? I don't think that's possible. Give us the keyword, and soon D packages will be treated as 'modules', while the original module idea slowly fades away. Considering that the majority of us are coming from C++ and Java, the idea of one class per file is something we've grown accustomed too (for maintenance, readability, desgin paradigms, or whatever reason). If we can do it easily, we will.

Another (very simple) solution would be to allow a module to be a directory. The module import mechanism could then be just as it is, "friends" could be handled the same way and the file layout would nevertheless be in the hands of the programmer.

I like this idea/concept a directory is a collection of files, a module is a collection of classes. So would privates from files within a directory become shared in this case?
 A super-simple way to do this would be to modify the module importing 
 algorithms like this:

 - searching for module A
 - if there is a file A.d import that
 - if there is no file A.d search for a directory A.dmodule

I would drop the .dmodule from the directory name.
 - if there is a directory A.dmodule import all .d files in it.
 - if there is no directory A.dmodule then the module is not found.

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 16 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 My reasons for wanting this are simple code maintenance issues. These
 kinds of things become important for big projects.

 Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...
May 15 2004
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Achilleas Margaritis wrote:

 Imagine a source code file with 5 such
 classes (because they need to know each other's few private members) !!! a
 nightmare from all perspectives...

The need to access private members usually imply bad design. The need to access protected members might be well founded, especially where MI isn't possible (like D). Lars Ivar Igesund
May 15 2004
parent Andy Friesen <andy ikagames.com> writes:
Lars Ivar Igesund wrote:

 The need to access private members usually imply bad design. The need to 
 access protected members might be well founded, especially where MI 
 isn't possible (like D).

The same could be said of goto. It may be bad design, but sometimes the wrong way really is the right way. D recognizes this in the case of goto, and maybe it should recognize it in the case of package scope. -- andy
May 15 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Achilleas Margaritis wrote:
My reasons for wanting this are simple code maintenance issues. These
kinds of things become important for big projects.

Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 15 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
J C Calvarese wrote:
 Achilleas Margaritis wrote:
 
 My reasons for wanting this are simple code maintenance issues. These
 kinds of things become important for big projects.

 Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.

What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV." I probably shouldn't even have answered... Hauke
May 15 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Hauke Duden wrote:

 J C Calvarese wrote:
 
 Achilleas Margaritis wrote:

 My reasons for wanting this are simple code maintenance issues. These
 kinds of things become important for big projects.

 Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.

What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV." I probably shouldn't even have answered... Hauke

I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public". I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public. I can't see what the problem is. Perhaps more detailed code samples will make his point more clear. I'm afraid that he wants to program Java in D when it would be better to program D in D. D is designed to be different than C++ and Java. Let's not be afraid to do things differently. Sometimes "different is better". Maybe we do need a protected, supermodule, friend, directory or some other new keyword, but I think we need to check to see if we have a need before we take that step. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 15 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
J C Calvarese wrote:
 Hauke Duden wrote:
 
 J C Calvarese wrote:

 Achilleas Margaritis wrote:

 My reasons for wanting this are simple code maintenance issues. These
 kinds of things become important for big projects.

 Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.

What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV." I probably shouldn't even have answered... Hauke

I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public". I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public.

I don't think you understand the issue. It is often the case that you want to provide a certain functionality and that functionality is decomposed into multiple classes. These classes may need to cooperate to achieve the goal, but you do not want the mechanisms used for the cooperation to be accessible by anyone else. That's where "package", "friends" or whatever you call it comes into play. It means "public, but only for my own team". In D this means that all classes of the same "team" have to be in the same module. So far so good, nothing wrong with that. But since a module is always a single file it means that these classes also have to be in the same file. And THIS can be a real problem when they reach a certain size. For example, it may very well be that you write a bunch of GUI classes which need to cooperate with some kind of window system. As said before, maybe you don't want these cooperation mechanism to be accessible by anything but the window system and the GUI classes. So with the current situation you'd have to put a good sized chunk of the library into one single file. We're talking about tens of thousands, maybe even hundreds of thousands of lines of code here. It would be impossible to have multiple programmers work on the library without regular merging nightmares. There may always be some way to avoid putting too much code into a single file, like creating "proxy classes" with all the cooperation stuff. But this kind of thing limits the freedom of the software designer. And worst of all, the problem isn't even a language concept (every language limits the design in some way) but merely the mapping of a language concept to a physical entity (i.e. the mapping of module=file). This kind of thing is totally unnecessary. Hauke
May 15 2004
next sibling parent DemmeGod <me demmegod.com> writes:
Hauke Duden wrote:

 J C Calvarese wrote:
 Hauke Duden wrote:
 
 J C Calvarese wrote:

 Achilleas Margaritis wrote:

 My reasons for wanting this are simple code maintenance issues. These
 kinds of things become important for big projects.

 Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.

What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV." I probably shouldn't even have answered... Hauke

I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public". I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public.

I don't think you understand the issue. It is often the case that you want to provide a certain functionality and that functionality is decomposed into multiple classes. These classes may need to cooperate to achieve the goal, but you do not want the mechanisms used for the cooperation to be accessible by anyone else. That's where "package", "friends" or whatever you call it comes into play. It means "public, but only for my own team". In D this means that all classes of the same "team" have to be in the same module. So far so good, nothing wrong with that. But since a module is always a single file it means that these classes also have to be in the same file. And THIS can be a real problem when they reach a certain size. For example, it may very well be that you write a bunch of GUI classes which need to cooperate with some kind of window system. As said before, maybe you don't want these cooperation mechanism to be accessible by anything but the window system and the GUI classes. So with the current situation you'd have to put a good sized chunk of the library into one single file. We're talking about tens of thousands, maybe even hundreds of thousands of lines of code here. It would be impossible to have multiple programmers work on the library without regular merging nightmares. There may always be some way to avoid putting too much code into a single file, like creating "proxy classes" with all the cooperation stuff. But this kind of thing limits the freedom of the software designer. And worst of all, the problem isn't even a language concept (every language limits the design in some way) but merely the mapping of a language concept to a physical entity (i.e. the mapping of module=file). This kind of thing is totally unnecessary. Hauke

So I wonder if Walter is going to grace us with his take on this?
May 16 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
 For example, it may very well be that you write a bunch of GUI classes
 which need to cooperate with some kind of window system. As said before,
 maybe you don't want these cooperation mechanism to be accessible by
 anything but the window system and the GUI classes. So with the current
 situation you'd have to put a good sized chunk of the library into one
 single file. We're talking about tens of thousands, maybe even hundreds
 of thousands of lines of code here. It would be impossible to have
 multiple programmers work on the library without regular merging

I totally agree, very good example. To put in real terms, in most GUI toolkits, the graphics/device context in a Graphics type object that provides the drawing algorithms to widgets. Most toolkits base Widget class has a 'paint' method which is passed a Graphics object which is used for drawing by the widget. For example, Swing has a Graphics object; Qt has a Painter object. With the D method, one needs to put the Graphics class and the Widget class in the same file...which probably means around 20,000 lines of code in the same module. This big file will contain all the implementations of the Graphics class (for MS Windows / X-Windows / MacOS), and it needs to be in the same file with Widget because it needs access to the window handle of the widget. And the Widget class itself would be thousands of lines of code, covering functionality between Win32/X/MacOS. It's a pity that the D community does not understand this. Most guys think it is no big problem. Unless you work on a big project, you can't understand what a problem can it be. Despite all this, D has the concept of package, right ? what if two classes want to co-operate in package level, but they don't belong in the same module ? i.e. they are not closely related, but they have to access a few of each other's internals. I repeat, this is a serious issue.
May 18 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 18 May 2004 22:55:13 +0300, Achilleas Margaritis wrote:

 For example, it may very well be that you write a bunch of GUI classes
 which need to cooperate with some kind of window system. As said before,
 maybe you don't want these cooperation mechanism to be accessible by
 anything but the window system and the GUI classes. So with the current
 situation you'd have to put a good sized chunk of the library into one
 single file. We're talking about tens of thousands, maybe even hundreds
 of thousands of lines of code here. It would be impossible to have
 multiple programmers work on the library without regular merging

I totally agree, very good example. To put in real terms, in most GUI toolkits, the graphics/device context in a Graphics type object that provides the drawing algorithms to widgets. Most toolkits base Widget class has a 'paint' method which is passed a Graphics object which is used for drawing by the widget. For example, Swing has a Graphics object; Qt has a Painter object. With the D method, one needs to put the Graphics class and the Widget class in the same file...which probably means around 20,000 lines of code in the same module.

Only if you wish to directly access each other's internal data elements rather than use public methods.
 This big file will contain all the implementations of the
 Graphics class (for MS Windows / X-Windows / MacOS), and it needs to be in
 the same file with Widget because it needs access to the window handle of
 the widget. And the Widget class itself would be thousands of lines of code,
 covering functionality between Win32/X/MacOS.

What wrong with a getWindowHandle() method?
 It's a pity that the D community does not understand this. Most guys think
 it is no big problem. Unless you work on a big project, you can't understand
 what a problem can it be.

I dislike huge source files too. I see no necessary linkage between a source code file and a D module either, other than this is how Walter has chosen to implement it.
 Despite all this, D has the concept of package, right ? what if two classes
 want to co-operate in package level, but they don't belong in the same
 module ? i.e. they are not closely related, but they have to access a few of
 each other's internals.
 
 I repeat, this is a serious issue.

Why can't access be via public *methods*? Why is the use of *private* (but friendly shared) data elements required? I don't see the seriousness of your situation. Can you give me code examples where you _need_ (as opposed to _want_ ) this? Is it a performance issue? As I said before, maybe a read-only attribute might be an acceptable solution. One could then create something like ... class Widget { readonly hWnd myHandle; setHandle( ... ) { ... } } which would make 'myHandle' publicly visible but only to read its contents. No one can set it other than the Widget class. -- Derek 19/May/04 10:11:14 AM
May 18 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
Derek Parnell wrote:

 Why can't access be via public *methods*? Why is the use of *private* (but
 friendly shared) data elements required? I don't see the seriousness of
 your situation. Can you give me code examples where you _need_ (as opposed
 to _want_ ) this? Is it a performance issue? 
 
 
 As I said before, maybe a read-only attribute might be an acceptable
 solution. One could then create something like ...
 
 class Widget
 {
    readonly hWnd myHandle;
    
    setHandle( ... ) { ... }
 }
 
 which would make 'myHandle' publicly visible but only to read its contents.
 No one can set it other than the Widget class.

I was about to say the same thing, but, if that handle is publically available, it is very easy to use it to break the class's invariant. (DestroyWindow?) I agree that exposing the handle to client code is a good idea in this particular case, but for completely unrelated reasons. (I like my GUI abstractions with backdoors for when I need to go beyond the toolkit) The argument stands in the general case. C# uses the 'internal' access modifier to achieve this. It looks like D might really need something like it. -- andy
May 18 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Derek Parnell wrote:

Why can't access be via public *methods*? Why is the use of *private* (but
friendly shared) data elements required? I don't see the seriousness of
your situation. Can you give me code examples where you _need_ (as opposed
to _want_ ) this? Is it a performance issue? 


As I said before, maybe a read-only attribute might be an acceptable
solution. One could then create something like ...

class Widget
{
   readonly hWnd myHandle;
   
   setHandle( ... ) { ... }
}

which would make 'myHandle' publicly visible but only to read its contents.
No one can set it other than the Widget class.
  
  

property methods? The above is not the right D syntax. The right D syntax would be: class Widget { private hWnd MyHandle; hWnd myHandle() { return MyHandle; } //Readonly setHandle( ... ) { ... } } -- -Anderson: http://badmama.com.au/~anderson/
May 19 2004
parent reply Derek <ddparnell bigpond.com> writes:
On Wed, 19 May 2004 17:06:57 +0800, J Anderson wrote:

 Derek Parnell wrote:
 
Why can't access be via public *methods*? Why is the use of *private* (but
friendly shared) data elements required? I don't see the seriousness of
your situation. Can you give me code examples where you _need_ (as opposed
to _want_ ) this? Is it a performance issue? 


As I said before, maybe a read-only attribute might be an acceptable
solution. One could then create something like ...

class Widget
{
   readonly hWnd myHandle;
   
   setHandle( ... ) { ... }
}

which would make 'myHandle' publicly visible but only to read its contents.
No one can set it other than the Widget class.
  
  


I'm sorry. That would be my fault for not explaining myself (again).
You know you can already do readonly in D right using 
 property methods? The above is not the right D syntax.

Yes, its true that it is possible to do 'readonly' in D already, and yes I did know that. What I was trying to do was suggest an ALTERNATE method, one that didn't involve a function call overhead. The current D 'get' property technique involves generating a functional call. What I was suggesting that this might be able to be avoided by a new 'readonly' attribute. The D compiler may be able to generate direct access to the data element instead of calling a function. It was just a performance issue that might be addressed this way. The 'readonly' attibute would mean that D would *not* allow direct access to update the data element, except for code belonging to the class that owned the data.
 The right D syntax would be:
 
 class Widget
 {
    private hWnd MyHandle;
    
    hWnd myHandle() { return MyHandle; } //Readonly
 
    setHandle( ... ) { ... }
 }

Yes, I agree. But this means a function call is needed to get the data element's value. If it was a public data element, a call might be avoided, but that also means that non-owning code can update the data too. The 'readonly' attribute would allow direct access to get the data's value but prevent direct access to update it. -- Derek Melbourne, Australia
May 19 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Derek wrote:

Yes, its true that it is possible to do 'readonly' in D already, and yes I
did know that. What I was trying to do was suggest an ALTERNATE method, one
that didn't involve a function call overhead.

What overhead? The function can easily be inlined. The only difference would be the syntax form. -- -Anderson: http://badmama.com.au/~anderson/
May 19 2004
parent reply Derek <ddparnell bigpond.com> writes:
On Wed, 19 May 2004 19:08:30 +0800, J Anderson wrote:

 Derek wrote:
 
Yes, its true that it is possible to do 'readonly' in D already, and yes I
did know that. What I was trying to do was suggest an ALTERNATE method, one
that didn't involve a function call overhead.

What overhead? The function can easily be inlined. The only difference would be the syntax form.

When you say that 'The function can easily be inlined' do you mean that any function one nominates will definitely be inlined? How does one indicate that in the source code? I was under the impression, after reading the D docs, that a function might not be inlined sometimes. The docs say ... --------- There is no inline keyword. The compiler makes the decision whether to inline a function or not, analogously to the register keyword no longer being relevant to a compiler's decisions on enregistering variables. (There is no register keyword either.) ---------- So I naturally assumed that there is a possibliity that the compiler might generate a function call. My suggestion was designed to tell the compiler that its okay to generate direct accessing code when any code is reading the data element's value. Sorry for misunderstanding the docs. -- Derek Melbourne, Australia
May 19 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Derek wrote:

When you say that 'The function can easily be inlined' do you mean that any
function one nominates will definitely be inlined? How does one indicate
that in the source code? 

I was under the impression, after reading the D docs, that a function might
not be inlined sometimes. The docs say ...

---------
There is no inline keyword. The compiler makes the decision whether to
inline a function or not, analogously to the register keyword no longer
being relevant to a compiler's decisions on enregistering variables. (There
is no register keyword either.) 
----------
  

most compilers can inline these. There are some cases where it can't inline, such as with some virtual functions. However these are rare and the overhead is generally acceptable. Trust your compiler to make the better choice.
So I naturally assumed that there is a possibliity that the compiler might
generate a function call. 

My suggestion was designed to tell the compiler that its okay to generate
direct accessing code when any code is reading the data element's value.

Sorry for misunderstanding the docs.

  

-- -Anderson: http://badmama.com.au/~anderson/
May 19 2004
prev sibling next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
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 20 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:c8e98t$2qph$1 digitaldaemon.com...
 On Tue, 18 May 2004 22:55:13 +0300, Achilleas Margaritis wrote:

 For example, it may very well be that you write a bunch of GUI classes
 which need to cooperate with some kind of window system. As said



 maybe you don't want these cooperation mechanism to be accessible by
 anything but the window system and the GUI classes. So with the current
 situation you'd have to put a good sized chunk of the library into one
 single file. We're talking about tens of thousands, maybe even hundreds
 of thousands of lines of code here. It would be impossible to have
 multiple programmers work on the library without regular merging

I totally agree, very good example. To put in real terms, in most GUI toolkits, the graphics/device context in a Graphics type object that provides the drawing algorithms to widgets. Most toolkits base Widget


 has a 'paint' method which is passed a Graphics object which is used for
 drawing by the widget.

 For example, Swing has a Graphics object; Qt has a Painter object.

 With the D method, one needs to put the Graphics class and the Widget


 in the same file...which probably means around 20,000 lines of code in


 same module.

Only if you wish to directly access each other's internal data elements rather than use public methods.
 This big file will contain all the implementations of the
 Graphics class (for MS Windows / X-Windows / MacOS), and it needs to be


 the same file with Widget because it needs access to the window handle


 the widget. And the Widget class itself would be thousands of lines of


 covering functionality between Win32/X/MacOS.

What wrong with a getWindowHandle() method?

You don't want to do that. Somebody might mess with the window that way and make a mess of your code.
 It's a pity that the D community does not understand this. Most guys


 it is no big problem. Unless you work on a big project, you can't


 what a problem can it be.

I dislike huge source files too. I see no necessary linkage between a source code file and a D module either, other than this is how Walter has chosen to implement it.
 Despite all this, D has the concept of package, right ? what if two


 want to co-operate in package level, but they don't belong in the same
 module ? i.e. they are not closely related, but they have to access a


 each other's internals.

 I repeat, this is a serious issue.

Why can't access be via public *methods*? Why is the use of *private* (but friendly shared) data elements required? I don't see the seriousness of your situation. Can you give me code examples where you _need_ (as opposed to _want_ ) this? Is it a performance issue?

The Graphics object needs to access the handle of the window, but the programmer must not have access to the handle of the window. Otherwise, it would be easy to make a mess of a program.
 As I said before, maybe a read-only attribute might be an acceptable
 solution. One could then create something like ...

 class Widget
 {
    readonly hWnd myHandle;

    setHandle( ... ) { ... }
 }

 which would make 'myHandle' publicly visible but only to read its

 No one can set it other than the Widget class.

 --
 Derek
 19/May/04 10:11:14 AM

May 22 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Achilleas Margaritis wrote:

The Graphics object needs to access the handle of the window, but the
programmer must not have access to the handle of the window. Otherwise, it
would be easy to make a mess of a program.
  

I don't know about that. I've always been annoyed with API's that don't provide a window handle because it makes adding openGL harder. However I think something like a windows handle could be kept in a platform-specific module. -- -Anderson: http://badmama.com.au/~anderson/
May 22 2004
parent Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:

 Achilleas Margaritis wrote:
 
 The Graphics object needs to access the handle of the window, but the
 programmer must not have access to the handle of the window. 
 Otherwise, it
 would be easy to make a mess of a program.

I don't know about that. I've always been annoyed with API's that don't provide a window handle because it makes adding openGL harder. However I think something like a windows handle could be kept in a platform-specific module.

I totally agree. Sometimes the toolkit doesn't do something you want, or you want to extend it with some third party UI element (like Scintilla). If you can't reach the metal, you can't do that at all. The solution is to simply document very clearly that it is "dangerous" and that it should not be used frivolously. -- andy
May 22 2004
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:c85k5f$1oga$1 digitaldaemon.com...
 Achilleas Margaritis wrote:
My reasons for wanting this are simple code maintenance issues. These
kinds of things become important for big projects.

Hauke

The importance of maintenance can't be overstressed. GUI classes often


 made out of thousands of lines of code. For example, Microsoft's ListBox
 implementation is 11,000 lines. Imagine a source code file with 5 such
 classes (because they need to know each other's few private members) !!!


 nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/

I wish things were as easy as you mention! But one of my programming principles is: no public data! ever! There is no design issue in my code. More specifically, my GUI has two major classes: -class Component is the base class for most widgets. -class Container is derived from class Component. -class Component has a pointer to the container it belongs. -I want class Component and class Container in different files; i want the user to: import bar.Component; and import bar.Container, for conceptual reasons. Anyway, I can't do it, but I will stop complaining. But this will come back when D is used for big projects.
May 18 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8dp62$2142$1 digitaldaemon.com>, Achilleas Margaritis says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:c85k5f$1oga$1 digitaldaemon.com...
 Achilleas Margaritis wrote:
My reasons for wanting this are simple code maintenance issues. These
kinds of things become important for big projects.

Hauke

The importance of maintenance can't be overstressed. GUI classes often


 made out of thousands of lines of code. For example, Microsoft's ListBox
 implementation is 11,000 lines. Imagine a source code file with 5 such
 classes (because they need to know each other's few private members) !!!


 nightmare from all perspectives...

Change the private memebers to public and use as many files as you want. If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/

I wish things were as easy as you mention! But one of my programming principles is: no public data! ever! There is no design issue in my code. More specifically, my GUI has two major classes: -class Component is the base class for most widgets. -class Container is derived from class Component. -class Component has a pointer to the container it belongs. -I want class Component and class Container in different files; i want the user to: import bar.Component; and import bar.Container, for conceptual reasons. Anyway, I can't do it, but I will stop complaining. But this will come back when D is used for big projects.

If class A has data, and classes B1 through B200 need to access this data, then you might do something like: file1: class A { .. private: int window_handle; }; // Is-A Dodge class SuperB { protected: get_window_handle(A a) { return A.window_handle; } }; file2,3,4,...200: class B122 : SuperB { public: Drawl() { get_window_handle().Elipsis(); } }; Yeah, I know its not exactly what you are asking for. But I think the "protected" is a good description of what you are suggesting. The user can still derive from SuperB and make more widgets, but that's a good thing in a widget set, right? Kevin
May 18 2004
prev sibling next sibling parent Billy Zelsnack <billy_zelsnack yahoo.com> writes:
 The whole idea of one class per file in Java is not necessarily because 
 it's a better design, but because it's the convention when using Java 
 (it's possible to have more than one class per file in Java actually). 
 We use package protection in Java because that's the mechanism provided. 
 Likewise the friend keyword in C++. D provides the same functionality. 
 If you adjust your train of thought (think in D!) you can accomplish 
 what you need easily without frustration.

I think the main reason for one public class per file in Java is to allow for magically compilation. ie. Given a classpath and a dotted class name, the compiler can find the file where the class lives.
May 14 2004
prev sibling parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
"mike parker" <mike aldacron.com> wrote in message
news:c82sm7$r9u$1 digitaldaemon.com...
 Hauke Duden wrote:
 I think this is really needed in the language; as it is right now, it
 would
 frustrate many developers who would want module names to correspond to
 class
 names (and for gui libs, there are lots of classes). Again, this is a
 small
 change and easily implementable, but it would save lots of developers
 from lots
 of frustration.


I think it's not needed at all. When coding in Java, I don't think in C++. D isn't Java, and it isn't C++. When designing a D app, think in D. It's not that hard of an adjustment to get used to using module-levle privates in place of package protection and friends.

 The whole idea of one class per file in Java is not necessarily because
 it's a better design, but because it's the convention when using Java
 (it's possible to have more than one class per file in Java actually).
 We use package protection in Java because that's the mechanism provided.
 Likewise the friend keyword in C++. D provides the same functionality.
 If you adjust your train of thought (think in D!) you can accomplish
 what you need easily without frustration.

I personally have no problem in adjusting to D, but the end-users of my library will have. From the end-user perspective(that is, the programmer who uses my library) it will be much easier to have one module per class, because remembering the class name will also help remember the module that should be imported. The problem is, a GUI library has many many classes: widgets (over 40 classes), layouts (over 10 classes), items (over 5 classes), many helper classes etc. If the user of this library has to remember all these class' names AND module names, it will be diffucult for them...whereas if it was possible to have one module per class, there would be significant advantages: 1) it would be much easier for the programmer, because remembering the class name will also help remember the module name. 2) it would make management of the project (a huge project) much easier. So, why to put the burden on the end-user's shoulders, while it can be put on the developer's ? a small change would result in big savings.
May 15 2004
prev sibling parent reply Kevin Belaer <Kevin_member pathlink.com> writes:
In article <c82ogd$lf6$1 digitaldaemon.com>, Hauke Duden says...
I totally agree. I posted about this a while back because I also like to 
have one class per file. Got no comment from Walter, so I guess he was 
waiting to see how important this issue is. Thanks for bringing it up 
again ;).

IMHO a JAVA-like package attribute is a good solution for this. Not as 
hackish as C++'s friend stuff and it integrates cleanly with the other 
access attributes.

By putting each module in one file, all the code that is able to access a given private member is compiled in the same step. This means that those members can be rearranged and even eliminated if they are not used. This level of analysis is probably not available yet; but its a good design. If you really want seperate files, you could use makefile rules: bigmodule.d: file1.dp file2.dp file3.dp cat file[123].dp > bigmodule.d OR # Parts of bigmodule are in files starting with "bigmodule_". bigmodule.d: bigmodule_*.d cat bigmodule_*.d > bigmodule.d This gives you the +/- advantages of seperate files (the only one I can think of is, you can check them into CVS (or wherever) and track each class's changes seperately.) Kevin
May 14 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Kevin Belaer wrote:

 In article <c82ogd$lf6$1 digitaldaemon.com>, Hauke Duden says...
 
I totally agree. I posted about this a while back because I also like to 
have one class per file. Got no comment from Walter, so I guess he was 
waiting to see how important this issue is. Thanks for bringing it up 
again ;).

IMHO a JAVA-like package attribute is a good solution for this. Not as 
hackish as C++'s friend stuff and it integrates cleanly with the other 
access attributes.

By putting each module in one file, all the code that is able to access a given private member is compiled in the same step. This means that those members can be rearranged and even eliminated if they are not used. This level of analysis is probably not available yet; but its a good design.

Even if the code is in different files, unused module members can still be optimized away by the linker, which is where this kind of optimization is usually done. Applies to public members as well, btw.
 If you really want seperate files, you could use makefile rules:
 
 bigmodule.d: file1.dp file2.dp file3.dp
 cat file[123].dp > bigmodule.d

Ewww. I prefer not to hack together my own preprocessor, thank you. The source files should be compilable as they are - generating intermediate files just leads to lots of problems (e.g. during debugging or if you accidentally edit the wrong file, or if people don't have your "preprocessor" or ...) Hauke
May 14 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8343j$15v2$1 digitaldaemon.com>, Hauke Duden says...
Kevin Belaer wrote:

 In article <c82ogd$lf6$1 digitaldaemon.com>, Hauke Duden says...
 
I totally agree. I posted about this a while back because I also like to 
have one class per file. Got no comment from Walter, so I guess he was 
waiting to see how important this issue is. Thanks for bringing it up 
again ;).

IMHO a JAVA-like package attribute is a good solution for this. Not as 
hackish as C++'s friend stuff and it integrates cleanly with the other 
access attributes.

By putting each module in one file, all the code that is able to access a given private member is compiled in the same step. This means that those members can be rearranged and even eliminated if they are not used. This level of analysis is probably not available yet; but its a good design.

Even if the code is in different files, unused module members can still be optimized away by the linker, which is where this kind of optimization is usually done. Applies to public members as well, btw.

I think it's common to use the operating system's linker, and rare to modify the linker with specific language optimization features. The linker looks at .o and a files. I think the knowledge of structures and members is lost at this point, and everything is done based on pointers, offsets, and labels. But I'm not really up on this; maybe everyone is writing their own linkers now. C++ needs at least some linker interaction in order to insure auto instantiation of template stuff. Kevin
 If you really want seperate files, you could use makefile rules:
 
 bigmodule.d: file1.dp file2.dp file3.dp
 cat file[123].dp > bigmodule.d

Ewww. I prefer not to hack together my own preprocessor, thank you. The source files should be compilable as they are - generating intermediate files just leads to lots of problems (e.g. during debugging or if you accidentally edit the wrong file, or if people don't have your "preprocessor" or ...)

I agree that its ugly..
Hauke

May 14 2004
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
 But at the same time, I want class 'Foo' to access the private fields of

 class 'T'. This is impossible, because they are in different modules.

Why dont you use public get and set methods, and access the private fields from these methods? Hmnnnn I must be wrong, this is just too obvious a solution.
May 15 2004
parent reply Derek <ddparnell bigpond.com> writes:
On Sat, 15 May 2004 20:57:59 +1000, Phill wrote:

 But at the same time, I want class 'Foo' to access the private fields of

 class 'T'. This is impossible, because they are in different modules.

Why dont you use public get and set methods, and access the private fields from these methods? Hmnnnn I must be wrong, this is just too obvious a solution.

This is how I would be addressing the situation too. I mentioned in another thread that I choose not to have public data elements, instead they are made private and I have public methods to access them. In D's case this could be the get/set property system. -- Derek Melbourne, Australia
May 15 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Derek wrote:

On Sat, 15 May 2004 20:57:59 +1000, Phill wrote:

  

But at the same time, I want class 'Foo' to access the private fields of
      

class 'T'. This is impossible, because they are in different modules.

      

access the private fields from these methods? Hmnnnn I must be wrong, this is just too obvious a solution.

This is how I would be addressing the situation too. I mentioned in another thread that I choose not to have public data elements, instead they are made private and I have public methods to access them. In D's case this could be the get/set property system.

getter/setter until you need them. You can happily create a public property and then change it to a getter/setter latter. This is the ideal way of doing things. Get/Sets were nessary in C++ and java because they didn't have that ability. -- -Anderson: http://badmama.com.au/~anderson/
May 15 2004
parent Derek <ddparnell bigpond.com> writes:
On Sat, 15 May 2004 22:32:39 +0800, J Anderson wrote:

 Derek wrote:
 
On Sat, 15 May 2004 20:57:59 +1000, Phill wrote:

  

But at the same time, I want class 'Foo' to access the private fields of
      

class 'T'. This is impossible, because they are in different modules.

      

access the private fields from these methods? Hmnnnn I must be wrong, this is just too obvious a solution.

This is how I would be addressing the situation too. I mentioned in another thread that I choose not to have public data elements, instead they are made private and I have public methods to access them. In D's case this could be the get/set property system.

getter/setter until you need them. You can happily create a public property and then change it to a getter/setter latter. This is the ideal way of doing things. Get/Sets were nessary in C++ and java because they didn't have that ability.

Yes, this is a good feature. I was just thinking now, that something in between 'public' and 'private' might be useful too. Some attibute that would grant read-only access to data elements for code outside the class. This way a class is still responsible for setting valid values, ensuring internal consistancy, and handling side-effects, but anyone can read them. -- Derek Melbourne, Australia
May 16 2004
prev sibling parent Billy Zelsnack <billy_zelsnack yahoo.com> writes:
Why dont you use public get and set methods, and
access the private fields from these methods?

Hmnnnn I must be wrong, this is just too obvious a
solution.

This is how I would be addressing the situation too. I mentioned in another thread that I choose not to have public data elements, instead they are made private and I have public methods to access them. In D's case this could be the get/set property system.

I have been using a special convention to get around the issue. public memberSetFoo(float foo) { } I prepend 'member' to sets and gets. I don't have to do it much, but it is ugly. Saying that, I would prefer a package concept too. hmm. Maybe there could be another access attribute called that allows access to any module that is in the same directory.
May 15 2004