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

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
>

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

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

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

C wrote:
> 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 :).

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 Ludwig Maximillian University (LMU), which is also in München, and offers almost all the same study courses and many more. LMU is good for its non-technical faculties, such as law, biology, medicine, and so on. We also have a medical faculty, but even it is technologically biased. 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 professors are quite active in research.

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

-eye

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

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

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

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