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

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/

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

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

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

Derek Parnell wrote:

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

I was about to say the same thing, but, if that handle is publically available, it is very easy to use it to break the class's invariant. (DestroyWindow?)

I agree that exposing the handle to client code is a good idea in this particular case, but for completely unrelated reasons. (I like my GUI abstractions with backdoors for when I need to go beyond the toolkit) The argument stands in the general case.

C# uses the 'internal' access modifier to achieve this.  It looks like D might really need something like it.

 -- andy

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

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/

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

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/