• Dan Liebgold (8/8) Feb 27 2003 Would it be possible to keep imports out of the symbol table? For exampl...
• Dan Liebgold (10/18) Feb 27 2003 Hmmm, I suppose disambiguating a name by prefixing the module is the
• Walter (10/34) Mar 02 2003 One thing I tried to get away from is the C++ distinction between ., -> ...
• Sean L. Palmer (21/25) Mar 02 2003 Is there any way we can remove the need for -> for dereferencing pointer...

"Dan Liebgold" <dliebgold yahoo.com> writes:

Would it be possible to keep imports out of the symbol table? For example,
this won't compile:

import timer;

TIMERCLASS timer;

...because the instance timer conflicts with the import name. There doesn't
seem to be any need for the import name in among the symbols, or at least
none that I can see.

Dan

"Dan Liebgold" <dliebgold yahoo.com> writes:

Hmmm, I suppose disambiguating a name by prefixing the module is the
problem. That could be solved through a naming convention. One could also
complicate the syntax and use something other than "." for module
disamibuation -- an example for below is timer.Reset(): does it call the
Reset() function in module timer, or the method of class TIMERCLASS?.  Use
timer::Reset() for the module?   I suppose that decision's been made...

Dan

"Dan Liebgold" <dliebgold yahoo.com> wrote in message
news:b3kh24$qi0$1 digitaldaemon.com...
 Would it be possible to keep imports out of the symbol table? For example,
 this won't compile:

 import timer;

 TIMERCLASS timer;

 ...because the instance timer conflicts with the import name. There

doesn't
 seem to be any need for the import name in among the symbols, or at least
 none that I can see.

 Dan

"Walter" <walter digitalmars.com> writes:

One thing I tried to get away from is the C++ distinction between ., -> and
::. I also want to get away from all the various context dependent lookup
rules in C++, preferring a more straightforward set of rules even if
sometimes it results in extra typing.

Of course, D isn't pure this way, as goto labels in functions are in a
separate symbol table.

"Dan Liebgold" <dliebgold yahoo.com> wrote in message
news:b3kht8$r4o$1 digitaldaemon.com...
 Hmmm, I suppose disambiguating a name by prefixing the module is the
 problem. That could be solved through a naming convention. One could also
 complicate the syntax and use something other than "." for module
 disamibuation -- an example for below is timer.Reset(): does it call the
 Reset() function in module timer, or the method of class TIMERCLASS?.  Use
 timer::Reset() for the module?   I suppose that decision's been made...

 Dan

 "Dan Liebgold" <dliebgold yahoo.com> wrote in message
 news:b3kh24$qi0$1 digitaldaemon.com...
 Would it be possible to keep imports out of the symbol table? For


example,
 this won't compile:

 import timer;

 TIMERCLASS timer;

 ...because the instance timer conflicts with the import name. There

 doesn't
 seem to be any need for the import name in among the symbols, or at


least
 none that I can see.

 Dan

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

Is there any way we can remove the need for -> for dereferencing pointers?

struct A
{
    int m1, m2;
}

A* pa = new A;

pa.m1 = pa.m2;

But then we get into trouble with pointers to pointers

A* pa = new A;
A** ppa = &pa;

ppa.m1 = ppa.m2;  // requires multiple dereferences

// but what happens if you only wanted to dereference once?

(*ppa + 1).m1 = ppa.m1;  // confusing

Perhaps we could eliminate *p syntax as well?

ppa .  = new A;  // but dot is small and easily overlooked.

In this case there's probably more reasons to stick with C syntax than there
are to change it.

Sean



"Walter" <walter digitalmars.com> wrote in message
news:b3tqe6$k47$1 digitaldaemon.com...
 One thing I tried to get away from is the C++ distinction between ., ->

and
 ::. I also want to get away from all the various context dependent lookup
 rules in C++, preferring a more straightforward set of rules even if
 sometimes it results in extra typing.