www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inner classes

reply "Walter" <newshound digitalmars.com> writes:
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.
May 28 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
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
May 28 2005
prev sibling next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
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



 May 28 2005



  parent reply pragma <pragma_member pathlink.com>  writes:


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



 May 28 2005



  parent reply "Shawn Liu" <liuxuhong.cn gmail.com>  writes:


"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(); 



 May 28 2005



 next sibling parent reply "Shawn Liu" <liuxuhong.cn gmail.com>  writes:


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.



 May 28 2005



  parent reply John Demme <me teqdruid.com>  writes:


On Sun, 2005-05-29 at 11:31 +0800, Shawn Liu wrote:

 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.


Actually, they are not the same.  As I recall, each time the code for
the anonymous class is run, it creates a new class, whereas the inner
class is one class.  The anonymous classes are basically an inefficient
waste of memory.

John Demme



 May 29 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"John Demme" <me teqdruid.com> wrote in message 
news:1117411000.19815.7.camel localhost.localdomain...

 On Sun, 2005-05-29 at 11:31 +0800, Shawn Liu wrote:

 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.


 Actually, they are not the same.  As I recall, each time the code for
 the anonymous class is run, it creates a new class, whereas the inner
 class is one class.  The anonymous classes are basically an inefficient
 waste of memory.


On each invocation of foo() will be created new instance.
anonymous classes are exactly the same as inner classes,
they just have no name and their declaration implies
hidden 'new' call.

In Java inner classes have access to 'final' local
variables existing at the point of their definition.

There is no 'final' concept in D.



 May 29 2005



prev sibling  parent reply Derek Parnell <derek psych.ward>  writes:


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



 May 28 2005



 next sibling parent reply "Kris" <fu bar.com>  writes:


"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





 May 28 2005



  parent reply Derek Parnell <derek psych.ward>  writes:


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



 May 28 2005



 next sibling parent  Derek Parnell <derek psych.ward>  writes:


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



 May 29 2005



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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. 



 May 29 2005



  parent reply Dave <Dave_member pathlink.com>  writes:


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?



 May 29 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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?


j-smile:
http://www.terrainformatica.com/org/j-smile/index.htm
is the project I was porting from primarily.

j-smile is almost not using inner classes - listeners (AWT/SWING/SWT).
Just don't need them in sinking/bubbling event propagation schema.
All containers of some widget are by design listeners of all events
coming to the widget.

<side-note>
The problem with listeners is one: they are too heavy for massive
use in UI. (WinForms.NET inherits the same design flaw.)
Java listener implementation tries to satify patterns:
Listener, Observer-Observable, Model-View-Controller
for all events. This is just overkill for most of the events.
See: *each* Component in Java contains fields
   ComponentListener cmpListener;
   KeyListener keyListener;
   FocusListener focusListener;
   MouseListener mouseListener;
   MouseMotionListener motionListener;
   ActionListener actionListener;

which are not used in 99% of cases,
only actionListener is used frequently.

In contrary, in Harmonia, only concrete classes
allows you to attach listeners and moreover to
events where they really make sense, e.g.
class Button
{
   bool delegate(Widget) _on_click;
}
For other cases SINKING/BUBLING works
and costs pretty much nothing - does not take
any instance memory.
</side-note>

Typical uses cases of inner/anonymous classes
is event handlers. And this is used primarily
in UI. In Java there are just three UI libraries
in active use: AWT, SWING and SWT.
I think that AWT and SWING are not free for
porting in D. And for IBM's SWT Shawn Liu
already did an excellent job.
----------------------------------------
Other big area of Listeners use in Java
is in JSP/Servlet/Server Faces.
http://www.onjava.com/pub/a/onjava/excerpt/JSF_chap8/index.html?page=1

(Ommited: question of GC and memory pools in D -
imo, the must for server implementations )

This framework uses ActionEvents only, afaik, so


If so, was it something you think could be automated
 reasonably well w/o adding 'inner classes' to D?


See, typical pattern is

public class [[[NMTOKEN]]] implements ActionListener {
    ...
    public void processAction(ActionEvent e)
         throws AbortProcessingException {
        [[[ delegate function body ]]]
    }
}

This could be translated by using pretty simple Perl script into
simple inline delegate function declartion.

And call replacements:

addActionListener(ActionListener listener);
removeActionListener(ActionListener listener);

can be also automated by Perl.

disclaimer: I am not
a Java expert, my experience is
limited by Java GUI area.
My Java server side experience is rather
theoretical than practical.

Andrew.


"Dave" <Dave_member pathlink.com> wrote in message 
news:d7ch6m$2j3k$1 digitaldaemon.com...

 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?

 





 May 29 2005



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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 





 May 29 2005



 next sibling parent reply "Shawn Liu" <liuxuhong.cn gmail.com>  writes:


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


 





 May 29 2005



  parent reply Mark T <Mark_member pathlink.com>  writes:


In article <d7cmad$2nje$1 digitaldaemon.com>, Shawn Liu says...

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


If this port is going well then why would D need inner classes for a GUI?

We certainly don't need a slow Swing GUI ported to D. 



 May 29 2005



  parent  John Reimer <brk_6502 yahoo.com>  writes:


Mark T wrote:

 In article <d7cmad$2nje$1 digitaldaemon.com>, Shawn Liu says...
 

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


 
 If this port is going well then why would D need inner classes for a GUI?
 
 We certainly don't need a slow Swing GUI ported to D. 
 
 


Um... Swt is not Swing.



 May 29 2005



prev sibling  parent reply John Demme <me teqdruid.com>  writes:


On Sun, 2005-05-29 at 01:39 -0700, Andrew Fedoniouk wrote:

 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?


Sure delegates clearer for single functions like that, but inner classes
are much clearer whenever the listener has more than one method.
Delegates are handy, but are NOT a replacement for inner classes.
They're handy, too.

It's like the difference between a crescent wrench and a vice grip.  You
can use both of them to do a lot of things, but each shine for certain
things.  "The right tool for the right job" and props to Walter for
adding more tools to D's toolbox.

John Demme



 May 29 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"John Demme" <me teqdruid.com> wrote in message 
news:1117411282.19815.13.camel localhost.localdomain...

 On Sun, 2005-05-29 at 01:39 -0700, Andrew Fedoniouk wrote:

 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?


 Sure delegates clearer for single functions like that, but inner classes
 are much clearer whenever the listener has more than one method.
 Delegates are handy, but are NOT a replacement for inner classes.
 They're handy, too.

 It's like the difference between a crescent wrench and a vice grip.  You
 can use both of them to do a lot of things, but each shine for certain
 things.  "The right tool for the right job" and props to Walter for
 adding more tools to D's toolbox.

 John Demme


John, do you know a good example of
Inner class usage?

Let's take a look on what Sun recommends here:
http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html

Major design flaw here is in line:

public Iterator iterator() {
        return new StackIterator();
    }

each time when you need to enumerate such
stack you will allocate object StackIterator.

D way which can be used right now:

public class Stack {
    private Object[] items;

    // code for Stack's methods and constructors
    // not shown

    public Iterator iterator() {
        Iterator it; it.items = items; return it;
    }

    struct Iterator {
        Object[] items;

        public boolean hasNext() {
            ...
        }
        public Object next() {
            ...
        }
        public void remove() {
            ...
        }
    }
}

As you may see iterator() call will
not allocate any object on the heap.


Andrew.



 May 29 2005



  parent reply John Demme <me teqdruid.com>  writes:


Yeah.  So?  The only reason you can't do this in Java is because Java
doesn't have structs.  Although this may or may not be a good usage of
inner classes that doesn't mean that they're not good for anything.

In Java, some listeners have multiple methods.  Look at MouseListener:
interface MouseListener {
	void mouseClicked(MouseEvent e);
	void mouseEntered(MouseEvent e);
	void mouseExited(MouseEvent e);
	...
}

If I'm writing a button that changes when the mouse hovers, and
depresses when it gets clicked, a great way to do it would be with an
inner class that implements this listener.  Another way to do it would
be to register three separate delegates to do it.  I prefer the inner
class method as it looks cleaner, and it separates the event code from
the set up code.

In addition, this approach will not necessarily use more memory than the
delegate method.  With delegates, references to several classes and
function pointers must be stored.  Here, a class must be put on the
heap, and a since reference to it must be stored.  It seems that you are
afraid of heap allocation.  I, however, am not, and rather like this
approach.

I might also add that in your implementation of an iterator will not
work like the Java one.  Because you are not allocating anything on the
heap, any advances through the iterator will be ignored if not passed
back.  Not necessarily an issue, but your code is NOT equivalent to the
Java code as you have implied it is.  Personally, I prefer the Java
approach.  It looks cleaner to me, and is more consistent.  You are
mixing classes and structs in your's.  I prefer not to do this without
good reason.

John Demme

On Sun, 2005-05-29 at 17:39 -0700, Andrew Fedoniouk wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:1117411282.19815.13.camel localhost.localdomain...

 On Sun, 2005-05-29 at 01:39 -0700, Andrew Fedoniouk wrote:

 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?


 Sure delegates clearer for single functions like that, but inner classes
 are much clearer whenever the listener has more than one method.
 Delegates are handy, but are NOT a replacement for inner classes.
 They're handy, too.

 It's like the difference between a crescent wrench and a vice grip.  You
 can use both of them to do a lot of things, but each shine for certain
 things.  "The right tool for the right job" and props to Walter for
 adding more tools to D's toolbox.

 John Demme


 
 John, do you know a good example of
 Inner class usage?
 
 Let's take a look on what Sun recommends here:
 http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html
 
 Major design flaw here is in line:
 
 public Iterator iterator() {
         return new StackIterator();
     }
 
 each time when you need to enumerate such
 stack you will allocate object StackIterator.
 
 D way which can be used right now:
 
 public class Stack {
     private Object[] items;
 
     // code for Stack's methods and constructors
     // not shown
 
     public Iterator iterator() {
         Iterator it; it.items = items; return it;
     }
 
     struct Iterator {
         Object[] items;
 
         public boolean hasNext() {
             ...
         }
         public Object next() {
             ...
         }
         public void remove() {
             ...
         }
     }
 }
 
 As you may see iterator() call will
 not allocate any object on the heap.
 
 
 Andrew.
 
 
 





 May 29 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"John Demme" <me teqdruid.com> wrote in message 
news:1117416407.19815.43.camel localhost.localdomain...

 Yeah.  So?  The only reason you can't do this in Java is because Java
 doesn't have structs.  Although this may or may not be a good usage of
 inner classes that doesn't mean that they're not good for anything.

 In Java, some listeners have multiple methods.  Look at MouseListener:
 interface MouseListener {
 void mouseClicked(MouseEvent e);
 void mouseEntered(MouseEvent e);
 void mouseExited(MouseEvent e);
 ...
 }


