This is based on discussions of mine with Kris where we were looking for a solution:

D can access existing code written in C very will. It's not hard to create a D interface to any C module. One can do it by rote with minimal effort.

The problem is that a lot of the libraries that D needs, like GUI libraries, are written in C++. C++ code tends to be so quirky, and and so wrapped up in its need to explicitly manage memory, that it is very resistent to rote translation into D (or any other language).

One could run C++ through one of the C++ to C translators, and then do an interface to the C. But the C code emitted is something only a machine could love, and is not something D programmers would want to deal with. It is not really a viable solution. One could adapt one of the, say, C++ to Python bindings, but the end result of that just isn't attractive either.

I've looked at doing a hand translation of C++ gui libraries. No dice, the sheer volume of code makes it completely impractical.

On the other hand, Java is a fairly simple language. It can be rote translated into many other languages, including C, C++ and D. There exists tons of Java code, including GUIs, with open source licenses that permit translation. The translation into D would retain enough of its original character to enable leveraging the existing documentation for the Java version as well.

Kris has made a lot of progress building such a translator. He suggested that the only remaining large obstacle is that much otherwise translatable Java code is wrapped around use of inner classes, and D doesn't have inner classes. Workarounds are ugly, and would cause it to lose the "character" of the way the code is designed to work.

Using a Java to D translator will still require an expert hand to guide it, since there are many semantic differences, subtle and not so subtle (such as arrays, order of evaluation, strings, overload resolution, conversion rules, etc.). Kris has experience with this, and he believes these issues are managable.

So, the result is that Kris has convinced me to support inner classes in D. This is a heads up that such change is coming. It shouldn't affect any existing code, unless that code uses nested classes. To prepare for the future, declare these nested classes as "static class ...", and they'll continue to work in the future as they do currently. I don't have a schedule for this change yet, as it is not a simple "drop in" into the compiler. A fair amount of engineering needs to be done.

No analogous "inner struct" support is planned.

In article <d7aqja$1dos$1@digitaldaemon.com>, Walter says...
>
>[snip]
>
>So, the result is that Kris has convinced me to support inner classes in D. This is a heads up that such change is coming. It shouldn't affect any existing code, unless that code uses nested classes. To prepare for the future, declare these nested classes as "static class ...", and they'll continue to work in the future as they do currently. I don't have a schedule for this change yet, as it is not a simple "drop in" into the compiler. A fair amount of engineering needs to be done.
>

Walter, I for one anxiously await this in D (dmd 0.126?). Having been inside the front-end a few times myself, I know this cannot be easy to implement.  My hat is off to you good sir.

Thanks again for all the hard work and effort.

- EricAnderton at yahoo

In article <d7aqja$1dos$1@digitaldaemon.com>, Walter says...
>
..
>
>So, the result is that Kris has convinced me to support inner classes in D. This is a heads up that such change is coming. It shouldn't affect any existing code, unless that code uses nested classes. To prepare for the future, declare these nested classes as "static class ...", and they'll continue to work in the future as they do currently. I don't have a schedule for this change yet, as it is not a simple "drop in" into the compiler. A fair amount of engineering needs to be done.
>
>No analogous "inner struct" support is planned.
>

Since I lack knownledge about Java, what exactly is the differents between a nested class, and a inner class? Could someone please shine some light on this subject.

Thanks in advance,
David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

In article <d7avqg$1gv1$1@digitaldaemon.com>, David L. Davis says...
>
>Since I lack knownledge about Java, what exactly is the differents between a nested class, and a inner class? Could someone please shine some light on this subject.
>
>Thanks in advance,
>David L.

I was a tad curious myself, as I wasn't 100% sure what the actual difference was Here we go:

http://www.cs.rice.edu/~cork/book/node80.html

Unlike nested classes, inner classes get an implicit pointer to the enclosing class instance.

I'm *assuimg* that our new inner class feature will add an 'outer' keyword to talk to the outer class.

> class Outer{
>    int member;
>    class Inner{
>       void foo(){
>           writefln("%d",outer.member);
>       }
>    }
>    void bar(){
>        (new Inner()).foo();
>    }
> }

void main(){
(new Outer()).bar();

new Outer.Inner(); // Error: no enclosing instance 'Outer' for class 'Inner'.
}

- EricAnderton at yahoo

