www.digitalmars.com         C & C++   DMDScript  

D - D OO projects and Intellisense and leds

reply Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 06 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Jan 06 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ant wrote:

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 (?)


Java has 4 protection levels: public, package, protected and private.

"package" protection is the default. It means that all other classes 
from the same package may access the member, but no one else.

Hauke
Jan 06 2004
prev sibling parent Mark T <Mark_member pathlink.com> writes:
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.


UNIX is case sensitive 
Windows is case insensitive but is case preserving
I assume MacOS X follows the UNIX standard (I have never used it)

only DOS would convert everything to uppercase 
(hopefully no-one is still using that for serious software development) 

We currently have no problems with our mixed UNIX and Windows development
environments at work, in C/C++ if you use #include "MyHeader.h" in the code
don't name the actual file "myheader.h"
Jan 07 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 06 2004
prev sibling parent reply "C" <dont respond.com> writes:
This is way off topic, but in this month's CUJ they have an article about
tail call optimization, in it he sites a refrence for a thesis written at
Technische Universitat Munchen :).

Is it a pretty good school ?

C


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:btei1o$m4q$1 digitaldaemon.com...

 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
Jan 06 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
C wrote:

 This is way off topic, but in this month's CUJ they have an article abo=


ut

 tail call optimization, in it he sites a refrence for a thesis written =


at

 Technische Universitat Munchen :).


Nice.

I'm quite surprised someone would poke on my domain adress. ;)


 Is it a pretty good school ?


I'm just in the 3rd semester, but i would say so. At least compared to=20
Ludwig Maximillian University (LMU), which is also in M=FCnchen, and=20
offers almost all the same study courses and many more. LMU is good for=20
its non-technical faculties, such as law, biology, medicine, and so on.=20
We also have a medical faculty, but even it is technologically biased.=20
But my opinion must be biased as well. Ask those studying at the LMU. :> =

I would say TUM has somewhat more attention payed to students, and the=20
professors are quite active in research.

University of Technology (TUM) has been slowly moving way outside the=20
city, so i believe all the lazy people are probably going to the LMU=20
now. ;) Apart from me. I have severe problems with motivation. ;(=20
Doesn't depend on the university though, it's just heavy baggage from my =

former and pre-former lives.

-eye
Jan 06 2004
prev sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
A friend of mine said: "Yes".
But his opinion might be biased - he studies there. :)
-- 
Jan-Eric Duden
"C" <dont respond.com> wrote in message
news:bter7u$14gb$1 digitaldaemon.com...

 This is way off topic, but in this month's CUJ they have an article about
 tail call optimization, in it he sites a refrence for a thesis written at
 Technische Universitat Munchen :).

 Is it a pretty good school ?

 C


 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:btei1o$m4q$1 digitaldaemon.com...

 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
Jan 07 2004
prev sibling parent "Ben Woodhead" <ben dragondoor.com> writes:
Hey, I have atleast one purpose for it. I created an Application Framework
that defined WinMain as a friend (since its not a class) so that when using
my App Framework, everthing was being handled in the Application Class but
that ment allowing WinMain (on a windows platform) and main to have access
to the Applications Framework private data when it was first started.
This made for a really nice way to work in more then one os and make it a
lot like java. Instead of needing a main you simply overload the Application
Framework and define the sections that you want. Nice and easy.

Ben

"Ant" <Ant_member pathlink.com> wrote in message
news:bteh52$kma$1 digitaldaemon.com...

 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
Jan 06 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 06 2004
prev sibling next sibling parent reply Lewis <dethbomb hotmail.com> writes:
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
Jan 06 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...

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


sure.
Jan 06 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:


In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...
  


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


sure.


  


Please announce this when you do, as I can't wait to have a look see.
Jan 08 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <btjuof$2um9$1 digitaldaemon.com>, J Anderson says...

Ant wrote:


In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...
  


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


sure.


Please announce this when you do, as I can't wait to have a look see.


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that each day
I delay the windows version I'm loosing market share to the
other D IDE ;)
But if I release it too soon the damage might be even worst (?) :(

Now I'm curious, What makes leds so appeling for windows use?
I understand that linux user would like to try it but for
windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)

leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant
Jan 08 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:


In article <btjuof$2um9$1 digitaldaemon.com>, J Anderson says...
  


Ant wrote:

    


In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...
 

      


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


sure.

      


Please announce this when you do, as I can't wait to have a look see.
    


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that each day
I delay the windows version I'm loosing market share to the
other D IDE ;)
But if I release it too soon the damage might be even worst (?) :(

Now I'm curious, What makes leds so appeling for windows use?
I understand that linux user would like to try it but for
windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)

  


