Here are some rules I'd like to propose to for OO projects in D
(nothing new) or, if you will, the "doo" standard:
- 1 source file defines 1 public class or 1 public struct
  or 1 public interface
- the module name is the same as the class, struct or interface
  it defines, this means the module name will start
  with a capital letter.
- Imports are declared inside the class body except for
  the super class and implemented interfaces

(When I started changing leds to comply with these rules
I manage to segfault the compiler 0.77. I revert to the
previous version but keept a backup of that one)

Are out there enough OO guys to start an OO D movement?
I guess it's too soon for that.

I started intellisense for leds. For now I have some
limitations when searching for definitions outside
the current source file. I search only for files
with the same name as the type of the current object.

So, for now "import dui.All" is meaningless to leds…

Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.

as intellisense is marked TM on the MS pages
I'm calling it 'code lookup'.

My code lookup is based on my code browser,
so all the limitation of the code browser
are reflected. (for instance the 'invariante'
and in general any block "{}" that's
not a function will confuse the code browser)

See how it looks like at the leds screenshots page.

http://leds.sourceforge.net

If you decide to try leds beware that there are some
simple limitations (at least for now) on a project
directory tree naming that might not be explicit on the manual.
Please direct any questions to the leds discussion group.

you can use leds to edit a 1 file project and compile it
and run it with one click hummm... I gonna change that
to allows "implict projects" or "auto projects" where
all the files opened and not associated with any other
project will be compiled together.
Seems like a good idea for small tests.

Remember that although leds is used to
develop leds it is alpha quality only.

The code browser and code lookup are the last two major
features I intende to include on leds before
making in a bit more configurable and ready for all.

Ant
dui page (nothing new) http://dui.sourceforge.net

Ant wrote:
> Here are some rules I'd like to propose to for OO projects in D
> (nothing new) or, if you will, the "doo" standard:
> - 1 source file defines 1 public class or 1 public struct
>   or 1 public interface
> - the module name is the same as the class, struct or interface
>   it defines, this means the module name will start
>   with a capital letter.

I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.

I posted about this a few months ago, because I think it is more than a minor problem. I hate source files with thousands of lines - it just gets hard to find your way around in them. It should be up to the programmer how he wants to organize his source files!

In that post I proposed to allow directory-modules, where all files in a directory are part of the same module.

Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one. I.e. introduce a package protection level and allow all classes from the same package to access package-members of other classes in the same package.

Hauke

In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
>
>Ant wrote:
>> Here are some rules I'd like to propose to for OO projects in D
>> (nothing new) or, if you will, the "doo" standard:
>> - 1 source file defines 1 public class or 1 public struct
>>   or 1 public interface
>> - the module name is the same as the class, struct or interface
>>   it defines, this means the module name will start
>>   with a capital letter.
>
>I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.

hmmmm... friend. Never though of that. That's because I never
use it. Is it really necessary?
When is it and essential construct to solve something?
Isn't that just a shortcut or workaround on the general rule
of encapsulation?
I remember friends from C++ never used it in java.

>Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.

If friends are really necessary I vote for that.

Ant

In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
>
>Ant wrote:
>> Here are some rules I'd like to propose to for OO projects in D
>> (nothing new) or, if you will, the "doo" standard:
>> - 1 source file defines 1 public class or 1 public struct
>>   or 1 public interface
>> - the module name is the same as the class, struct or interface
>>   it defines, this means the module name will start
>>   with a capital letter.
>
>I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.

hmmmm... friend. Never though of that. That's because I never
use it. Is it really necessary?
When is it and essential construct to solve something?
Isn't that just a shortcut or workaround on the general rule
of encapsulation?
I remember friends from C++ never used it in java.

>Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.

If friends are really necessary I vote for that.

Ant

looks good ant, do you plan on a windows version also?
regards
lewis

Ant wrote:

> Here are some rules I'd like to propose to for OO projects in D
> (nothing new) or, if you will, the "doo" standard:
> - 1 source file defines 1 public class or 1 public struct
>   or 1 public interface
> - the module name is the same as the class, struct or interface
>   it defines, this means the module name will start
>   with a capital letter.
> - Imports are declared inside the class body except for
>   the super class and implemented interfaces
> 
> (When I started changing leds to comply with these rules
> I manage to segfault the compiler 0.77. I revert to the
> previous version but keept a backup of that one)
> 
> Are out there enough OO guys to start an OO D movement?
> I guess it's too soon for that.
> 
> I started intellisense for leds. For now I have some
> limitations when searching for definitions outside
> the current source file. I search only for files
> with the same name as the type of the current object.
> 
> So, for now "import dui.All" is meaningless to leds…
> 
> Due to the flexibility on naming D modules I'm
> Very happy that D doesn't import all the modules
> in the current 'package' automatically.
> That would make a nightmare to find out the
> source file with a particular class definition.
> 
> as intellisense is marked TM on the MS pages
> I'm calling it 'code lookup'.
> 
> My code lookup is based on my code browser,
> so all the limitation of the code browser
> are reflected. (for instance the 'invariante'
> and in general any block "{}" that's
> not a function will confuse the code browser)
> 
> See how it looks like at the leds screenshots page.
> 
> http://leds.sourceforge.net
> 
> If you decide to try leds beware that there are some
> simple limitations (at least for now) on a project
> directory tree naming that might not be explicit on the manual.
> Please direct any questions to the leds discussion group.
> 
> you can use leds to edit a 1 file project and compile it
> and run it with one click hummm... I gonna change that
> to allows "implict projects" or "auto projects" where
> all the files opened and not associated with any other
> project will be compiled together.
> Seems like a good idea for small tests.
> 
> Remember that although leds is used to
> develop leds it is alpha quality only.
> 
> The code browser and code lookup are the last two major
> features I intende to include on leds before
> making in a bit more configurable and ready for all.
> 
> Ant
> dui page (nothing new) http://dui.sourceforge.net
> 
> 

