On Sat, 28 May 2005 22:27:58 -0700, Kris wrote:

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

I'm still digesting this...but in the meantime ...

What is the problem that inner classes solve?

-- 
Derek Parnell
Melbourne, Australia
29/05/2005 1:49:28 PM

I understand motivation of having porting tool from Java. But as a concept delegates are just better.

One more: if I understand layout of inners correctly
then with having inners implemented we will have
"class instances allocated on stack" also. Am I right?

Andrew.



"Walter" <newshound@digitalmars.com> wrote in message news:d7aqja$1dos$1@digitaldaemon.com...
> 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 13:50:36 +1000, Derek Parnell wrote:

> On Sat, 28 May 2005 22:27:58 -0700, Kris wrote:
> 
>> "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.
> 
> I'm still digesting this...but in the meantime ...
> 
> What is the problem that inner classes solve?

Ok, after a little more research, it seems that I was correct in that the main benefit is to limit the scope of the inner class to that of the enclosing class. It reduces namespace pollution. The fact that it can access the members of the enclosing class is a natural 'side-effect' of that.

-- 
Derek Parnell
Melbourne, Australia
29/05/2005 6:07:41 PM

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

There is no function pointer nor delegate nor inner function/delegate in Java. Only classes. Inner and anonymous classes are just cheap design patches for having something like delegate.

99.99% of inner/anonymous class use cases in Java are just delegates and inner functions emulations. Verbose and ugly.

D is doing delegates and inner delegates in the right way. Much better than in Java.

See, in Java:

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

And in D:

class Outer
{
  public void actionPerformed(ActionEvent evt) { writefln("write some
thing"); }
  void foo() { addActionLister ( &actionPerformed ); }
}

-or just -

class Outer
{
   void foo()
   {
       addActionLister ( delegate void(ActionEvent evt)  { writefln("write
some thing"); }  );
   }
}

Little bit better and clear, isn't it?




"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

>
> I'm still digesting this...but in the meantime ...
>
> What is the problem that inner classes solve?
>

Inner classes in Java is what D already have -
inner delegates/functions.

Thus for D itself inners are not solving anything in principle just increase pollution of grammar.

As Walter clealry expressed they only needed for automated Java-to-D tool. Motivation is understandable and honorable.

I am pretty sure though that such a tool can always translate
Java's inner and anonymous classes into D
delegates and inner functions in 98% of cases.
Anyway zero effort Java-to-D  is a myth. Such
translation is will *always* need intervention and
debugging.

I've ported Harmonia (big part of it) from Java.
It took me half of man/month. Doing porting
I've improved source code a lot - as too many
optimisation technics and features are not available
in Java but available in D.

Other part was ported from C/C++ and practically
by just copy-n-paste. In fact porting C++ to D for me
was just 3 times easier than from Java to D.

This is my own experience.

Andrew.

I know almost nothing about Java. All I did in java was a lousy j2me game... What I know for sure is that it is slow (maybe after few years it wont be slow in it will ruler the world :). But I guess this will not reflect to D since it will not execute Java code like in the C case but instead convert it to D and compile it. What comes to my mind first, well second after that the Java syntax is ugly where it is not copied from C++, is that the Java code is relying on the Java std lib or whatever it is called. And it is a huge one. It covers gui, network, sound and everything else (let someone who deals with java complete this list)... And the more important part is that this library is machine/platform independent because it is executed in the java virtual machine... How the HELL you gonna make this thing work with D?

P.S. I don't like the idea. Java is everything I want to escape from with D. C/C++ is too old and needs replacement. I believe java/c# is not that replacement. I prefer to write C wrapers... But it requires a lot of entusiasm and this is a big issue. Still, I believe a better solution is required. And I don't know what your conversation with Kris was. Maybe this is the best solution. The other thing I don't agree is that D needs to reuse all the existing code in the world. It is like.. I don't know. When you no longer can use a buildning, no longer can upgrade it and need a better one, you raze to the ground and buid it once again. And D shouldn't be the next upgrade for this C++ building (even less to java). Well if you want to make money with it you go with the java way. But I think you can't just make people use D. When they come with the idea D is worthy language they will write D native (I mean in D not reusing the old ones) gui and whatever libraries. If someone use D to for his favourite old library be it java,c++ or whatever he better stays with it. This is the same issue microsoft have with their win32 lib, because it is C... But all they need is money and they can't stop support it. Otherwise they would throw it all away and go with something totally new. This is what D needs to do in my opinion. Not relying on some old code...

In article <d7aqja$1dos$1@digitaldaemon.com>, Walter says...
>
>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.
>
>

"Walter" <newshound@digitalmars.com> wrote in message news:d7aqja$1dos$1@digitaldaemon.com...
> 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.

Yes yes yes yes yes yes yes yes yes!

Wooooooo!

In article <d7c03s$27lf$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I've ported Harmonia (big part of it) from Java.
>It took me half of man/month. Doing porting
>I've improved source code a lot - as too many
>optimisation technics and features are not available
>in Java but available in D.
>

In your Harmonia porting efforts, did you have to port Java inner classes to delegates as well? If so, was it something you think could be automated reasonably well w/o adding 'inner classes' to D?

Yes. This is the approach I currently used while porting SWT to DWT, but partially. The original APIs are kept for compatibility.


"Andrew Fedoniouk" <news@terrainformatica.com> дÈëÏûÏ¢ÐÂÎÅ:d7bv4u$2705$1@digitaldaemon.com...
>> 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.
>
> There is no function pointer nor delegate nor inner function/delegate in Java. Only classes. Inner and anonymous classes are just cheap design patches for having something like delegate.
>
> 99.99% of inner/anonymous class use cases in Java are just delegates and inner functions emulations. Verbose and ugly.
>
> D is doing delegates and inner delegates in the right way. Much better than in Java.
>
> See, in Java:
>
> class Outer{
> void foo(){
>    class NewActionListen : ActionListener{
>         public void actionPerformed(ActionEvent evt){
>            writefln("write some thing");
>         }
>    }
>    addActionLister(new NewActionListener());
> }
> }
>
> And in D:
>
> class Outer
> {
>  public void actionPerformed(ActionEvent evt) { writefln("write some
> thing"); }
>  void foo() { addActionLister ( &actionPerformed ); }
> }
>
> -or just -
>
> class Outer
> {
>   void foo()
>   {
>       addActionLister ( delegate void(ActionEvent evt)  { writefln("write
> some thing"); }  );
>   }
> }
>
> Little bit better and clear, isn't it?
>
>
>
>
> "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
>
> 

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7bsv8$25o0$3@digitaldaemon.com...
> I understand motivation of having porting tool from Java. But as a concept delegates are just better.

I agree. But inner classes aren't conceptually the same thing, so a design wrapped around inner classes would need to be reengineered.

> One more: if I understand layout of inners correctly
> then with having inners implemented we will have
> "class instances allocated on stack" also. Am I right?

No, that's a separate issue.