Walter wrote:
> This is based on discussions of mine with Kris where we were looking for a
> solution:
> 
> D can access existing code written in C very will. It's not hard to create a
> D interface to any C module. One can do it by rote with minimal effort.
> 
> The problem is that a lot of the libraries that D needs, like GUI libraries,
> are written in C++. C++ code tends to be so quirky, and and so wrapped up in
> its need to explicitly manage memory, that it is very resistent to rote
> translation into D (or any other language).
> 
> One could run C++ through one of the C++ to C translators, and then do an
> interface to the C. But the C code emitted is something only a machine could
> love, and is not something D programmers would want to deal with. It is not
> really a viable solution. One could adapt one of the, say, C++ to Python
> bindings, but the end result of that just isn't attractive either.
> 
> I've looked at doing a hand translation of C++ gui libraries. No dice, the
> sheer volume of code makes it completely impractical.
> 
> On the other hand, Java is a fairly simple language. It can be rote
> translated into many other languages, including C, C++ and D. There exists
> tons of Java code, including GUIs, with open source licenses that permit
> translation. The translation into D would retain enough of its original
> character to enable leveraging the existing documentation for the Java
> version as well.
> 
> Kris has made a lot of progress building such a translator. He suggested
> that the only remaining large obstacle is that much otherwise translatable
> Java code is wrapped around use of inner classes, and D doesn't have inner
> classes. Workarounds are ugly, and would cause it to lose the "character" of
> the way the code is designed to work.
> 
> Using a Java to D translator will still require an expert hand to guide it,
> since there are many semantic differences, subtle and not so subtle (such as
> arrays, order of evaluation, strings, overload resolution, conversion rules,
> etc.). Kris has experience with this, and he believes these issues are
> managable.
> 
> So, the result is that Kris has convinced me to support inner classes in D.
> This is a heads up that such change is coming. It shouldn't affect any
> existing code, unless that code uses nested classes. To prepare for the
> future, declare these nested classes as "static class ...", and they'll
> continue to work in the future as they do currently. I don't have a schedule
> for this change yet, as it is not a simple "drop in" into the compiler. A
> fair amount of engineering needs to be done.
> 
> No analogous "inner struct" support is planned.
> 
> 

After working on manual translation of parts of DWT myself in the past, I totally support the idea of inner classes.  I discussed this with Kris recently and am convinced that this is the way to go.

Thanks for listening, Walter.  Kris has accomplished a lot already, so I'm thrilled to see that you were willing to work with him on this to take things the final distance.

-JJR

"pragma" <pragma_member@pathlink.com> дÈëÏûÏ¢ÐÂÎÅ:d7b5hn$1knd$1@digitaldaemon.com...
> In article <d7avqg$1gv1$1@digitaldaemon.com>, David L. Davis says...
>>
I think the inner class is a class embeded in a function.

class Outer{
    int member;
    void func(){};

    void bar(){
     int barNumber;
     void innerfunc(){};
     class Inner{
         int myownMember;
         void foo(){
             writefln("%d",outer.member);    // Error, currently
             writefln("%d",barNumber);       // Error, currently
             writefln("%d",myownMember);     // OK
             func();                         // error,
             outer.func();                   // error, where can we get
outer?
             innerfunc();                    // maybe error, I am not sure.
         }
     }
     (new Inner()).foo();
    }
 }

 void main(){
 (new Outer()).bar();
 }

this kind of inner class can work currently, excepte that it can not access neither the Outer's member nor the member declared in function bar();

This kind of technology is widly used in java.

class Outer{
void foo(){
    class NewActionListen : ActionListener{
         public void actionPerformed(ActionEvent evt){
            writefln("write some thing");
         }
    }
    addActionLister(new NewActionListener());
}
}

and is the same as the following code.

class Outer{
void foo(){
    addActionLister(new ActionListener(){
        public void actionPerformed(ActionEvent evt){
            writefln("write some thing");
        }
   };
}
}
We call the later "anonymous class" since it was derived from a base class
but has not been assigned a name.

D rejects the later and accepts the former syntax. But the frame inside foo() and Outer class can't be access by the inner class method.


I solve by passing the outer class instance into the inner class while port
SWT from java to d.
see the original code in last message.

class Outer{
    int member;
    void func(){};

    void bar(){
     int barNumber;
     void innerFunc();
     class Temp{
      Outer inst;
      int barNumber;
     }
     class Inner{
      Temp t;
      this(Temp tmp) {t = tmp;}
        int myownMember;
        void foo(){
            writefln("%d",t.inst.member);
            writefln("%d",t.barNumber);
            writefln("%d",myownMember);
            t.inst.func();
            // nested function, only in D
            innerFunc();// maybe error, java has no nested function
        }
     }
     Temp t = new Temp();
     t.inst = this;
     t.barNumber = barNumber;
     (new Inner(t)).foo();
    }
 }

 void main(){
 (new Outer()).bar();
 }

looks ugly but works.

Awesome, looks like both of you will have your work cut out :)
Goodluck.