Ok. As Harmonia solves this without need of
any listenters in this case then this
vaporized from my memory. Thanks for remainding
it.


 If I'm writing a button that changes when the mouse hovers, and
 depresses when it gets clicked, a great way to do it would be with an
 inner class that implements this listener.  Another way to do it would
 be to register three separate delegates to do it.  I prefer the inner
 class method as it looks cleaner, and it separates the event code from
 the set up code.


Cleaner than what?

class MyCompoundControl {}
{
    void onButtonMouseClick() {...}
    ....
    this() {
      button.onClick = &onButtonMouseClick;
   }
}


 Another way to do it would
 be to register three separate delegates to do it.


What is better:
1) To define inner class and  to write three implementations
of listener methods in it,
-or just-
2) to write three implementations (if you need them all)
of listener methods?

What is clearer, natural, readable and simpler?
I really want but cannot understand you.


 In addition, this approach will not necessarily use more memory than the
 delegate method.  With delegates, references to several classes and
 function pointers must be stored.  Here, a class must be put on the
 heap, and a since reference to it must be stored.  It seems that you are
 afraid of heap allocation.  I, however, am not, and rather like this
 approach.

 I might also add that in your implementation of an iterator will not
 work like the Java one.  Because you are not allocating anything on the
 heap, any advances through the iterator will be ignored if not passed
 back.  Not necessarily an issue, but your code is NOT equivalent to the
 Java code as you have implied it is.  Personally, I prefer the Java
 approach.  It looks cleaner to me, and is more consistent.  You are
 mixing classes and structs in your's.  I prefer not to do this without
 good reason.

 John Demme

 On Sun, 2005-05-29 at 17:39 -0700, Andrew Fedoniouk wrote:

 "John Demme" <me teqdruid.com> wrote in message
 news:1117411282.19815.13.camel localhost.localdomain...

 On Sun, 2005-05-29 at 01:39 -0700, Andrew Fedoniouk wrote:

 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?


 Sure delegates clearer for single functions like that, but inner 
 classes
 are much clearer whenever the listener has more than one method.
 Delegates are handy, but are NOT a replacement for inner classes.
 They're handy, too.

 It's like the difference between a crescent wrench and a vice grip. 
 You
 can use both of them to do a lot of things, but each shine for certain
 things.  "The right tool for the right job" and props to Walter for
 adding more tools to D's toolbox.

 John Demme


 John, do you know a good example of
 Inner class usage?

 Let's take a look on what Sun recommends here:
 http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html

 Major design flaw here is in line:

 public Iterator iterator() {
         return new StackIterator();
     }

 each time when you need to enumerate such
 stack you will allocate object StackIterator.

 D way which can be used right now:

 public class Stack {
     private Object[] items;

     // code for Stack's methods and constructors
     // not shown

     public Iterator iterator() {
         Iterator it; it.items = items; return it;
     }

     struct Iterator {
         Object[] items;

         public boolean hasNext() {
             ...
         }
         public Object next() {
             ...
         }
         public void remove() {
             ...
         }
     }
 }

 As you may see iterator() call will
 not allocate any object on the heap.


 Andrew.


 





 May 29 2005



prev sibling next sibling parent  John Reimer <brk_6502 yahoo.com>  writes:


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



 May 28 2005



prev sibling next sibling parent  clayasaurus <clayasaurus gmail.com>  writes:


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.
 
 





 May 28 2005



prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


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.

 





 May 29 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


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



 May 29 2005



 next sibling parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


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


Generally speaking, yes. But 99% of
transformation of real code of inners
can be handled by using dumb Perl script.  imho.
Name the project/technology where you think
such java-to-D tool makes sense.
I don't know any case where Java-to-D
could be used without reengineered.
(inners are just very small part of the problem).

Again: conceptually speaking inners were invented
for close of the hole of luck of funtion pointers and
delegates. And inners in Java are used primarily for delegate
emulation and exactly in the same pattern.

Andrew.



 May 29 2005



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 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.


This is one of refactoring features of IntelliJ
http://www.jetbrains.com/idea/features/refactoring.html

--------------
Convert Anonymous Class to Inner

Invoke this refactoring on an anonymous class to convert it to a named inner 
class. If the anonymous class accesses local variables, a constructor will 
be created for the inner class and values of the accessed variables will be 
passed to it. If the anonymous class is located in a non-static method, you 
may also choose an option to pass a reference to the outer class to the 
constructor. It is especially useful to apply this refactoring to large 
anonymous classes, so that the code becomes more readable. Additional 
benefit is the possibility to share the functionality provided by the inner 
class.
--------------

I think that using such tool you can prepare your
Java code to be converted into D without need of
inners in D.

Andrew.



 May 29 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7d8rp$7n1$1 digitaldaemon.com...

 I think that using such tool you can prepare your
 Java code to be converted into D without need of
 inners in D.


I agree, technically it can be done. But it isn't just a matter of making
the code work. We also need to leverage the existing *documentation*,
because the inner classes are meant to be written in user code that drives
the GUI, and that is how the documentation is written.



 May 30 2005



  parent reply Sean Kelly <sean f4.ca>  writes:


In article <d7elcs$1jkk$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7d8rp$7n1$1 digitaldaemon.com...

 I think that using such tool you can prepare your
 Java code to be converted into D without need of
 inners in D.


I agree, technically it can be done. But it isn't just a matter of making
the code work. We also need to leverage the existing *documentation*,
because the inner classes are meant to be written in user code that drives
the GUI, and that is how the documentation is written.


I don't see anything strikingly wrong with having inner classes in D.  They
aren't as neccesary as they are in Java (because D isn't so prohibitively object
oriented) but they do offer a convenient alternative for structuring code.  And
since adding them will allow us to leverage a significant amount of pre-existing
code from Java, I really don't see anything bad about this decision (and I'm a
C++ person, not a Java person).  This is great news.


Sean



 May 30 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:d7fg99$2ft0$1 digitaldaemon.com...

 In article <d7elcs$1jkk$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7d8rp$7n1$1 digitaldaemon.com...

 I think that using such tool you can prepare your
 Java code to be converted into D without need of
 inners in D.


I agree, technically it can be done. But it isn't just a matter of making
the code work. We also need to leverage the existing *documentation*,
because the inner classes are meant to be written in user code that drives
the GUI, and that is how the documentation is written.


 I don't see anything strikingly wrong with having inner classes in D. 
 They
 aren't as neccesary as they are in Java (because D isn't so prohibitively 
 object
 oriented) but they do offer a convenient alternative for structuring code. 
 And
 since adding them will allow us to leverage a significant amount of 
 pre-existing
 code from Java, I really don't see anything bad about this decision (and 
 I'm a
 C++ person, not a Java person).  This is great news.


In Java inner class instance has parent reference declared as final.

D has no const. Dot.

Imagine what will happened with inner instances in case of outer will be 
declared
as auto. All sorts of problems like this.

And add here all problems related to grammar pollution:

Outer o = getSomeOuter();
Outer.Inner i = o.new Inner();

Nice, eh?



 May 30 2005



prev sibling next sibling parent reply bobef <bobef_member pathlink.com>  writes:


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.

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.





 May 29 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"bobef" <bobef_member pathlink.com> wrote in message
news:d7cfoi$2hsr$1 digitaldaemon.com...

 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.


Inner classes are not a cause of slow Java programs, so no need to worry
there.


 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?


Good point - the underlying Java standard library is not going to be
converted. However, it turns out to be not necessary to. The goal isn't to
do a hands-off completely mechanical translation, but to convert libraries
(where the copyright/license of them allows) more or less mechanically, then
go in and adjust/fix/adapt as necessary.


 P.S. I don't like the idea. Java is everything I want to escape from with


D.


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


Let me put some of your concerns to rest <g>. D is not Java, it will never
be Java. Phobos isn't going to be replaced with a Java clone library. But D
does need a GUI, and doesn't have (yet) the resources to engineer a
top-notch one from scratch. Just like C++ bootstrapped off of existing C
libraries before going its own way, D needs to bootstrap off of something.
For reasons I laid out, the Java GUI libraries are the shortest path to get
D bootstrapped with a much needed crossplatform, modern GUI.



 May 29 2005



 next sibling parent reply bobef <bobef_member pathlink.com>  writes:


OK . Everything else sounds fine but this:


Good point - the underlying Java standard library is not going to be
converted. However, it turns out to be not necessary to. The goal isn't to
do a hands-off completely mechanical translation, but to convert libraries
(where the copyright/license of them allows) more or less mechanically, then
go in and adjust/fix/adapt as necessary.


I still can't understand. We are talking about gui-s. As long as I understand
Java has a basic gui and routines that supports it. Also drawing routines and
everything else needed. And every other java gui depends on that. Its like the
"asm" of java. You can't just go and write something your video card's memory,
can you? And you depend on sun for that matter. Well you will convert some
thirdparty code to D, but D misses gui and drawing. How you gonna replace these?
And you can't add such functionality because D, unlike Java, is platform
dependent.

Please tell me what I am missing here?



 May 29 2005



  parent  clayasaurus <clayasaurus gmail.com>  writes:


bobef wrote:

 OK . Everything else sounds fine but this:
 
 

Good point - the underlying Java standard library is not going to be
converted. However, it turns out to be not necessary to. The goal isn't to
do a hands-off completely mechanical translation, but to convert libraries
(where the copyright/license of them allows) more or less mechanically, then
go in and adjust/fix/adapt as necessary.


 
 
 I still can't understand. We are talking about gui-s. As long as I understand
 Java has a basic gui and routines that supports it. Also drawing routines and
 everything else needed. And every other java gui depends on that. Its like the
 "asm" of java. You can't just go and write something your video card's memory,
 can you? And you depend on sun for that matter. Well you will convert some
 thirdparty code to D, but D misses gui and drawing. How you gonna replace
these?


I assume Kris will write his own implementation.


 And you can't add such functionality because D, unlike Java, is platform
 dependent.


It is possible to write cross platform code by using the version 
statement, though initially I suspect only Windows and Linux will be 
supported.


 
 Please tell me what I am missing here?
 
 





 May 29 2005



prev sibling  parent reply Carlos Santander <csantander619 gmail.com>  writes:


Walter escribió:

 
 Let me put some of your concerns to rest <g>. D is not Java, it will never
 be Java. Phobos isn't going to be replaced with a Java clone library. But D
 does need a GUI, and doesn't have (yet) the resources to engineer a
 top-notch one from scratch. Just like C++ bootstrapped off of existing C
 libraries before going its own way, D needs to bootstrap off of something.
 For reasons I laid out, the Java GUI libraries are the shortest path to get
 D bootstrapped with a much needed crossplatform, modern GUI.
 
 


