Pavel \"EvilOne\" Minayev wrote:

> Once again, suppose there's a piece of code like that:
>
>     void X() { ... }
>
>     class B
>     {
>         void Y() { ... }
>     }
>
>     class C
>     {
>         void Y() { ... }
>     }
>
>     class A: B
>     {
>         void X() { ... }
>
>         void Y()
>         {
>             C B;
>             B.Y();
>             X();
>         }
>     }
>
> Question #1: how do I call the global X() from A.Y() (since
> simply typing X() would invoke A.X())?

Since you know the module name, why not:
   <module>.X();

> Question #2: how do I access method Y() of class B from A.Y()
> (since B.Y() will invoke method Y() of object C)?

this.B.Y()

This is just like in C++:

class foo
{
   int a;
 public:
   foo(int a) { this->a = a; };
}

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEAE349.BCF30DD7@deming-os.org...

> > Question #1: how do I call the global X() from A.Y() (since
> > simply typing X() would invoke A.X())?
>
> Since you know the module name, why not:
>    <module>.X();

And what if there's a local variable or class property
with the same name as module?

> > Question #2: how do I access method Y() of class B from A.Y()
> > (since B.Y() will invoke method Y() of object C)?
>
> this.B.Y()
>
> This is just like in C++:
>
> class foo
> {
>    int a;
>  public:
>    foo(int a) { this->a = a; };
> }

And what if B is not a local, but a class member?
This way, this.B.Y() will still call the wrong method...

What I'm in general trying to say is that I hate when
there are some ambiguities. Like in C++, if I have a
class Parser, I can declare objects as "Parser p".
However if I have a variable called Parser, I have
to use "class Parser p". The same case is here. Wouldn't
it be better to provide some completely distinct way
to call module globals (no ideas) and methods of base
class (I propose super(class).method)? Not only it
would ease the life of programmers (especially if you
are working with others' code... A.B - is A a class
or a variable? with super(A).B it's much clearer),
but also helped the compiler as well.

None of them. I intend to have it (the default D calling convention) unspecified, so the compiler will be free to use whatever works best for the code gen for that particular function. This makes interprocedural optimizations possible. I strongly dislike the pointless proliferation of calling conventions found in win32.

Since D must interface with existing C code, it must support them. Hence,
the extern(spec) construct.

Microsoft doesn't exactly use the stdcall for Windows API calls - first of all, it varies (pascal on 16 bit machines, syscall on OS/2), and second, they mangle the names differently than stdcall for system calls. After all, they are windows API calling conventions, and who (besides the compiler implementor) really cares what it is, so why not call it the "windows" calling convention? It's easy to remember <g>.

I called it "Pascal" rather than "pascal" because it is conventionally capitalized, just like fortran is normally "FORTRAN". I suppose it doesn't matter one way or the other.

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdiqf$2721$1@digitaldaemon.com...
> What is the default calling convention for D functions - cdecl, stdcall, pascal, fastcall?
>
>
> BTW I wonder why you define stdcall convention as
> extern(Windows)? It's not WinAPI-only, there are
> stdcall specifiers in C, C++ and Pascal, and I believe
> that most programmers know it as stdcall. And in
> general, although convention is not a keyword, as
> stated in the specs, it looks like that, so - IMHO -
> it should be in lower-case. The same for extern(Pascal) -
> extern(pascal) seems to look better and more familiar
> especially to those who, like me, are used to Borland's
> compilers.
>
>
>

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdfh6$253c$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9sdc1v$2167$1@digitaldaemon.com...
> > > Array slicing. What happens when I use the form
> > > a[x..y], and x is greater than y?
> > If you have array bounds checking turned on, an array bounds exception
> gets
> > thrown.
> And if not? I mean, since the copying code will, in general, be the loop (or am I wrong?), it simply won't do anything.

In general, if an exception will be thrown if checking is turned on, undefined behavior will result if checking is turned off.


> > > Class model. It says that for each class XXXX, an
> > > instance of Class is created, named ClassXXXX. What
> > > is Class (RTTI, I believe), what functionality it
> > > provides?
> > A way to examine the type and offset of each member, access to the finalizer, and (in the future) access to any classes it depends on.
> Ability to call methods of class by their name (a la IDispatch::Invoke)?

That's an open possibility.

> Also, if those Class objects are unused, will they still be there (thus cluttering the program with unnecessary info like class and method names)?

Yes.


> > > If I have a reference to object, how
> > > do I get the appropriate Class object?
> > There's a member function to get it. Or a property. I can't decide which <g>.
> object.class, probably?

Or .classinfo. Something like that.

> > > Methods of base class. How do I access them? I believe
> > > that super.method form is used to call methods of super
> > > class. But how to call a method of an arbitrary class
> > > in the hierarchy - super(class).method?
> > If class B is derived from A, you can also use:
> >     B b;
> >     b.A.foo();
> So, from withing B, I'd simply write:
>     A.foo();

Yes.

> > > Static methods. Can they be overridden? Can they be
> > > called in the same manner as non-static ones?
> > Yes, yes.
> So the following:
>     class A
>     {
>         static void B() { ... }
>     }
>     A a;
>     A::B();
>     a.B();    // the same?

Yes.

> is legal? If it is, will B() be aware that it is called in a
> different way?

Yes, yes.

Pavel \"EvilOne\" Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEAE349.BCF30DD7@deming-os.org...
>
> > > Question #1: how do I call the global X() from A.Y() (since
> > > simply typing X() would invoke A.X())?
> >
> > Since you know the module name, why not:
> >    <module>.X();
>
> And what if there's a local variable or class property
> with the same name as module?

