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


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



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>


 In article <d7avqg$1gv1$1 digitaldaemon.com>, David L. Davis says...



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



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



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.

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

In article <d7aqja$1dos$1 digitaldaemon.com>, Walter says...
This is based on discussions of mine with Kris where we were looking for a
solution:

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

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

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

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

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

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

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

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

No analogous "inner struct" support is planned.

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

 What I know for sure is that it is slow (maybe after few years it wont be

 in it will ruler the world :). But I guess this will not reflect to D

 will not execute Java code like in the C case but instead convert it to D

 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

 Java std lib or whatever it is called. And it is a huge one. It covers

 network, sound and everything else (let someone who deals with java

 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

 C/C++ is too old and needs replacement. I believe java/c# is not that
 replacement. I prefer to write C wrapers... But it requires a lot of

 and this is a big issue. Still, I believe a better solution is required.

 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

 use a buildning, no longer can upgrade it and need a better one, you raze

 ground and buid it once again. And D shouldn't be the next upgrade for

 building (even less to java). Well if you want to make money with it you

 the java way. But I think you can't just make people use D. When they come

 the idea D is worthy language they will write D native (I mean in D not

 the old ones) gui and whatever libraries. If someone use D to for his

 old library be it java,c++ or whatever he better stays with it. This is

 issue microsoft have with their win32 lib, because it is C... But all they

 is money and they can't stop support it. Otherwise they would throw it all

 and go with something totally new. This is what D needs to do in my

 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


 (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


 (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


 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

 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

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

 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

 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


 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

 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

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

 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

 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 to port some GUI project from C# :)) 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


 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


 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

 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

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

 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



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


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


 detail than reengineering.

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

 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


 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


 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

 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

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

 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



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


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


 detail than reengineering.

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

 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.

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,

 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,

 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 from C# and C++. '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

 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


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


 Great! We'll have lots of wonderful choices!

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


 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


 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


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


 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
 from C# and C++.
 'cause WinForms.NET failed and real Avalon GUI
 will appear alive in 2011 or so.
 http://tirania.org/blog/archive/2004/Sep-01.html

So ~ there's a bunch of C# and C++ developers looking for a language with a 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

 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


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


 Great! We'll have lots of wonderful choices!

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


 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


 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


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


 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
 from C# and C++.
 'cause WinForms.NET failed and real Avalon GUI
 will appear alive in 2011 or so.
 http://tirania.org/blog/archive/2004/Sep-01.html

So ~ there's a bunch of C# and C++ developers looking for a language with 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 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
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