Will this D GUI be a part of Phobos or will it only be the "official" D 
GUI library? Will it be written by you (Walter), Kris, both, somebody 
else...? Will it be more like MinWin (very lightweight) or like DWT or 
wxD (very heavyweight)?

-- 
Carlos Santander Bernal



 May 29 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:d7dp8b$l7b$1 digitaldaemon.com...

 Walter escribió:

 Let me put some of your concerns to rest <g>. D is not Java, it will 
 never
 be Java. Phobos isn't going to be replaced with a Java clone library. But 
 D
 does need a GUI, and doesn't have (yet) the resources to engineer a
 top-notch one from scratch. Just like C++ bootstrapped off of existing C
 libraries before going its own way, D needs to bootstrap off of 
 something.
 For reasons I laid out, the Java GUI libraries are the shortest path to 
 get
 D bootstrapped with a much needed crossplatform, modern GUI.


 Will this D GUI be a part of Phobos or will it only be the "official" D 
 GUI library? Will it be written by you (Walter), Kris, both, somebody 
 else...? Will it be more like MinWin (very lightweight) or like DWT or wxD 
 (very heavyweight)?

 -- 


I would also ask: there are just three of them (in Java world):
AWT(Sun) ,SWING(Sun), SWT(IBM public license).
Latter one is almost done in D. First two are not free to port.

Walter, what Java GUI library you have in mind?

Andrew.



 May 29 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7ds35$nvf$1 digitaldaemon.com...

 Will this D GUI be a part of Phobos or will it only be the "official" D
 GUI library?




Part of phobos, no. I don't see a gui as a core library. As an addon
library, like dmdscript is, yes. Several D gui libraries are being worked
on. Eventually, I hope it will become obvious which one is the 'right' one,
and that one will become more or less official. Of course, nobody will be
prevented from using any other D gui library, and many will prefer using
other ones. The point of having a more or less official one is to avoid the
C++ problem of there being no standardized gui library. The point of not
putting it in Phobos is so that those who wish to use other GUIs can do so.
(I.e. Phobos should avoid being dependent on a particular GUI.)


 Will it be written by you (Walter),


No. GUIs are not a core competency of mine <g>.


 Kris, both, somebody

 else...? Will it be more like MinWin (very lightweight) or like DWT or




wxD

 (very heavyweight)?




It's whatever the programmers of it wish it to be. Whether and which one
becomes the "official" one or not really depends on how the people in this
group feel about it. Kris is working on one.



 I would also ask: there are just three of them (in Java world):
 AWT(Sun) ,SWING(Sun), SWT(IBM public license).
 Latter one is almost done in D. First two are not free to port.


If their licenses do not permit porting and free redistribution for any
purpose, then they are a total non-starter. I don't recommend that anyone
waste their time trying to convert such code. SWT, however, seems to have a
license that will work for us.



 Walter, what Java GUI library you have in mind?


I'm not competent to judge which one. I just want to open the door as wide
as possible for those who want to develop GUIs for D, and I hope a consensus
will emerge in this group as to which one to endorse. Kris has convinced me
that supporting inner classes will help a lot, not just for GUIs, but for a
lot of freely reusable Java code.



 May 30 2005



 next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 that supporting inner classes will help a lot, not just for GUIs, but for 
 a
 lot of freely reusable Java code.


Gentlemen, could you name library/libraries you want to port?
Or make sense to port? Just few examples would be enough.
Probably I cannot see something.

There are just no Java GUI libraries which you can port.

I even not sure about SWT port.
EPL (eclipse public license) shall be carefully studied first.
http://www.eclipse.org/legal/epl-v10.html by anyone
willing to use SWT/D port. I really don't know how to solve
all these legal collisions.

What is really make sense -  porting of various in-house
systems by their owners.  But in any case - Java has a foundation
of classes. Without these classes any Java code is almost unusable.
So you will always do some reengineering. I believe that
replacing inners with delegates will be *very* small part of the problem.

Andrew.


"Walter" <newshound digitalmars.com> wrote in message 
news:d7ekq0$1iq6$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7ds35$nvf$1 digitaldaemon.com...

 Will this D GUI be a part of Phobos or will it only be the "official" D
 GUI library?




 Part of phobos, no. I don't see a gui as a core library. As an addon
 library, like dmdscript is, yes. Several D gui libraries are being worked
 on. Eventually, I hope it will become obvious which one is the 'right' 
 one,
 and that one will become more or less official. Of course, nobody will be
 prevented from using any other D gui library, and many will prefer using
 other ones. The point of having a more or less official one is to avoid 
 the
 C++ problem of there being no standardized gui library. The point of not
 putting it in Phobos is so that those who wish to use other GUIs can do 
 so.
 (I.e. Phobos should avoid being dependent on a particular GUI.)


 Will it be written by you (Walter),


 No. GUIs are not a core competency of mine <g>.


 Kris, both, somebody

 else...? Will it be more like MinWin (very lightweight) or like DWT or




 wxD

 (very heavyweight)?




 It's whatever the programmers of it wish it to be. Whether and which one
 becomes the "official" one or not really depends on how the people in this
 group feel about it. Kris is working on one.



 I would also ask: there are just three of them (in Java world):
 AWT(Sun) ,SWING(Sun), SWT(IBM public license).
 Latter one is almost done in D. First two are not free to port.


 If their licenses do not permit porting and free redistribution for any
 purpose, then they are a total non-starter. I don't recommend that anyone
 waste their time trying to convert such code. SWT, however, seems to have 
 a
 license that will work for us.



 Walter, what Java GUI library you have in mind?


 I'm not competent to judge which one. I just want to open the door as wide
 as possible for those who want to develop GUIs for D, and I hope a 
 consensus
 will emerge in this group as to which one to endorse. Kris has convinced 
 me
 that supporting inner classes will help a lot, not just for GUIs, but for 
 a
 lot of freely reusable Java code.

 





 May 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7fmhv$2mp4$1 digitaldaemon.com...

 I even not sure about SWT port.
 EPL (eclipse public license) shall be carefully studied first.
 http://www.eclipse.org/legal/epl-v10.html by anyone
 willing to use SWT/D port. I really don't know how to solve
 all these legal collisions.


Here's the interesting part:

"a) Subject to the terms of this Agreement, each Contributor hereby grants
Recipient a non-exclusive, worldwide, royalty-free copyright license to
reproduce, prepare derivative works of, publicly display, publicly perform,
distribute and sublicense the Contribution of such Contributor, if any, and
such derivative works, in source code and object code form."

That seems pretty clear that translations are allowed, as translations are
derivative works. Nowhere in the license does it restrict anything to Java,
in fact, the word Java never appears.


 What is really make sense -  porting of various in-house
 systems by their owners.  But in any case - Java has a foundation
 of classes. Without these classes any Java code is almost unusable.
 So you will always do some reengineering. I believe that
 replacing inners with delegates will be *very* small part of the problem.


The use of the foundation classes will need to be rewritten, but the
capabilities of those foundation classes tend to have rough equivalents in
any programming language, so the rewrite is likely to be more a matter of
detail than reengineering.



 May 30 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7fr1h$2qol$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7fmhv$2mp4$1 digitaldaemon.com...

 I even not sure about SWT port.
 EPL (eclipse public license) shall be carefully studied first.
 http://www.eclipse.org/legal/epl-v10.html by anyone
 willing to use SWT/D port. I really don't know how to solve
 all these legal collisions.


 Here's the interesting part:

 "a) Subject to the terms of this Agreement, each Contributor hereby grants
 Recipient a non-exclusive, worldwide, royalty-free copyright license to
 reproduce, prepare derivative works of, publicly display, publicly 
 perform,
 distribute and sublicense the Contribution of such Contributor, if any, 
 and
 such derivative works, in source code and object code form."

 That seems pretty clear that translations are allowed, as translations are
 derivative works. Nowhere in the license does it restrict anything to 
 Java,
 in fact, the word Java never appears.


3. REQUIREMENTS
A Contributor may choose to distribute the Program in object code form under 
its own license agreement, provided that:
...
b) its license agreement:
.....
iv) states that source code for the Program is available from such 
Contributor, and informs licensees how to obtain it in a reasonable manner 
on or through a medium customarily used for software exchange.

This is typical GPL (I guess) requirement and I don't think it will be quite 
popular
among business software developers. How all this stuff will be sublicenses,
derived, etc?


 What is really make sense -  porting of various in-house
 systems by their owners.  But in any case - Java has a foundation
 of classes. Without these classes any Java code is almost unusable.
 So you will always do some reengineering. I believe that
 replacing inners with delegates will be *very* small part of the problem.


 The use of the foundation classes will need to be rewritten, but the
 capabilities of those foundation classes tend to have rough equivalents in
 any programming language, so the rewrite is likely to be more a matter of
 detail than reengineering.


Umm... I think "is likely to be more a matter of detail than reengineering."
is a bit optimistic. Main use case of Java is JSP and on second
place is mobile platforms and there are quite few serious projects
using Java GUI on desktop.

JSP framework.... It uses many tricks specific to archtecture of
bytecoded VM - hybernation, specific memory management and
pretty big one: REFLECTION.

Again, inners are just top of the iceberg. Very, very small one.
If only inners would stop Java-to-D transition - everybody
will be already here.

Andrew.



 May 30 2005



 next sibling parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7fscq$2sd9$1 digitaldaemon.com...

 That seems pretty clear that translations are allowed, as translations




are

 derivative works. Nowhere in the license does it restrict anything to
 Java,
 in fact, the word Java never appears.


 3. REQUIREMENTS
 A Contributor may choose to distribute the Program in object code form


under

 its own license agreement, provided that:
 ...
 b) its license agreement:
 .....
 iv) states that source code for the Program is available from such
 Contributor, and informs licensees how to obtain it in a reasonable manner
 on or through a medium customarily used for software exchange.

 This is typical GPL (I guess) requirement and I don't think it will be


quite

 popular
 among business software developers. How all this stuff will be


sublicenses,

 derived, etc?


The "Program" is defined as the initial Eclipse code plus any contributions
to Eclipse. I don't read it as including any other code, such as code that
would simply link to the SWT library, in particular: "Contributions do not
include additions to the Program which: (i) are separate modules of software
distributed in conjunction with the Program under their own license
agreement, and (ii) are not derivative works of the Program."

So, it is not viral like the GPL in that it does not infect anything linked
to it.



 Umm... I think "is likely to be more a matter of detail than


reengineering."

 is a bit optimistic. Main use case of Java is JSP and on second
 place is mobile platforms and there are quite few serious projects
 using Java GUI on desktop.

 JSP framework.... It uses many tricks specific to archtecture of
 bytecoded VM - hybernation, specific memory management and
 pretty big one: REFLECTION.

 Again, inners are just top of the iceberg. Very, very small one.
 If only inners would stop Java-to-D transition - everybody
 will be already here.