Ant wrote:
> In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
> 
>>Ant wrote:
>>
>>>Here are some rules I'd like to propose to for OO projects in D
>>>(nothing new) or, if you will, the "doo" standard:
>>>- 1 source file defines 1 public class or 1 public struct
>>>  or 1 public interface
>>>- the module name is the same as the class, struct or interface
>>>  it defines, this means the module name will start
>>>  with a capital letter.

I'd say this is evil. Because of filesystem issues, module names should be left lower case. That is, for a class "MagnifficentWalter" i would make a module "magnifficent_walter".

>>I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.

Hmmm... Even Delphi has an {$INCLUDE} lexer directive.

> hmmmm... friend. Never though of that. That's because I never
> use it. Is it really necessary?
> When is it and essential construct to solve something?
> Isn't that just a shortcut or workaround on the general rule
> of encapsulation?

It is a shortcut to keep encapsulation intact.

> I remember friends from C++ never used it in java.

Did they make all public in Java?

>>Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.

Another solution: declare another module as a friend.

-eye

In article <btei1o$m4q$1@digitaldaemon.com>, Ilya Minkov says...
>
>Ant wrote:
>> In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
>> 
>>>Ant wrote:
>>>
>>>>Here are some rules I'd like to propose to for OO projects in D
>>>>(nothing new) or, if you will, the "doo" standard:
>>>>- 1 source file defines 1 public class or 1 public struct
>>>>  or 1 public interface
>>>>- the module name is the same as the class, struct or interface
>>>>  it defines, this means the module name will start
>>>>  with a capital letter.
>
>I'd say this is evil. Because of filesystem issues, module names should be left lower case. That is, for a class "MagnifficentWalter" i would make a module "magnifficent_walter".

What file systems? we're talking 21st century here...
even the default file system for win98 (what ever that is)
we never had any problem with the java standard.
I remember now. If move your app from a case insensitive
fs to another case sensitive you might have problems.

I've no idea how that works for languages like japanese...?

>
>>>I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.
>
>Hmmm... Even Delphi has an {$INCLUDE} lexer directive.
>
>> hmmmm... friend. Never though of that. That's because I never
>> use it. Is it really necessary?
>> When is it and essential construct to solve something?
>> Isn't that just a shortcut or workaround on the general rule
>> of encapsulation?
>
>It is a shortcut to keep encapsulation intact.
>
>> I remember friends from C++ never used it in java.
>
>Did they make all public in Java?

As I said I don't really use it but I believe that
protected and default (no access modifier) members are
accessible from the entire package (?)

>
>>>Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.
>
>Another solution: declare another module as a friend.

Seems good. It's probably better can't really say.

Ant

In article <btehka$lbl$1@digitaldaemon.com>, Lewis says...
>
>looks good ant, do you plan on a windows version also?
>regards
>lewis

sure.

Ant wrote:
> In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
> 
>>Ant wrote:
>>
>>>Here are some rules I'd like to propose to for OO projects in D
>>>(nothing new) or, if you will, the "doo" standard:
>>>- 1 source file defines 1 public class or 1 public struct
>>>  or 1 public interface
>>>- the module name is the same as the class, struct or interface
>>>  it defines, this means the module name will start
>>>  with a capital letter.
>>
>>I would support that, if it wasn't for one thing: the D "friend" rules. Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.
> 
> 
> hmmmm... friend. Never though of that. That's because I never
> use it. Is it really necessary?

Yes, for some things it is. For example, imagine a Tree class that wants to return an enumerator object. The tree class doesn't expose the internal data pointers, but you need the enumerator to access them directly (say, because of performance). That's one of the cases where friends can be useful.

> Isn't that just a shortcut or workaround on the general rule
> of encapsulation?

No, it allows for better encapsulation. The alternative is usually to make the members public, which allows everyone to access them, not just that one other class that needs it.

I think the Java way (package access) is better than the C++ friend concept. It is less specific, i.e. more classes gain access to a member than really necessary, but it is also easier to manage and understand. Also, it can be argued that you do not need to protect a classes member that fiercely against elements of the same package, because usually they are all under the same designer's control.

Hauke

Ilya Minkov wrote:
>>> Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.
> 
> 
> Another solution: declare another module as a friend.

Hmmm. I think that would be the easiest way to solve this problem. Not necessarily the most elegant one, but oh well - let's stay pragmatic ;).

How about it, big W?

Hauke