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.



  


What about putting all your shared info in a private module, ie:

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.



  


What about putting all your shared info in a private module, ie:

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.
  


This seems to be an oxymoron to me.  D's modules design tries to help 
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.


Why dont you just name the module the same name as the class and import the
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.



  


 What about putting all your shared info in a private module, ie:
 
 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.



 

      


What about putting all your shared info in a private module, ie:

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.

  


<snip>

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.



 

      


What about putting all your shared info in a private module, ie:

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.

  


 <snip>
 
 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


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.


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


for/from.

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


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.


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
    


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.
    


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


 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.


 
 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


 for/from.
 
 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


 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.


 
 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


Java:

 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,


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.


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


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


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


nightmares.

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


 nightmares.
 
 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.


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.
  
  


I'm confused.  You know you can already do readonly in D right using 
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 confused.  


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.) 
----------
  


One line functions are obvious candidates for the compiler to inline and 
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






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.

 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?


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




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?


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


contents.

 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




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/


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




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/


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



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


another

 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


 another

 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
      


another
    


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.

  


One thing I like about D is that you don't need to write the 
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
      


another
    


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.

  


 One thing I like about D is that you don't need to write the 
 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