Kris says it stops the SWT GUI translation - he's in it up to his elbows. D
badly needs a full featured GUI. It's worth adding inner class support even
if it's only the SWT translation that benefits from it.

I agree that anything using reflection will need reengineering, although D
does support some basic reflection (.classinfo, typeid's, and template
partial specialization).

There isn't a whole lot of downside to implementing inner classes, if there
was I'd fight it. It'll have essentially no impact on programs that don't
care to use it.



 May 30 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7fupc$2ugj$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7fscq$2sd9$1 digitaldaemon.com...

 That seems pretty clear that translations are allowed, as translations




 are

 derivative works. Nowhere in the license does it restrict anything to
 Java,
 in fact, the word Java never appears.


 3. REQUIREMENTS
 A Contributor may choose to distribute the Program in object code form


 under

 its own license agreement, provided that:
 ...
 b) its license agreement:
 .....
 iv) states that source code for the Program is available from such
 Contributor, and informs licensees how to obtain it in a reasonable 
 manner
 on or through a medium customarily used for software exchange.

 This is typical GPL (I guess) requirement and I don't think it will be


 quite

 popular
 among business software developers. How all this stuff will be


 sublicenses,

 derived, etc?


 The "Program" is defined as the initial Eclipse code plus any 
 contributions
 to Eclipse. I don't read it as including any other code, such as code that
 would simply link to the SWT library, in particular: "Contributions do not
 include additions to the Program which: (i) are separate modules of 
 software
 distributed in conjunction with the Program under their own license
 agreement, and (ii) are not derivative works of the Program."

 So, it is not viral like the GPL in that it does not infect anything 
 linked
 to it.



 Umm... I think "is likely to be more a matter of detail than


 reengineering."

 is a bit optimistic. Main use case of Java is JSP and on second
 place is mobile platforms and there are quite few serious projects
 using Java GUI on desktop.

 JSP framework.... It uses many tricks specific to archtecture of
 bytecoded VM - hybernation, specific memory management and
 pretty big one: REFLECTION.

 Again, inners are just top of the iceberg. Very, very small one.
 If only inners would stop Java-to-D transition - everybody
 will be already here.


 Kris says it stops the SWT GUI translation - he's in it up to his elbows. 
 D
 badly needs a full featured GUI. It's worth adding inner class support 
 even
 if it's only the SWT translation that benefits from it.

 I agree that anything using reflection will need reengineering, although D
 does support some basic reflection (.classinfo, typeid's, and template
 partial specialization).

 There isn't a whole lot of downside to implementing inner classes, if 
 there
 was I'd fight it. It'll have essentially no impact on programs that don't
 care to use it.


I trust you Walter. If it would be possible to port some Java packages
then why not? They will be not D packages though, but who cares -
the main thing is to get job done.

Are you going to have string constants castable to String, BTW?
Or any other class? That would be nice...



 May 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7gnec$kc0$1 digitaldaemon.com...

 I trust you Walter. If it would be possible to port some Java packages
 then why not? They will be not D packages though, but who cares -
 the main thing is to get job done.


Think of it like C++ initially living off of C code. It was many years
before C++ did its own libraries and left C behind - but those early
bootstrapping years were very important.


 Are you going to have string constants castable to String, BTW?
 Or any other class? That would be nice...


What advantage does java.lang.String have? Why does string need to be a
class?



 May 30 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7go89$ll5$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gnec$kc0$1 digitaldaemon.com...

 I trust you Walter. If it would be possible to port some Java packages
 then why not? They will be not D packages though, but who cares -
 the main thing is to get job done.


 Think of it like C++ initially living off of C code. It was many years
 before C++ did its own libraries and left C behind - but those early
 bootstrapping years were very important.


Yep.  But D has already C interface. And you can mix D/C<-C++ code.
This just perfect and enough in most cases as all worth looking
libraries already has C API. Java ones as rule too specific - rely
on Java *platform* - running environment.


 Are you going to have string constants castable to String, BTW?
 Or any other class? That would be nice...


 What advantage does java.lang.String have? Why does string need to be a
 class?


Please see new posting : Java String vs wchar[] Was: Re: inner classes 



 May 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7gs4c$pd0$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d7go89$ll5$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gnec$kc0$1 digitaldaemon.com...

 I trust you Walter. If it would be possible to port some Java packages
 then why not? They will be not D packages though, but who cares -
 the main thing is to get job done.


 Think of it like C++ initially living off of C code. It was many years
 before C++ did its own libraries and left C behind - but those early
 bootstrapping years were very important.


 Yep.  But D has already C interface.


But it's not good enough these days, because people need a GUI and the
interesting GUIs are not written in C.



 May 31 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7h48j$12fi$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gs4c$pd0$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d7go89$ll5$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gnec$kc0$1 digitaldaemon.com...

 I trust you Walter. If it would be possible to port some Java packages
 then why not? They will be not D packages though, but who cares -
 the main thing is to get job done.


 Think of it like C++ initially living off of C code. It was many years
 before C++ did its own libraries and left C behind - but those early
 bootstrapping years were very important.


 Yep.  But D has already C interface.


 But it's not good enough these days, because people need a GUI and the
 interesting GUIs are not written in C.


Probably.

"Interesting" here means interesting for porting into D
or really interesting?

Andrew.



 May 31 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7h4ns$12um$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message

 But it's not good enough these days, because people need a GUI and the
 interesting GUIs are not written in C.


 Probably.

 "Interesting" here means interesting for porting into D
 or really interesting?


"Interesting" as in D programmers would want to use it to develop modern,
useful GUI apps.



 May 31 2005



 next sibling parent  Roberto Mariottini <Roberto_member pathlink.com>  writes:


In article <d7i7t3$299o$1 digitaldaemon.com>, Walter says...


[...]

"Interesting" as in D programmers would want to use it to develop modern,
useful GUI apps.


This is the definition of Swing :-)

Multi-platform, customizable look-and-feel, zillions of documentation,
tutorials, examples on the net, years of expertise for millions of Java
programmers (like me).
And, last but not least, easy to use.

Ciao



 May 31 2005



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7i7t3$299o$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7h4ns$12um$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message

 But it's not good enough these days, because people need a GUI and the
 interesting GUIs are not written in C.


 Probably.

 "Interesting" here means interesting for porting into D
 or really interesting?


 "Interesting" as in D programmers would want to use it to develop modern,
 useful GUI apps.


Have you seen modern, useful GUI apps in Java?
Yes there is only one which comes up in mind, Eclipse.

But compare its GUI with
http://www.gexperts.com/gel.html
http://www.jcreator.com/

I am not speaking about such features as refactoring, etc.
Just GUI. Speed, response time, etc.

Please don't forget that modern Java VM is
only 60%-70% slow than C++ code doing the same
task.

Java GUI solutions are theoretically clean but
practically just not working. That means bad theory
was selected. Don't think that SWT way
(use of native widgets instead of pure Java ones (Swing) )
was selected because native widgets were of better quality.
No. They were and are simply not moving.
Reason is simple: Java solutions rely on GC and fairy tale
that GC is fast.

Typical:
Rectangle getWindowRect() { return new Rectangle(1,2,3,4); }

Do you want this in D? Are you ready  to handle
memory defragmentation -> to implement copying GC
and finally to get what? Good JavaVM which is slightly
better than standard VM because it doesn't need JIT phase?
Doh!



 Jun 01 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7m22s$5dt$1 digitaldaemon.com...

 Typical:
 Rectangle getWindowRect() { return new Rectangle(1,2,3,4); }

 Do you want this in D? Are you ready  to handle
 memory defragmentation -> to implement copying GC
 and finally to get what?


But D has support for structs, which are lightweight aggregates and avoid
the mentioned 'typical' problems.



 Jun 02 2005



 next sibling parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7ngdh$1um7$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7m22s$5dt$1 digitaldaemon.com...

 Typical:
 Rectangle getWindowRect() { return new Rectangle(1,2,3,4); }

 Do you want this in D? Are you ready  to handle
 memory defragmentation -> to implement copying GC
 and finally to get what?


 But D has support for structs, which are lightweight aggregates and avoid
 the mentioned 'typical' problems.


Yes, but you are proposing to port library from language
which does not have them.

Good GUI (or any other library) for D without 'manual'
translation of code is just impossible.
Practically when I was porting mine I did cut n paste
from Java with code inspection with D in mind.
Code inspection process happens in lifecycle of any
project.
D is close enough to Java / C++ to make it happen
mor or less flawlessly. And I am not sure what
source language will be used as a source of porting:
C/C++ or Java more.
The most serious project I am getting these days is


Java, is a server side platform these days.
In big picture GUI in Java is exotic rather than practical.

Andrew.



 Jun 03 2005



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


In article <d7ngdh$1um7$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7m22s$5dt$1 digitaldaemon.com...

 Typical:
 Rectangle getWindowRect() { return new Rectangle(1,2,3,4); }

 Do you want this in D? Are you ready  to handle
 memory defragmentation -> to implement copying GC
 and finally to get what?


But D has support for structs, which are lightweight aggregates and avoid
the mentioned 'typical' problems.


But structs can't have ctors, which reduces their utility IMO.  The alternative
is using classes with alloca, but I don't see that as a particularly attractive
solution.  In some respects it might be nice to have a language mechanism to
allocate classes on the stack:

Class C {}
C c = local C(...);

But sadly, this still doesn't support copy semantics, which is a limiting aspect
of classes with alloca.  Personally, I find this issue to be the most difficult
adjustment in moving from C++.  There, explicit dynamic allocations are a design
choice and happen quite rarely, while in D they're both unavoidable and quite
common.

Sean



 Jun 03 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:d7qbg0$14qp$1 digitaldaemon.com...

 In article <d7ngdh$1um7$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7m22s$5dt$1 digitaldaemon.com...

 Typical:
 Rectangle getWindowRect() { return new Rectangle(1,2,3,4); }

 Do you want this in D? Are you ready  to handle
 memory defragmentation -> to implement copying GC
 and finally to get what?


But D has support for structs, which are lightweight aggregates and avoid
the mentioned 'typical' problems.


 But structs can't have ctors, which reduces their utility IMO.  The 
 alternative
 is using classes with alloca, but I don't see that as a particularly 
 attractive
 solution.  In some respects it might be nice to have a language mechanism 
 to
 allocate classes on the stack:

 Class C {}
 C c = local C(...);

 But sadly, this still doesn't support copy semantics, which is a limiting 
 aspect
 of classes with alloca.  Personally, I find this issue to be the most 
 difficult
 adjustment in moving from C++.  There, explicit dynamic allocations are a 
 design
 choice and happen quite rarely, while in D they're both unavoidable and 
 quite
 common.


