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

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.

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.

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

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

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

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

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7ds35$nvf$1@digitaldaemon.com...
> > Will this D GUI be a part of Phobos or will it only be the "official" D GUI library?

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

> Will it be written by you (Walter),

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

> Kris, both, somebody
> > else...? Will it be more like MinWin (very lightweight) or like DWT or
wxD
> > (very heavyweight)?

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


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

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


> Walter, what Java GUI library you have in mind?

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

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

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