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.

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/

[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

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

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.

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/

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.

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

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

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