Yep. This one second for me too (after const).


 Sean

 





 Jun 03 2005



prev sibling  parent reply "Kris" <fu bar.com>  writes:


I have to ask, Andrew ~ just what is your beef ?

I mean, you've made a number of entirely negative remarks within this
thread, and from another thread ~ for what? Is it that you just don't like
inner-classes? Is it because you somehow feel you should sanction what
others spend their time working on? Is it because you somehow feel
threatened? You've already clearly noted how you feel about Walter's
'priorities' in this regard ~ do you think you should dictate what he does
or doesn't do?

I'll try to clarify some things for you, such that you'll perhaps reconsider
spouting off yet more vague assertions:

1) The parties responsible have provided explicit written permission to port
their code. It is not GPL, as you claim. That aside, almost all current D
libraries & utilities make the source freely available; therefore your
'concerns' in this arena appear fickle. As do the vague and speculative
assertions you make, regarding perception from the commercial sector. The
term for such actions are widely known as FUD.

2) Shawn is not solely responsible for DWT, though he has put a lot of
effort into it ~ you really should have given equal credit to all the others
who worked just as hard.

3) A prototype converter has been operational for some time now, and it is
entirely feasible to port certain types of Java software with nary an issue;
results have been discussed indirectly on this NG during the past several
months. The doom and gloom you predict is inane, at best. Nobody (except
perhaps you?) is making claims one might whimsically port anything &
everything; that would be patently ridiculous.

4) Continued assertions about inner classes not solving world-hunger are
just silly ~ they just help porting in certain respects. In particular: they
are imperitive to preserving any documented API that applies them. That's
important to many.

5) The usage of inner-classes applies to more than trivial Listener designs.
Delegates are great, but they can and do run out of steam; making sweeping
judgements upon software architecture in general places you upon decidedly
shaky ground. At least you had the conscience to note your limited
experience with servers ~ there's more to software than UI APIs.

6) People have been doing Java conversions for quite some time. Ben and I
are two examples. I understand you feel the original author should somehow
be persuaded to port their code instead? Good luck!

7) You have asserted that Java "ruined everything". That's a fairly sweeping
statement to make, and appears rather naiive given the total lack of
substantiating evidence offered. Whatever.


Again ~ what exactly is your problem here? Regarding this thread? Why all
this banal assertion? I really would like to know ...

- Intrigued




"Andrew Fedoniouk" <news terrainformatica.com> ...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d7fr1h$2qol$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7fmhv$2mp4$1 digitaldaemon.com...

 I even not sure about SWT port.
 EPL (eclipse public license) shall be carefully studied first.
 http://www.eclipse.org/legal/epl-v10.html by anyone
 willing to use SWT/D port. I really don't know how to solve
 all these legal collisions.


 Here's the interesting part:

 "a) Subject to the terms of this Agreement, each Contributor hereby




grants

 Recipient a non-exclusive, worldwide, royalty-free copyright license to
 reproduce, prepare derivative works of, publicly display, publicly
 perform,
 distribute and sublicense the Contribution of such Contributor, if any,
 and
 such derivative works, in source code and object code form."

 That seems pretty clear that translations are allowed, as translations




are

 derivative works. Nowhere in the license does it restrict anything to
 Java,
 in fact, the word Java never appears.


 3. REQUIREMENTS
 A Contributor may choose to distribute the Program in object code form


under

 its own license agreement, provided that:
 ...
 b) its license agreement:
 .....
 iv) states that source code for the Program is available from such
 Contributor, and informs licensees how to obtain it in a reasonable manner
 on or through a medium customarily used for software exchange.

 This is typical GPL (I guess) requirement and I don't think it will be


quite

 popular
 among business software developers. How all this stuff will be


sublicenses,

 derived, etc?


 What is really make sense -  porting of various in-house
 systems by their owners.  But in any case - Java has a foundation
 of classes. Without these classes any Java code is almost unusable.
 So you will always do some reengineering. I believe that
 replacing inners with delegates will be *very* small part of the






problem.

 The use of the foundation classes will need to be rewritten, but the
 capabilities of those foundation classes tend to have rough equivalents




in

 any programming language, so the rewrite is likely to be more a matter




of

 detail than reengineering.


 Umm... I think "is likely to be more a matter of detail than


reengineering."

 is a bit optimistic. Main use case of Java is JSP and on second
 place is mobile platforms and there are quite few serious projects
 using Java GUI on desktop.

 JSP framework.... It uses many tricks specific to archtecture of
 bytecoded VM - hybernation, specific memory management and
 pretty big one: REFLECTION.

 Again, inners are just top of the iceberg. Very, very small one.
 If only inners would stop Java-to-D transition - everybody
 will be already here.

 Andrew.





 May 30 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


Kris, I relly don't want to be a tory here.
Not my intention, honestly.

I am also not in position to convince anybody to
do or not to do something. What I can do is only
to discuss. Sorry if my sounds are too m.m.m.m ...
emphatic lets say so.

My point is simple - time and resource management.
There are some outstanding issues which are not
in the language yet: and you can name them by yourself.

All OOP languages has const idiom. Even Java. D has not.
Compiler itself is solid but not enough. Adding new, pretty complex,
and most doubtful feature from Java at this point of time means
to postpone version 1.0 up to half of the year.

Motivation of adding inners is not clear as main players are
silent about what they are going to port.
Only in this message SWT poped up.
SWT - good framework but for tasks of creating
IDE alike projects.
It is used primarily in Eclipse. I don't know any other major project
using it.
http://www.clientjava.com/blog/2005/03/22/1111512421510.html
So I am assuming that this feature is only
for porting Eclipse and to create IDE.

IDE without debugger is nothing. It is second thing needs to be done.
If I could decide anything here I will start from doing debugger.
To create a simple IDE after is not a rocket science at all.
Just to start from somenthing. Just to be able to debug
SWT itself. We already have few IDEs in D.
Without debugger nobody will buy D. IMHO.

And moreover core of SWT is already here.


 2) Shawn is not solely responsible for DWT, though he has put a lot of
 effort into it ~ you really should have given equal credit to all the 
 others
 who worked just as hard.


I did, I do and will do. But I didn't get your point.
What is telling you that I am not "giving equal credit to...".
If it sounded this way - terribly sorry, guys.

Again, if inners will help D somehow:
popularity, marketing features, etc. then I am
voting by both hands. But as a realist I just cannot
see how this can be achieved - java-2-D blind translation of
*real* projects - not test pieces of code.

If implementation of inners will significantly popstpone final
D version....  nobody will be happy. And I am not sure
this delay... will it be equalized by inners or not. No idea.

I have experience working with 4 Java VMs and I can tell that
pure Java code porting from VM to VM is not a trivial task.
It took us half of the year to port from MS JVM to Sun
big and real GUI project. Just differences in core libraries.

Again, guys, SWT is good. For Java and Eclipse.
I'd be happy if D will have such IDE. But real one and not
just another editor.


 6) People have been doing Java conversions for quite some time. Ben and I
 are two examples. I understand you feel the original author should somehow
 be persuaded to port their code instead? Good luck!


I completely lost you here. What is this all about?
I am not doing any external ports, I am publishing my own stuff. Good it or 
bad?
It is enough for me to think that I did it as it should be implemented.in D.

Andrew.



"Kris" <fu bar.com> wrote in message news:d7g1dn$314a$1 digitaldaemon.com...

I have to ask, Andrew ~ just what is your beef ?

 I mean, you've made a number of entirely negative remarks within this
 thread, and from another thread ~ for what? Is it that you just don't like
 inner-classes? Is it because you somehow feel you should sanction what
 others spend their time working on? Is it because you somehow feel
 threatened? You've already clearly noted how you feel about Walter's
 'priorities' in this regard ~ do you think you should dictate what he does
 or doesn't do?

 I'll try to clarify some things for you, such that you'll perhaps 
 reconsider
 spouting off yet more vague assertions:

 1) The parties responsible have provided explicit written permission to 
 port
 their code. It is not GPL, as you claim. That aside, almost all current D
 libraries & utilities make the source freely available; therefore your
 'concerns' in this arena appear fickle. As do the vague and speculative
 assertions you make, regarding perception from the commercial sector. The
 term for such actions are widely known as FUD.

 2) Shawn is not solely responsible for DWT, though he has put a lot of
 effort into it ~ you really should have given equal credit to all the 
 others
 who worked just as hard.

 3) A prototype converter has been operational for some time now, and it is
 entirely feasible to port certain types of Java software with nary an 
 issue;
 results have been discussed indirectly on this NG during the past several
 months. The doom and gloom you predict is inane, at best. Nobody (except
 perhaps you?) is making claims one might whimsically port anything &
 everything; that would be patently ridiculous.

 4) Continued assertions about inner classes not solving world-hunger are
 just silly ~ they just help porting in certain respects. In particular: 
 they
 are imperitive to preserving any documented API that applies them. That's
 important to many.

 5) The usage of inner-classes applies to more than trivial Listener 
 designs.
 Delegates are great, but they can and do run out of steam; making sweeping
 judgements upon software architecture in general places you upon decidedly
 shaky ground. At least you had the conscience to note your limited
 experience with servers ~ there's more to software than UI APIs.

 6) People have been doing Java conversions for quite some time. Ben and I
 are two examples. I understand you feel the original author should somehow
 be persuaded to port their code instead? Good luck!

 7) You have asserted that Java "ruined everything". That's a fairly 
 sweeping
 statement to make, and appears rather naiive given the total lack of
 substantiating evidence offered. Whatever.


 Again ~ what exactly is your problem here? Regarding this thread? Why all
 this banal assertion? I really would like to know ...

 - Intrigued




 "Andrew Fedoniouk" <news terrainformatica.com> ...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d7fr1h$2qol$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7fmhv$2mp4$1 digitaldaemon.com...

 I even not sure about SWT port.
 EPL (eclipse public license) shall be carefully studied first.
 http://www.eclipse.org/legal/epl-v10.html by anyone
 willing to use SWT/D port. I really don't know how to solve
 all these legal collisions.


 Here's the interesting part:

 "a) Subject to the terms of this Agreement, each Contributor hereby




 grants

 Recipient a non-exclusive, worldwide, royalty-free copyright license to
 reproduce, prepare derivative works of, publicly display, publicly
 perform,
 distribute and sublicense the Contribution of such Contributor, if any,
 and
 such derivative works, in source code and object code form."

 That seems pretty clear that translations are allowed, as translations




 are

 derivative works. Nowhere in the license does it restrict anything to
 Java,
 in fact, the word Java never appears.


 3. REQUIREMENTS
 A Contributor may choose to distribute the Program in object code form


 under

 its own license agreement, provided that:
 ...
 b) its license agreement:
 .....
 iv) states that source code for the Program is available from such
 Contributor, and informs licensees how to obtain it in a reasonable 
 manner
 on or through a medium customarily used for software exchange.

 This is typical GPL (I guess) requirement and I don't think it will be


 quite

 popular
 among business software developers. How all this stuff will be


 sublicenses,

 derived, etc?


 What is really make sense -  porting of various in-house
 systems by their owners.  But in any case - Java has a foundation
 of classes. Without these classes any Java code is almost unusable.
 So you will always do some reengineering. I believe that
 replacing inners with delegates will be *very* small part of the






 problem.

 The use of the foundation classes will need to be rewritten, but the
 capabilities of those foundation classes tend to have rough equivalents




 in

 any programming language, so the rewrite is likely to be more a matter




 of

 detail than reengineering.


 Umm... I think "is likely to be more a matter of detail than


 reengineering."

 is a bit optimistic. Main use case of Java is JSP and on second
 place is mobile platforms and there are quite few serious projects
 using Java GUI on desktop.

 JSP framework.... It uses many tricks specific to archtecture of
 bytecoded VM - hybernation, specific memory management and
 pretty big one: REFLECTION.

 Again, inners are just top of the iceberg. Very, very small one.
 If only inners would stop Java-to-D transition - everybody
 will be already here.

 Andrew.


 





 May 30 2005



  parent  kris <fu bar.org>  writes:


Inline,Andrew:

Andrew Fedoniouk wrote:

 Kris, I relly don't want to be a tory here.
 Not my intention, honestly.


<G> Tory? Very funny :-D

Nor my intention.



 I am also not in position to convince anybody to
 do or not to do something. What I can do is only
 to discuss. Sorry if my sounds are too m.m.m.m ...
 emphatic lets say so.


I can be overtly emphatic about certain things too. But I'm afraid I 
wasn't seeing anything resembling a discussion point; just what appeared 
to be unsubstantiated FUD. But perhaps I have blinkers on today?



 My point is simple - time and resource management.
 There are some outstanding issues which are not
 in the language yet: and you can name them by yourself.


A point! A point! <g>

I must admit to sharing similar concerns in the past. However, as much 
as it can be frustrating to those supporting D, I think only Walter will 
decide when D is 'ready'. What can one do? Argue, leave, or do something 
about it? My choice is to try and improve the available libraries. 
There's plenty of work still required in that department, though I think 
it's great to see more and more people contributing (such as yourself ~ 
I think Harmonia is a very good idea).



 All OOP languages has const idiom. Even Java. D has not.
 Compiler itself is solid but not enough.


I, too, have an axe to grind over the "read-only" issue. Walter has 
actually posted a few replies on this topic, though it was long ago.


 Adding new, pretty complex,
 and most doubtful feature from Java at this point of time means
 to postpone version 1.0 up to half of the year.


FUD! <g>



 Motivation of adding inners is not clear as main players are
 silent about what they are going to port.
 Only in this message SWT poped up.


You must have skipped all the times Walter mentioned it in his posts.



 SWT - good framework but for tasks of creating
 IDE alike projects.
 It is used primarily in Eclipse. I don't know any other major project
 using it.
 http://www.clientjava.com/blog/2005/03/22/1111512421510.html
 So I am assuming that this feature is only
 for porting Eclipse and to create IDE.


I don't see a question mark in there; just assertion. So lets move on:



 IDE without debugger is nothing. It is second thing needs to be done.
 If I could decide anything here I will start from doing debugger.
 To create a simple IDE after is not a rocket science at all.
 Just to start from somenthing. Just to be able to debug
 SWT itself. We already have few IDEs in D.


A point which has had much attention in various guises. One can debug D 
using existing tools, but I don't think anyone would assert it could not 
be made better. If you could get a group of folks to build a debugger 
(perhaps into Elephant, or one of the other promising IDE's?), or do it 
yourself, that would be awesome! There once was a project on dsource 
within this realm ...



 Without debugger nobody will buy D. IMHO.


It's currently free ... ? Jocular sarcasm aside, solid debugging would 
probably benefit the perception of D.



 And moreover core of SWT is already here.


Perhaps it is.



2) Shawn is not solely responsible for DWT, though he has put a lot of
effort into it ~ you really should have given equal credit to all the 
others
who worked just as hard.


 
 
 I did, I do and will do. But I didn't get your point.
 What is telling you that I am not "giving equal credit to...".
 If it sounded this way - terribly sorry, guys.


For the record, this is what told me:
<quote>
"I think that AWT and SWING are not free for
porting in D. And for IBM's SWT Shawn Liu
already did an excellent job."
</quote>



 Again, if inners will help D somehow:
 popularity, marketing features, etc. then I am
 voting by both hands. But as a realist I just cannot
 see how this can be achieved - java-2-D blind translation of
 *real* projects - not test pieces of code.


I'll meet your assertion, and raise you several G. Might I suggest you 
re-read the prior posts?



 If implementation of inners will significantly popstpone final
 D version....  nobody will be happy. And I am not sure
 this delay... will it be equalized by inners or not. No idea.


Strawman. Or perhaps someone (Regan?) will qualify how to correctly 
define secondary propogation of one's own FUD?



 I have experience working with 4 Java VMs and I can tell that
 pure Java code porting from VM to VM is not a trivial task.
 It took us half of the year to port from MS JVM to Sun
 big and real GUI project. Just differences in core libraries.


Doom and gloom :-)

Perhaps a better initial isolation of the GUI from the functionality 
might have helped? I don't know. But, again, no one is suggesting doing 
any such thing (except you).



 Again, guys, SWT is good. For Java and Eclipse.


I see.



 I'd be happy if D will have such IDE. But real one and not
 just another editor.


So help build one? You seem to be a capable dude, and an IntelliJ for D 
would be truly awesome. Probably a money spinner too.


=============================================


So, you say your concern is with respect to Walter's time-management? 
Why didn't you just say so in the first place? :-)

Let's move on?



 May 30 2005



prev sibling  parent reply Roberto Mariottini <Roberto_member pathlink.com>  writes:


In article <d7ekq0$1iq6$1 digitaldaemon.com>, Walter says...

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7ds35$nvf$1 digitaldaemon.com...


[...]

 I would also ask: there are just three of them (in Java world):
 AWT(Sun) ,SWING(Sun), SWT(IBM public license).
 Latter one is almost done in D. First two are not free to port.


If their licenses do not permit porting and free redistribution for any
purpose, then they are a total non-starter. I don't recommend that anyone
waste their time trying to convert such code. SWT, however, seems to have a
license that will work for us.


Wait, there is a free version of Swing, that is part of GNU Classpath
(www.classpath.org). No Sun code used, completely rewritten from scratch, uses a
slightly modified GPL.

Please consider that 99% of Java developers use Swing. SWT is used only by
Eclipse and its plugins.

Ciao



 May 30 2005



  parent reply "Walter" <newshound digitalmars.com>  writes:


"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:d7h1bt$u4g$1 digitaldaemon.com...

 Wait, there is a free version of Swing, that is part of GNU Classpath
 (www.classpath.org). No Sun code used, completely rewritten from scratch,


uses a

 slightly modified GPL.

 Please consider that 99% of Java developers use Swing. SWT is used only by
 Eclipse and its plugins.


I don't know which is better, SWT or Swing. But D needs the best GUI we can
get, not necessarilly the most popular one <g>.



 May 31 2005



 next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter" <newshound digitalmars.com> wrote in message 
news:d7h48k$12fi$2 digitaldaemon.com...

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d7h1bt$u4g$1 digitaldaemon.com...

 Wait, there is a free version of Swing, that is part of GNU Classpath
 (www.classpath.org). No Sun code used, completely rewritten from scratch,


 uses a

 slightly modified GPL.

 Please consider that 99% of Java developers use Swing. SWT is used only 
 by
 Eclipse and its plugins.


 I don't know which is better, SWT or Swing. But D needs the best GUI we 
 can
 get, not necessarilly the most popular one <g>.