Frankly, then you are a bad programmer :)  Seriously, though, I suppose you have a point.  It might be good to explicitly define syntax for such a circumstance.  Some possibilities for ways to access global module data as opposed to class variables:

module <moduleName>.X()
module.<moduleName>.X()
global.<moduleName>.X()

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter@digitalmars.com> wrote in message news:9sgcul$10f4$1@digitaldaemon.com...

> None of them. I intend to have it (the default D calling convention) unspecified, so the compiler will be free to use whatever works best for
the
> code gen for that particular function. This makes interprocedural optimizations possible. I strongly dislike the pointless proliferation of calling conventions found in win32.

Optimizations are good, but what about assembler routines? I believe that order of arguments on stack is not really important since you can use their names instead, but who should clean the stack - callee or caller?

BTW, another syntactic sugar suggestion - a short way to declare assembler rountines: make it so that body of function can consist of a single asm block:

    void DrawLine(int x1, int y1, int x2, int y2, int color) asm
    {
        // assembler code goes here
    }

Or an "asm" attibute:

    void asm DrawLine(int x1, int y1, int x2, int y2, int color) { ... }

This way, the only thing generated by the compiler itsel would be the typical entry code, everything else is on programmer's part.

Could be handy.

> Microsoft doesn't exactly use the stdcall for Windows API calls - first of all, it varies (pascal on 16 bit machines, syscall on OS/2), and second, they mangle the names differently than stdcall for system calls. After
all,
> they are windows API calling conventions, and who (besides the compiler implementor) really cares what it is, so why not call it the "windows" calling convention? It's easy to remember <g>.

Okay, I give up. You can be very persuasive, you know. =)

Concerning name mangling. Are you going to define a single scheme that must be used by each and any compiler, or is it implementation- defined?

I believe that extern() property states that function
has no body, so the following is illegal:

    extern(Windows) int WindowProc() { }

Is it so? If it is, how about WinAPI callbacks?



Is it legal to define names for parameters of extern
function? Is it legal to omit names of parameters
of implemented function? Like that:

    extern(Windows) int LineTo(HDC hDc, int x, int y);
    void TimerProc(HWND, uint, uint id, uint) { switch (id) { ... } }



How are function pointers declared? I remember a discussion of this topic not long ago, but what is the official way?



Are pointers to methods supported? Are they like in Delphi (kewl)
or in C++ (almost useless)?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEBCCF3.ABEBCB5@deming-os.org...

> Frankly, then you are a bad programmer :)  Seriously, though, I suppose

Definitely. However, we shouldn't discriminate =)

> you have a point.  It might be good to explicitly define syntax for such a circumstance.  Some possibilities for ways to access global module data as opposed to class variables:
>
> module <moduleName>.X()
> module.<moduleName>.X()
> global.<moduleName>.X()

I thought about it as well - since we have "this" to refer to current class, why not have something that refers to current module? "global" seems just fine to me, what about the others?

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sdigb$2715$1@digitaldaemon.com...
> What is the default attribute for class members
> (private/protected/public)?

Public. I always thought that C++'s way just made for annoying extra typing when banging out quick code. A production quality class should always say it explicitly.


> Suppose I have the following declaration:
>     int* x, y;
> Is y an int or a pointer to int?

An int. I didn't break away from C on that one. I can be persuaded otherwise.


> Once again, suppose there's a piece of code like that:
>     void X() { ... }
>     class B
>     {
>         void Y() { ... }
>     }
>     class C
>     {
>         void Y() { ... }
>     }
>     class A: B
>     {
>         void X() { ... }
>
>         void Y()
>         {
>             C B;
>             B.Y();
>             X();
>         }
>     }
>
> Question #1: how do I call the global X() from A.Y() (since
> simply typing X() would invoke A.X())?

Prefix it with the module name. Assume the module name is foo:

    foo.X()

> Question #2: how do I access method Y() of class B from A.Y()
> (since B.Y() will invoke method Y() of object C)?

A.B.Y()

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sg5vh$scq$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BEAE349.BCF30DD7@deming-os.org...
>
> > > Question #1: how do I call the global X() from A.Y() (since
> > > simply typing X() would invoke A.X())?
> >
> > Since you know the module name, why not:
> >    <module>.X();
>
> And what if there's a local variable or class property
> with the same name as module?
>
> > > Question #2: how do I access method Y() of class B from A.Y()
> > > (since B.Y() will invoke method Y() of object C)?
> >
> > this.B.Y()
> >
> > This is just like in C++:
> >
> > class foo
> > {
> >    int a;
> >  public:
> >    foo(int a) { this->a = a; };
> > }
>
> And what if B is not a local, but a class member?
> This way, this.B.Y() will still call the wrong method...
>
> What I'm in general trying to say is that I hate when
> there are some ambiguities. Like in C++, if I have a
> class Parser, I can declare objects as "Parser p".
> However if I have a variable called Parser, I have
> to use "class Parser p". The same case is here. Wouldn't
> it be better to provide some completely distinct way
> to call module globals (no ideas) and methods of base
> class (I propose super(class).method)? Not only it
> would ease the life of programmers (especially if you
> are working with others' code... A.B - is A a class
> or a variable? with super(A).B it's much clearer),
> but also helped the compiler as well.

Hmm. It might be a good idea to use the "." as meaning "at the module level", as in:

    .B();

The problem, though, is the . is almost invisible. Maybe:

    module.B();