Walter wrote:
> This is based on discussions of mine with Kris where we were looking for a
> solution:
> 
> D can access existing code written in C very will. It's not hard to create a
> D interface to any C module. One can do it by rote with minimal effort.
> 
> The problem is that a lot of the libraries that D needs, like GUI libraries,
> are written in C++. C++ code tends to be so quirky, and and so wrapped up in
> its need to explicitly manage memory, that it is very resistent to rote
> translation into D (or any other language).
> 
> One could run C++ through one of the C++ to C translators, and then do an
> interface to the C. But the C code emitted is something only a machine could
> love, and is not something D programmers would want to deal with. It is not
> really a viable solution. One could adapt one of the, say, C++ to Python
> bindings, but the end result of that just isn't attractive either.
> 
> I've looked at doing a hand translation of C++ gui libraries. No dice, the
> sheer volume of code makes it completely impractical.
> 
> On the other hand, Java is a fairly simple language. It can be rote
> translated into many other languages, including C, C++ and D. There exists
> tons of Java code, including GUIs, with open source licenses that permit
> translation. The translation into D would retain enough of its original
> character to enable leveraging the existing documentation for the Java
> version as well.
> 
> Kris has made a lot of progress building such a translator. He suggested
> that the only remaining large obstacle is that much otherwise translatable
> Java code is wrapped around use of inner classes, and D doesn't have inner
> classes. Workarounds are ugly, and would cause it to lose the "character" of
> the way the code is designed to work.
> 
> Using a Java to D translator will still require an expert hand to guide it,
> since there are many semantic differences, subtle and not so subtle (such as
> arrays, order of evaluation, strings, overload resolution, conversion rules,
> etc.). Kris has experience with this, and he believes these issues are
> managable.
> 
> So, the result is that Kris has convinced me to support inner classes in D.
> This is a heads up that such change is coming. It shouldn't affect any
> existing code, unless that code uses nested classes. To prepare for the
> future, declare these nested classes as "static class ...", and they'll
> continue to work in the future as they do currently. I don't have a schedule
> for this change yet, as it is not a simple "drop in" into the compiler. A
> fair amount of engineering needs to be done.
> 
> No analogous "inner struct" support is planned.
> 
> 

On Sun, 29 May 2005 11:01:44 +0800, Shawn Liu wrote:

> "pragma" <pragma_member@pathlink.com> дÈëÏûÏ¢ÐÂÎÅ:d7b5hn$1knd$1@digitaldaemon.com...
>> In article <d7avqg$1gv1$1@digitaldaemon.com>, David L. Davis says...
>>>
> I think the inner class is a class embeded in a function.

Can I gather from this that the main purpose of an inner class is to limit the scope of the class usage to the function or class that defines it? In other words, the only code that can create instances of an inner class, or use the members of an inner class, is code that is inside the enclosing function or class.

-- 
Derek Parnell
Melbourne, Australia
29/05/2005 2:09:19 PM

"class embedded within a function" is a misnomer, Derek.

An inner class is simply a class defined within the scope of another, with the property of being able to see attributes of its enclosing scope. One can emulate this to a degree by passing an outer class reference to the ctor of the inner, and using that as a dereferencing mechanism (as Shawn noted); that's typically how it's implemented under the covers. D Inner-functions have a similar property, where they can see the attributes of the enclosing function/method, along with the attributes of an enclosing class.

Certain languages also support the notion of anonymous classes, which have the property described above, but can also be specified (and instantiated) in a manner similar to anonymous delegates.

For all intents & purposes, a inner-class is just a typed collection of delegates; Some find it useful to think of them as "grown up delegates". These are very useful when working with certain kinds of Patterns, such as the Template Method and/or Adapter. Such usage is augmented by being able to easily access the enclosing scope, just as traditional delegates can & do.

- Kris



"Derek Parnell" <derek@psych.ward> wrote in message news:hozn11do353u.m8pxnm0crdmv.dlg@40tude.net...
> On Sun, 29 May 2005 11:01:44 +0800, Shawn Liu wrote:
>
> > "pragma" <pragma_member@pathlink.com>
дÈëÏûÏ¢ÐÂÎÅ:d7b5hn$1knd$1@digitaldaemon.com...
> >> In article <d7avqg$1gv1$1@digitaldaemon.com>, David L. Davis says...
> >>>
> > I think the inner class is a class embeded in a function.
>
> Can I gather from this that the main purpose of an inner class is to limit the scope of the class usage to the function or class that defines it? In other words, the only code that can create instances of an inner class, or use the members of an inner class, is code that is inside the enclosing function or class.
>
> -- 
> Derek Parnell
> Melbourne, Australia
> 29/05/2005 2:09:19 PM