Walter, for D sake, do not look into Java for "the best GUI"....
There are too many of them out there and for many different purposes.
Java ones famous only by their weight :(

Start VS and start Eclipse and compare time.
And this not about bytecode - JavaVM these days
is loosing 30% from C++. It is about architecture and
memory management.



 May 31 2005



  parent reply kris <fu bar.org>  writes:


Andrew Fedoniouk wrote:

 
 Walter, for D sake, do not look into Java for "the best GUI"....
 There are too many of them out there and for many different purposes.
 Java ones famous only by their weight :(


According to whom? How can you "discuss" such things rationally with 
such a bigoted point of view? Should we suppose Harmonia would be the 
best GUI? Great! We'll have lots of wonderful choices!

As I see it, Walter is simply opening more doors for D; for rather 
limited cost. You, on the other hand, seem bent on maintaining the 
status-quo :-)



 Start VS and start Eclipse and compare time.
 And this not about bytecode - JavaVM these days
 is loosing 30% from C++. It is about architecture and
 memory management.


Now that is one misleading set of statements. You're apparently 
compounding wibbly assertion upon dodgy premise <g>

All that aside; would you like to find out whether the same might be 
true of D, or would you rather just sit and speculate idly/wildly?

C'mon Andrew. Why don't you help out instead?



 May 31 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"kris" <fu bar.org> wrote in message news:d7h9c6$184e$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 Walter, for D sake, do not look into Java for "the best GUI"....
 There are too many of them out there and for many different purposes.
 Java ones famous only by their weight :(


 According to whom? How can you "discuss" such things rationally with such 
 a bigoted point of view? Should we suppose Harmonia would be the best GUI? 
 Great! We'll have lots of wonderful choices!

 As I see it, Walter is simply opening more doors for D; for rather limited 
 cost. You, on the other hand, seem bent on maintaining the status-quo :-)



 Start VS and start Eclipse and compare time.
 And this not about bytecode - JavaVM these days
 is loosing 30% from C++. It is about architecture and
 memory management.


 Now that is one misleading set of statements. You're apparently 
 compounding wibbly assertion upon dodgy premise <g>

 All that aside; would you like to find out whether the same might be true 
 of D, or would you rather just sit and speculate idly/wildly?

 C'mon Andrew. Why don't you help out instead?


I am trying to help. I am trying to allude that it is good
to build walls first and only then "opening the doors" for
anybody.


 According to whom? How can you "discuss" such things rationally with such 
 a bigoted point of view? Should we suppose Harmonia would be the best GUI? 
 Great! We'll have lots of wonderful choices!


First: I've asked you and Walter many times here to
show real Java GUI application except of Eclipse.
SWT? Fine! But show please applications made on
this platform. Without, talks about porting
Java code and huge opportunities and doors in this area
are just one big puff.

Second: please, don't think that I am propaganding
Harmonia. I've told many times:
Harmonia is not for everyone and every GUI task.
It should be a set of DFL alike toolkits highly
optimized for particular platforms.
Just visit WTL news groups to get an idea what
is going on and how native GUI packages are popular.

Kris, please trust me, I am in GUI business all my life.
Java GUI dead now. Eclipse alone is just nothing if
you'll compare it with full rainbow:
http://www.atai.org/guitool/

And there is a huge crowd of people who are looking
for client side programming solutions now. The biggest
stream now is not coming from Java but suprisingly

'cause WinForms.NET failed and real Avalon GUI
will appear alive in 2011 or so.
http://tirania.org/blog/archive/2004/Sep-01.html



 Jun 03 2005



 next sibling parent reply "Kris" <fu bar.com>  writes:


Andrew, I really wish I could understand what it is you want me to do (or
not do). I would avoid replying, but I don't wish you to feel your
perspective is being ignored. So ...


"Andrew Fedoniouk" <news terrainformatica.com> wrote ...

 "kris" <fu bar.org> wrote in message


news:d7h9c6$184e$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 Walter, for D sake, do not look into Java for "the best GUI"....
 There are too many of them out there and for many different purposes.
 Java ones famous only by their weight :(


 According to whom? How can you "discuss" such things rationally with




such

 a bigoted point of view? Should we suppose Harmonia would be the best




GUI?

 Great! We'll have lots of wonderful choices!

 As I see it, Walter is simply opening more doors for D; for rather




limited

 cost. You, on the other hand, seem bent on maintaining the status-quo




:-)

 Start VS and start Eclipse and compare time.
 And this not about bytecode - JavaVM these days
 is loosing 30% from C++. It is about architecture and
 memory management.


 Now that is one misleading set of statements. You're apparently
 compounding wibbly assertion upon dodgy premise <g>

 All that aside; would you like to find out whether the same might be




true

 of D, or would you rather just sit and speculate idly/wildly?

 C'mon Andrew. Why don't you help out instead?


 I am trying to help. I am trying to allude that it is good
 to build walls first and only then "opening the doors" for
 anybody.


Walls? I thought you said it was Walter's time-management you had a beef
with? Now I'm really confused.



 According to whom? How can you "discuss" such things rationally with




such

 a bigoted point of view? Should we suppose Harmonia would be the best




GUI?

 Great! We'll have lots of wonderful choices!


 First: I've asked you and Walter many times here to
 show real Java GUI application except of Eclipse.
 SWT? Fine! But show please applications made on
 this platform. Without, talks about porting
 Java code and huge opportunities and doors in this area
 are just one big puff.


Why should anyone show any application at all? I really don't see where that
has any bearing whatsoever. What 'huge' opportunities?

I think you're blowing thing entirely out of proportion here. It's really
simple Andrew: a number of folks feel it's worthwhile porting some Java code
over to D. End of story. Nobody's asking you to do the work, although you're
very welcome to join in if you so desire.



 Second: please, don't think that I am propaganding
 Harmonia. I've told many times:
 Harmonia is not for everyone and every GUI task.
 It should be a set of DFL alike toolkits highly
 optimized for particular platforms.
 Just visit WTL news groups to get an idea what
 is going on and how native GUI packages are popular.


What I've been working on is not intended for everyone or everything,
either. But it does have native attributes.



 Kris, please trust me, I am in GUI business all my life.
 Java GUI dead now. Eclipse alone is just nothing if
 you'll compare it with full rainbow:
 http://www.atai.org/guitool/


Let me play all this back to you. You're saying: "Kris, I'm an expert in
this field; don't waste your time and that of others; drop any ideas you
have regarding a port of Java code to D. It's just not worth it. Trust me; I
know what I'm taking about."

You may well be some kind of expert, Andrew. But you've yet to come up with
even one solid reason why I, or anyone else, should buy in. Sure; you've
said lots of things along the lines of "Java GUI dead now" or "SWT is failed
design", but that is hardly concrete or convincing, and nor is it
particularly relevant.

I'll be happy and willing to listen to you, if you can bring something more
to the table than what appears to be wholly unfounded speculative assertion.
It's not even clear what it is you wish me to do ... so you'll have to start
there.



 And there is a huge crowd of people who are looking
 for client side programming solutions now. The biggest
 stream now is not coming from Java but suprisingly

 'cause WinForms.NET failed and real Avalon GUI
 will appear alive in 2011 or so.
 http://tirania.org/blog/archive/2004/Sep-01.html



good GUI? For Windows? Cross-platform? OK.



 Jun 03 2005



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Kris" <fu bar.com> wrote in message news:d7qsq3$1kl7$1 digitaldaemon.com...

 Andrew, I really wish I could understand what it is you want me to do (or
 not do). I would avoid replying, but I don't wish you to feel your
 perspective is being ignored. So ...


 "Andrew Fedoniouk" <news terrainformatica.com> wrote ...

 "kris" <fu bar.org> wrote in message


 news:d7h9c6$184e$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 Walter, for D sake, do not look into Java for "the best GUI"....
 There are too many of them out there and for many different purposes.
 Java ones famous only by their weight :(


 According to whom? How can you "discuss" such things rationally with




 such

 a bigoted point of view? Should we suppose Harmonia would be the best




 GUI?

 Great! We'll have lots of wonderful choices!

 As I see it, Walter is simply opening more doors for D; for rather




 limited

 cost. You, on the other hand, seem bent on maintaining the status-quo




 :-)

 Start VS and start Eclipse and compare time.
 And this not about bytecode - JavaVM these days
 is loosing 30% from C++. It is about architecture and
 memory management.


 Now that is one misleading set of statements. You're apparently
 compounding wibbly assertion upon dodgy premise <g>

 All that aside; would you like to find out whether the same might be




 true

 of D, or would you rather just sit and speculate idly/wildly?

 C'mon Andrew. Why don't you help out instead?


 I am trying to help. I am trying to allude that it is good
 to build walls first and only then "opening the doors" for
 anybody.


 Walls? I thought you said it was Walter's time-management you had a beef
 with? Now I'm really confused.


Seems indeed I want too much and went too far.
It is personal, terribly sorry.
I am forced to stop working on Harmonia today.
Three new projects requiring my full dedication.
And I cannot use D there. There were chances
but ... various reasons to be short.


 According to whom? How can you "discuss" such things rationally with




 such

 a bigoted point of view? Should we suppose Harmonia would be the best




 GUI?

 Great! We'll have lots of wonderful choices!


 First: I've asked you and Walter many times here to
 show real Java GUI application except of Eclipse.
 SWT? Fine! But show please applications made on
 this platform. Without, talks about porting
 Java code and huge opportunities and doors in this area
 are just one big puff.


 Why should anyone show any application at all? I really don't see where 
 that
 has any bearing whatsoever. What 'huge' opportunities?

 I think you're blowing thing entirely out of proportion here. It's really
 simple Andrew: a number of folks feel it's worthwhile porting some Java 
 code
 over to D. End of story. Nobody's asking you to do the work, although 
 you're
 very welcome to join in if you so desire.


Ok. Consider me and others as a C++ guys.
We are asking for const implementation. What
will benefit D more?
Answer from heavens is one: there will be inners
instead (but not finals). And nobody willing
to explain why? Just common words: there are
somewhere some Java projects which will be
translated automatically from Java...
I know Java. I did my own VM. I am not
buying this automatic translation.
Java is a platform. Code without platform -
system of classes from lang.java etc. -
is nothing.
Moreover I've provided concrete link which will help
to try this translation without need of inners.
So anyone who have project to port can use
this tool now. Just to test is it possible at all.



 Second: please, don't think that I am propaganding
 Harmonia. I've told many times:
 Harmonia is not for everyone and every GUI task.
 It should be a set of DFL alike toolkits highly
 optimized for particular platforms.
 Just visit WTL news groups to get an idea what
 is going on and how native GUI packages are popular.


 What I've been working on is not intended for everyone or everything,
 either. But it does have native attributes.



 Kris, please trust me, I am in GUI business all my life.
 Java GUI dead now. Eclipse alone is just nothing if
 you'll compare it with full rainbow:
 http://www.atai.org/guitool/


 Let me play all this back to you. You're saying: "Kris, I'm an expert in
 this field; don't waste your time and that of others; drop any ideas you
 have regarding a port of Java code to D. It's just not worth it. Trust me; 
 I
 know what I'm taking about."

 You may well be some kind of expert, Andrew. But you've yet to come up 
 with
 even one solid reason why I, or anyone else, should buy in. Sure; you've
 said lots of things along the lines of "Java GUI dead now" or "SWT is 
 failed
 design", but that is hardly concrete or convincing, and nor is it
 particularly relevant.


In GUI business absense of successfull applications during
5 years of development means two things:
either this technology was designed to accomplish one
particular task (SWT/Eclipse) either it is failed.
I don't know what to say more concret here.


 I'll be happy and willing to listen to you, if you can bring something 
 more
 to the table than what appears to be wholly unfounded speculative 
 assertion.
 It's not even clear what it is you wish me to do ... so you'll have to 
 start
 there.


Ok.


 And there is a huge crowd of people who are looking
 for client side programming solutions now. The biggest
 stream now is not coming from Java but suprisingly

 'cause WinForms.NET failed and real Avalon GUI
 will appear alive in 2011 or so.
 http://tirania.org/blog/archive/2004/Sep-01.html



 a
 good GUI? For Windows? Cross-platform? OK.


Yep.



 Jun 03 2005



 next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


 Seems indeed I want too much and went too far.
 It is personal, terribly sorry.
 I am forced to stop working on Harmonia today.
 Three new projects requiring my full dedication.
 And I cannot use D there. There were chances
 but ... various reasons to be short.


I hope it's temporary. Harmonia is very impressive. 



 Jun 03 2005



  parent reply Trevor Parscal <trevorparscal hotmail.com>  writes:


Andrew...
*snip* I am forced to stop working on Harmonia today.

We all have our own ideas for D man, but patience is allot more useful 
than giving up. But, if you have other projects that need attention, I 
do wish you good luck with them.

Between this and TZ, I am starting to think that this is the Drama 
programming language... :) (c'mon, that's funny!)

I LOVE D!

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com



 Jun 03 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Trevor Parscal" <trevorparscal hotmail.com> wrote in message 
news:d7r6se$1r76$1 digitaldaemon.com...

 Andrew...
 *snip* I am forced to stop working on Harmonia today.

 We all have our own ideas for D man, but patience is allot more useful 
 than giving up. But, if you have other projects that need attention, I do 
 wish you good luck with them.

 Between this and TZ, I am starting to think that this is the Drama 
 programming language... :) (c'mon, that's funny!)