Exactly.  Once I start using it, and I don't like something I can make 
the changes.  DIDE is being written by one person, which I see these 
problems.
- When that person leaves the project the project dies.
- There is a potential for leds to move at a much faster pace then DIDE, 
once people start contributing.

That's not to say I don't like DIDE, though.


leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant
Jan 08 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I think DIDE and leds should define a common plug-in architecture - D beans,
if you like - such that people can write modules for, and thereby expand,
the powers of both.

I see advantages and disadvantages to open-source and closed-source, but if
both have an extensible architecture, then it's win-win. If they share that
architecture, it's win-win-win


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:btk3hb$4fh$1 digitaldaemon.com...

 Ant wrote:


In article <btjuof$2um9$1 digitaldaemon.com>, J Anderson says...



Ant wrote:




In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...





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


sure.


Please announce this when you do, as I can't wait to have a look see.


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that each day
I delay the windows version I'm loosing market share to the
other D IDE ;)
But if I release it too soon the damage might be even worst (?) :(

Now I'm curious, What makes leds so appeling for windows use?
I understand that linux user would like to try it but for
windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)


 Exactly.  Once I start using it, and I don't like something I can make
 the changes.  DIDE is being written by one person, which I see these
 problems.
 - When that person leaves the project the project dies.
 - There is a potential for leds to move at a much faster pace then DIDE,
 once people start contributing.

 That's not to say I don't like DIDE, though.


leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant
Jan 08 2004
next sibling parent reply "C" <dont respond.com> writes:
Hmm cool idea!

SciTE now now supports scripting with LUA.  As soon as that is 100% I'll
incoporate it.  If we could define a common interface through LUA , then
that would be awesome I think.

C
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btl0hp$1g9q$1 digitaldaemon.com...

 I think DIDE and leds should define a common plug-in architecture - D


beans,

 if you like - such that people can write modules for, and thereby expand,
 the powers of both.

 I see advantages and disadvantages to open-source and closed-source, but


if

 both have an extensible architecture, then it's win-win. If they share


that

 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:btk3hb$4fh$1 digitaldaemon.com...

 Ant wrote:


In article <btjuof$2um9$1 digitaldaemon.com>, J Anderson says...



Ant wrote:




In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...





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


sure.


Please announce this when you do, as I can't wait to have a look see.


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that each day
I delay the windows version I'm loosing market share to the
other D IDE ;)
But if I release it too soon the damage might be even worst (?) :(

Now I'm curious, What makes leds so appeling for windows use?
I understand that linux user would like to try it but for
windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)


 Exactly.  Once I start using it, and I don't like something I can make
 the changes.  DIDE is being written by one person, which I see these
 problems.
 - When that person leaves the project the project dies.
 - There is a potential for leds to move at a much faster pace then DIDE,
 once people start contributing.

 That's not to say I don't like DIDE, though.


leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant
Jan 08 2004
parent reply "Bruce Dodson" <bruce_dodson_except_this_part hotmail.com> writes:
Maybe the Extension Interface should be refactored into
something that is not quite as SciTE specific, so that other
Scintilla based editors and IDEs can more easily implement
the "host" side of the protocol.  Then it would be a
win-win-win-win.

"C" <dont respond.com> wrote in message
news:btl0p3$1gi3$1 digitaldaemon.com...

 Hmm cool idea!

 SciTE now now supports scripting with LUA.  As soon as


that is 100% I'll

 incoporate it.  If we could define a common interface


through LUA , then

 that would be awesome I think.

 C
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btl0hp$1g9q$1 digitaldaemon.com...

 I think DIDE and leds should define a common plug-in




architecture - D

 beans,

 if you like - such that people can write modules for,




and thereby expand,

 the powers of both.

 I see advantages and disadvantages to open-source and




closed-source, but

 if

 both have an extensible architecture, then it's win-win.




If they share

 that

 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in




message

 news:btk3hb$4fh$1 digitaldaemon.com...

 Ant wrote:


In article <btjuof$2um9$1 digitaldaemon.com>, J








Anderson says...

Ant wrote:




In article <btehka$lbl$1 digitaldaemon.com>, Lewis












says...

looks good ant, do you plan on a windows version














also?

regards
lewis


sure.


Please announce this when you do, as I can't wait to










have a look see.


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that








each day

I delay the windows version I'm loosing market share








to the

other D IDE ;)
But if I release it too soon the damage might be even