:) Not a drama. No tragic at all.
Just real life, real projects, real situation.

Agreed, D is a nice language.
Overall concept is good.
Just couple of  design holes still open (exactly two in fact).
I wish they will be resolved. Hope D will not
loose moment of time. Wish also that
language design process will be a bit
predictable and open.
---------------------------------
For those who are interested: Pretty
soon Harmonia will be available in C++.
We are doing interesting projects
now so life is not ending. One of it might
follow to appear of OS of new generation
built on principles too far from existing ones.
Extremely interesting and *very real*
project, investors are eager and so on.
and D there was no.1 candidate....

Anyway...

For those who decided to use Harmonia/D
further: let me know - some help will be available -
at least I'll try to answer on questions.


 I LOVE D!


Yep. Hope this love will be mutual ;)
otherwise it is a perversion.

PS: I'll double this message on
russian software developers network.
Many people were very exited there after my
postings. So I have to explain my position.
Meaning will be the same.



 Jun 04 2005



prev sibling  parent  "Kris" <fu bar.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote

 Ok. Consider me and others as a C++ guys.
 We are asking for const implementation. What
 will benefit D more?


Regarding a const implementation: I'm afraid you're just gonna' have to get
over that, Andrew. I've been asking for a readonly modifier for about a year
now, and there were probably others before me. This is not some kind of new
request, by any stretch of the imagination. It'll happen when it happens.



 Answer from heavens is one: there will be inners
 instead (but not finals). And nobody willing
 to explain why? Just common words: there are
 somewhere some Java projects which will be
 translated automatically from Java...
 I know Java. I did my own VM. I am not
 buying this automatic translation.
 Java is a platform. Code without platform -
 system of classes from lang.java etc. -
 is nothing.


I see.

So place a wager, then.

If you're so adament that it's simply not possible to port a major Java
library to D without some serious hand-waving and serious manual
intervention, then put some clout behind those claims of yours. Let's just
see how much value all this expertise and knowledge of yours is really worth
:-)



 Jun 03 2005



prev sibling  parent reply Carlos Santander <csantander619 gmail.com>  writes:


Andrew Fedoniouk escribió:

 
 First: I've asked you and Walter many times here to
 show real Java GUI application except of Eclipse.
 SWT? Fine! But show please applications made on
 this platform. Without, talks about porting
 Java code and huge opportunities and doors in this area
 are just one big puff.
 


I don't know if SWT is that bad. I don't know much about GUI libraries 
besides a handful of them. The same could be said for libraries in 
general. I understand (it's not hard to do ;)) that there're good and 
bad libraries everywhere, but I'm all for options.

Nobody can know before hand if porting some library (good or bad) to D 
will produce the same library as before: maybe it'll get better, or it 
could get worse, but it can only be known after it's been done and 
tested. So, Andrew, while I respect your opinion as much as I respect 
everyone else's, I think it's good that more libraries are ported to D. 
They can come from anywhere, they can be old or new, they can be 
anything related, but we, the D programmers, need those libraries, and 
only using them we'll know if we stick to them or not.

One example: I still think DFL is the best D GUI library right now, but 
I don't use it because it's Windows only. I follow it, but that's it. 
Portability is very high in my book, so I have to look somewhere else. 
But that's me, somebody else will think different, and that's where 
options come handy.

I think the worst mistake we as human beings can make is to think that 
we have to make everybody think like we do, think that there's only one 
absolute truth. "Only Sith(s?) think in absolutes" ;)

-- 
Carlos Santander Bernal



 Jun 03 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:d7qv92$1m4l$1 digitaldaemon.com...

 Andrew Fedoniouk escribió:

 First: I've asked you and Walter many times here to
 show real Java GUI application except of Eclipse.
 SWT? Fine! But show please applications made on
 this platform. Without, talks about porting
 Java code and huge opportunities and doors in this area
 are just one big puff.


 I don't know if SWT is that bad. I don't know much about GUI libraries 
 besides a handful of them. The same could be said for libraries in 
 general. I understand (it's not hard to do ;)) that there're good and bad 
 libraries everywhere, but I'm all for options.

 Nobody can know before hand if porting some library (good or bad) to D 
 will produce the same library as before: maybe it'll get better, or it 
 could get worse, but it can only be known after it's been done and tested. 
 So, Andrew, while I respect your opinion as much as I respect everyone 
 else's, I think it's good that more libraries are ported to D. They can 
 come from anywhere, they can be old or new, they can be anything related, 
 but we, the D programmers, need those libraries, and only using them we'll 
 know if we stick to them or not.

 One example: I still think DFL is the best D GUI library right now, but I 
 don't use it because it's Windows only. I follow it, but that's it. 
 Portability is very high in my book, so I have to look somewhere else. But 
 that's me, somebody else will think different, and that's where options 
 come handy.

 I think the worst mistake we as human beings can make is to think that we 
 have to make everybody think like we do, think that there's only one 
 absolute truth. "Only Sith(s?) think in absolutes" ;)


Absolutely true.


 -- 
 Carlos Santander Bernal 





 Jun 03 2005



prev sibling  parent reply John Reimer <brk_6502 yahoo.com>  writes:


Walter wrote:

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d7h1bt$u4g$1 digitaldaemon.com...
 

Wait, there is a free version of Swing, that is part of GNU Classpath
(www.classpath.org). No Sun code used, completely rewritten from scratch,


 
 uses a
 

slightly modified GPL.

Please consider that 99% of Java developers use Swing. SWT is used only by
Eclipse and its plugins.


 
 
 I don't know which is better, SWT or Swing. But D needs the best GUI we can
 get, not necessarilly the most popular one <g>.
 
 


Swing vs SWT...

Now where is that interesting piece of propoganda Kris had us reading at 
dsource? ;)

Oh... here it is:

http://www.mail-archive.com/jug-discussion tucson-jug.org/msg00355.html

Really, it was a good read.  I don't know how true it is, but it 
definitely gives credence to the fact that things aren't always what 
they appear.

-JJR



 May 31 2005



  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:d7h8rn$17k4$1 digitaldaemon.com...

 Walter wrote:

 "Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
 news:d7h1bt$u4g$1 digitaldaemon.com...


Wait, there is a free version of Swing, that is part of GNU Classpath
(www.classpath.org). No Sun code used, completely rewritten from scratch,


 uses a


slightly modified GPL.

Please consider that 99% of Java developers use Swing. SWT is used only 
by
Eclipse and its plugins.



 I don't know which is better, SWT or Swing. But D needs the best GUI we 
 can
 get, not necessarilly the most popular one <g>.


 Swing vs SWT...

 Now where is that interesting piece of propoganda Kris had us reading at 
 dsource? ;)

 Oh... here it is:

 http://www.mail-archive.com/jug-discussion tucson-jug.org/msg00355.html

 Really, it was a good read.  I don't know how true it is, but it 
 definitely gives credence to the fact that things aren't always what they 
 appear.


Good one! Thanks John! It is close to what I knew. Some new nice facts :)
The problem was that goal to beat VS IDE was not reached.
VisualJ was simply better. It is native. And only now when
we can see VS (Whitbey) made in .NET they (VS and Eclipse) are pretty close 
:)

Andrew.



 Jun 01 2005



prev sibling next sibling parent  "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


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



 May 29 2005



prev sibling next sibling parent  =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com>  writes:


On Sat, 28 May 2005 14:50:14 -0700, 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).


For some cool C GUI libs look at 
http://www.enlightenment.org/



 May 29 2005



prev sibling next sibling parent  Stewart Gordon <smjg_1998 yahoo.com>  writes:


Walter wrote:
<snip>

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


You did tell us in the overview that D isn't for legacy apps.  I suppose 
it isn't really for legacy libs either.  Leave GUI support in D to those 
of us who are writing native D GUI libs....

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


So people can write their GUIs in a D port of Java AWT?


 No analogous "inner struct" support is planned.


Better watch the confusion - I've seen some use "inner struct" to mean 
"anonymous struct".

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.



 May 31 2005



prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


Just thinking about it, I'm not sure that inner classes really add 
anything to the power of a language.

The essence of an inner class is that it implicitly contains a pointer 
to an object of the outer class.  But you could just as well define a 
static nested class that explicitly contains such a pointer.

So really, it seems that inner classes are just syntactic sugar.  Or am 
I missing something?  Is the feature really worth the weight of 
implementation?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.



 Jun 02 2005



 next sibling parent  "Walter" <newshound digitalmars.com>  writes:


"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d7mlba$lgk$1 digitaldaemon.com...

 So really, it seems that inner classes are just syntactic sugar.  Or am
 I missing something?  Is the feature really worth the weight of
 implementation?


You're right, inner classes are nothing more than syntactic sugar. If it'll
open the door to getting a lot of needed existing code translated into D,
then it's worth it.



 Jun 02 2005



prev sibling  parent  Matthias Becker <Matthias_member pathlink.com>  writes:


Just thinking about it, I'm not sure that inner classes really add 
anything to the power of a language.

The essence of an inner class is that it implicitly contains a pointer 
to an object of the outer class.  But you could just as well define a 
static nested class that explicitly contains such a pointer.

So really, it seems that inner classes are just syntactic sugar.  Or am 
I missing something?  Is the feature really worth the weight of 
implementation?


It is syntactic suggar, but syntactic suggar is important for a language.



 Jun 03 2005



prev sibling next sibling parent reply xs0 <xs0 xs0.com>  writes:


Walter wrote:


 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.


Great! I also tried to write a Java -> D converter, and it was a real 
pain to rewrite all Java inners to normal classes.

Will you also support anonymous inner classes, or just named ones? The 
anonymous type is perhaps even more important, as far as porting Java 
code is concerned..

If I can help in some way, let me know; I'd love to see this done ASAP.


xs0



 Jun 02 2005



  parent  "Walter" <newshound digitalmars.com>  writes:


"xs0" <xs0 xs0.com> wrote in message news:d7mqah$qtr$1 digitaldaemon.com...

 Will you also support anonymous inner classes, or just named ones? The
 anonymous type is perhaps even more important, as far as porting Java
 code is concerned..


I agree that the anonymous inner classes need to be done if doing inner
classes at all.


 If I can help in some way, let me know; I'd love to see this done ASAP.


Improving your Java->D converter will pay big dividends. I know Kris is
working on one, too. Perhaps you two can help each other?



 Jun 02 2005



prev sibling  parent  Vathix <vathix dprogramming.com>  writes:


 So, the result is that Kris has convinced me to support inner classes in  
 D.


Will a class defined in a function be inner to that function and have  
access to its variables, kind of like a delegate?


void foo()
{
    int foovar;

    class InnerFoo
    {
       void stuff()
       {
          foovar = 4; // Allowed?
       }
    }
}



 Jun 02 2005