worst (?) :(

Now I'm curious, What makes leds so appeling for








windows use?

I understand that linux user would like to try it but








for

windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)


 Exactly.  Once I start using it, and I don't like






something I can make

 the changes.  DIDE is being written by one person,






which I see these

 problems.
 - When that person leaves the project the project






dies.

 - There is a potential for leds to move at a much






faster pace then DIDE,

 once people start contributing.

 That's not to say I don't like DIDE, though.


leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant











 Jan 08 2004



  parent  "C" <dont respond.com>  writes:


How's that going ?  Was / Is it very hard to integrate ?  I thought you and
the team were going to bring the extensions to scintilla  , or just SciTE
For now ?

C


"Bruce Dodson" <bruce_dodson_except_this_part hotmail.com> wrote in message
news:btl4q3$1mff$1 digitaldaemon.com...

 Maybe the Extension Interface should be refactored into
 something that is not quite as SciTE specific, so that other
 Scintilla based editors and IDEs can more easily implement
 the "host" side of the protocol.  Then it would be a
 win-win-win-win.

 "C" <dont respond.com> wrote in message
 news:btl0p3$1gi3$1 digitaldaemon.com...

 Hmm cool idea!

 SciTE now now supports scripting with LUA.  As soon as


 that is 100% I'll

 incoporate it.  If we could define a common interface


 through LUA , then

 that would be awesome I think.

 C
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btl0hp$1g9q$1 digitaldaemon.com...

 I think DIDE and leds should define a common plug-in




 architecture - D

 beans,

 if you like - such that people can write modules for,




 and thereby expand,

 the powers of both.

 I see advantages and disadvantages to open-source and




 closed-source, but

 if

 both have an extensible architecture, then it's win-win.




 If they share

 that

 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in




 message

 news:btk3hb$4fh$1 digitaldaemon.com...

 Ant wrote:


In article <btjuof$2um9$1 digitaldaemon.com>, J








 Anderson says...

Ant wrote:




In article <btehka$lbl$1 digitaldaemon.com>, Lewis












 says...

looks good ant, do you plan on a windows version














 also?

regards
lewis


sure.


Please announce this when you do, as I can't wait to










 have a look see.


I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that








 each day

I delay the windows version I'm loosing market share








 to the

other D IDE ;)
But if I release it too soon the damage might be even








 worst (?) :(

Now I'm curious, What makes leds so appeling for








 windows use?

I understand that linux user would like to try it but








 for

windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)


 Exactly.  Once I start using it, and I don't like






 something I can make

 the changes.  DIDE is being written by one person,






 which I see these

 problems.
 - When that person leaves the project the project






 dies.

 - There is a potential for leds to move at a much






 faster pace then DIDE,

 once people start contributing.

 That's not to say I don't like DIDE, though.


leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant













 Jan 08 2004



prev sibling  parent  Ant <duitoolkit yahoo.ca>  writes:


On Fri, 09 Jan 2004 12:36:45 +1100, Matthew wrote:


 I think DIDE and leds should define a common plug-in architecture - D beans,
 if you like - such that people can write modules for, and thereby expand,
 the powers of both.


I have no idea how it's done.
any pointers?

Ant



 Jan 08 2004



prev sibling next sibling parent reply Ant <Ant_member pathlink.com>  writes:


In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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.


of course the best way to do it is to forget the
file system altogether and store the source code
on a data base.
The compiler should be able to accept a stream of
data instead of files.
(we can always generate files on compilation time
for the compiler use)
To do the intellisense searches we would just throw
a sql select to our database.
We could also store the object files (units)
with dates and times and compilation options...

I actually thought of doing that when I started the leds
project but I decided to go conservative as I needed
a tool immediately.

(don't be surprised if in the future the leds dependencies
include PostgreSQL;)

Ant



 Jan 06 2004



  parent reply "C" <dont respond.com>  writes:


sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...

 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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.


 of course the best way to do it is to forget the
 file system altogether and store the source code
 on a data base.
 The compiler should be able to accept a stream of
 data instead of files.
 (we can always generate files on compilation time
 for the compiler use)
 To do the intellisense searches we would just throw
 a sql select to our database.
 We could also store the object files (units)
 with dates and times and compilation options...

 I actually thought of doing that when I started the leds
 project but I decided to go conservative as I needed
 a tool immediately.

 (don't be surprised if in the future the leds dependencies
 include PostgreSQL;)

 Ant





 Jan 06 2004



  parent reply Luke D <Luke_member pathlink.com>  writes:


Do you really need to store the whole source?  Wouldn't just the type info be
sufficient, or even just the name of the file where the type info can be found?
I doubt Intellisence stores the whole source.

Forgive me if I'm misinformed.

In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...

sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...

 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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.


 of course the best way to do it is to forget the
 file system altogether and store the source code
 on a data base.
 The compiler should be able to accept a stream of
 data instead of files.
 (we can always generate files on compilation time
 for the compiler use)
 To do the intellisense searches we would just throw
 a sql select to our database.
 We could also store the object files (units)
 with dates and times and compilation options...

 I actually thought of doing that when I started the leds
 project but I decided to go conservative as I needed
 a tool immediately.

 (don't be surprised if in the future the leds dependencies
 include PostgreSQL;)

 Ant







 Jan 06 2004



 next sibling parent  Ant <Ant_member pathlink.com>  writes:


In article <btfj9e$2a2j$1 digitaldaemon.com>, Luke D says...

Do you really need to store the whole source?  Wouldn't just the type info be
sufficient, or even just the name of the file where the type info can be found?
I doubt Intellisence stores the whole source.

Forgive me if I'm misinformed.


Forgive me if I miss lead you. You are right.
The idea was to store the entire source code in a data base
instead of using a file system.

Of course if the source is on a file you parse it and
store only the info you are going to use.

for a minute there I thought you had looked at my source
code as I'm storing the function bodies. But that's
just an hack because I didn't create a method to
extract a range of lines of text from the scintilla component.
It's a pain: gotta get the position from each line
then get the lenght of text then...
So that hack was a simple way of testing the function parser.
only the current function (method) needs to be parsed (eventually)
the other function bodies are skipped.

AH! AH! why store the start and end line of the functions?
what I need is the start and end positions (offset) on the entire text.
And thats valid for every element type (enums, structs, classes...).
(thanks)

Ant

dictionaryCheck("Intellisence") ? "Intellisence" : "Intellisense";


In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...

sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...

 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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.


 of course the best way to do it is to forget the
 file system altogether and store the source code
 on a data base.
 The compiler should be able to accept a stream of
 data instead of files.
 (we can always generate files on compilation time
 for the compiler use)
 To do the intellisense searches we would just throw
 a sql select to our database.
 We could also store the object files (units)
 with dates and times and compilation options...

 I actually thought of doing that when I started the leds
 project but I decided to go conservative as I needed
 a tool immediately.

 (don't be surprised if in the future the leds dependencies
 include PostgreSQL;)

 Ant









 Jan 06 2004



prev sibling  parent  "C" <dont respond.com>  writes:


For just intellisense I imagine the tags would be sufficient , you probably
want something in memory though.  MSVC 6's tags and code completeion suck ,
most of the time it just plain does not work for me.

I probably wouldnt put source files into a DB , only to write them to hard
drive again.  Though I like the idea of streaming data to the compiler :).

C

"Luke D" <Luke_member pathlink.com> wrote in message
news:btfj9e$2a2j$1 digitaldaemon.com...

 Do you really need to store the whole source?  Wouldn't just the type info


be

 sufficient, or even just the name of the file where the type info can be


found?

 I doubt Intellisence stores the whole source.

 Forgive me if I'm misinformed.

 In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...

sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...

 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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.


 of course the best way to do it is to forget the
 file system altogether and store the source code
 on a data base.
 The compiler should be able to accept a stream of
 data instead of files.
 (we can always generate files on compilation time
 for the compiler use)
 To do the intellisense searches we would just throw
 a sql select to our database.
 We could also store the object files (units)
 with dates and times and compilation options...

 I actually thought of doing that when I started the leds
 project but I decided to go conservative as I needed
 a tool immediately.

 (don't be surprised if in the future the leds dependencies
 include PostgreSQL;)

 Ant









 Jan 06 2004



prev sibling next sibling parent  Ant <Ant_member pathlink.com>  writes:


In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...

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


how about another one:
- if the module name doens't start with a capital letter
  it doesn't define 1 and only 1 object.

so we could have
dui.Widget
dui.Window
for the classes Widget and Window and
dui.all
for ease of importing a bunch of things or
dui.structs
dui.fontStructs
to import all the necessary structures for a task.

that would get rid of some excess rigidity that might
not be really necessary
and would also be 'almost' intellisense 'friendly'.

I think I like it.
prepare to change your dui applications ;)
(oh! no! - say 3 million people around the world)

Of course we still have the friend across modules problem
(thanks for the example guys).

Ant



 Jan 06 2004



prev sibling  parent reply J C Calvarese <jcc7 cox.net>  writes:


Ant wrote:

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


At the risk of the changing the subject, have you thought of making use 
of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund

I've only briefly used it, but it seems to work (and the D community 
really needs tools like this).  And I love the price:
  * Permission to use, copy, modify, distribute and sell this software
  * and its documentation for any purpose is hereby granted without fee,
  * provided that the above copyright notice appear in all copies and
  * that both that copyright notice and this permission notice appear
  * in supporting documentation. It is provided "as is" without express
  * or implied warranty.

-- 
Justin
http://jcc_7.tripod.com/d/



 Jan 06 2004



  parent reply Ant <Ant_member pathlink.com>  writes:


In article <btfurs$2u1o$1 digitaldaemon.com>, J C Calvarese says...

Ant wrote:

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


At the risk of the changing the subject, have you thought of making use 
of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund

I've only briefly used it, but it seems to work (and the D community 
really needs tools like this).  And I love the price:
  * Permission to use, copy, modify, distribute and sell this software
  * and its documentation for any purpose is hereby granted without fee,
  * provided that the above copyright notice appear in all copies and
  * that both that copyright notice and this permission notice appear
  * in supporting documentation. It is provided "as is" without express
  * or implied warranty.

-- 
Justin
http://jcc_7.tripod.com/d/


Initially yes, that's why I looked at it
and made some suggestions.
but I ended up integrating every thing into
my code browser parser.

see the first post on this thread to understant what
I mean by that. (or lets move this conversation
to the leds group before someone complains about it...:(

Ant



 Jan 06 2004



 next sibling parent  Ant <duitoolkit yahoo.ca>  writes:


On Wed, 07 Jan 2004 04:54:55 +0000, Ant wrote:


 In article <btfurs$2u1o$1 digitaldaemon.com>, J C Calvarese says...

 have you thought of making use 
of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund

-- 
Justin
http://jcc_7.tripod.com/d/


 
 Initially yes, that's why I looked at it
 and made some suggestions.
 but I ended up integrating


I don't mean his code... I mean the possibility
of browsing the import dependencies tree...
No illigal use of anyone else's code.

Ant



 Jan 06 2004



prev sibling  parent reply J C Calvarese <jcc7 cox.net>  writes:


Ant wrote:

 In article <btfurs$2u1o$1 digitaldaemon.com>, J C Calvarese says...
 

Ant wrote:


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


At the risk of the changing the subject, have you thought of making use 
of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund




...

 Initially yes, that's why I looked at it
 and made some suggestions.
 but I ended up integrating every thing into
 my code browser parser.


I thought you had noticed it.  (I guess I just wanted to make sure you 
hadn't forgotten about it.)


 
 see the first post on this thread to understant what
 I mean by that. 


After re-reading your original post (again), I can see better where 
you're coming from.  I guess part of the challenge is that when the goal 
is so ambitious it's hard to draw boundaries and the one-class/one-file 
idea could made life much easier for the code lookup routine (probably 
at small cost).


 (or lets move this conversation
 to the leds group before someone complains about it...:(


I think we should be able to talk about D code in the D group. :)


 
 Ant



-- 
Justin
http://jcc_7.tripod.com/d/



 Jan 06 2004



  parent  Ant <Ant_member pathlink.com>  writes:


In article <btg4r9$6jp$1 digitaldaemon.com>, J C Calvarese says...

Ant wrote:

 In article <btfurs$2u1o$1 digitaldaemon.com>, J C Calvarese says...
 

Ant wrote:


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


At the risk of the changing the subject, have you thought of making use 
of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund




...

 Initially yes, that's why I looked at it
 and made some suggestions.
 but I ended up integrating every thing into
 my code browser parser.


I thought you had noticed it.  (I guess I just wanted to make sure you 
hadn't forgotten about it.)


 
 see the first post on this thread to understant what
 I mean by that. 


 After re-reading your original post (again)


is it that badly written... :{  :)


, I can see better where 
 you're coming from.  I guess part of the challenge is that when the goal 
 is so ambitious it's hard to draw boundaries and the one-class/one-file 
 idea could made life much easier for the code lookup routine (probably 
 at small cost).


maybe it's not as bad as I thought.
dui has 51000 lines and dmd compiles it
in about 3 seconds (less after the first time)
so even if code lookup has to parse most of the
files it should be fast enough.

But that's not only for the automatic parsers.
It's for the human users also.
I used to work on a system where the source files
were named TCS0234, TCS2567, TCS1103
(oops... now you know how old I am)
the really sad thing is that you end up memorizing
which number correspond to what routines...

Ant



 Jan 06 2004