View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2005
Re: inner classes
"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 30, 2005
Re: inner classes
In article <d7cmad$2nje$1@digitaldaemon.com>, Shawn Liu says...
>
>Yes. This is the approach I currently used while porting SWT to DWT, but 
>partially. The original APIs are kept for compatibility.
>
If this port is going well then why would D need inner classes for a GUI?

We certainly don't need a slow Swing GUI ported to D.
May 30, 2005
Re: inner classes
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 30, 2005
Re: inner classes
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 30, 2005
Re: inner classes
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 30, 2005
Re: inner classes
"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 30, 2005
Re: inner classes
"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 30, 2005
Re: inner classes
"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message
news:d7ds35$nvf$1@digitaldaemon.com...
> > Will this D GUI be a part of Phobos or will it only be the "official" D
> > GUI library?

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

> Will it be written by you (Walter),

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

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

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


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

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


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

I'm not competent to judge which one. I just want to open the door as wide
as possible for those who want to develop GUIs for D, and I hope a consensus
will emerge in this group as to which one to endorse. Kris has convinced me
that supporting inner classes will help a lot, not just for GUIs, but for a
lot of freely reusable Java code.
May 30, 2005
Re: inner classes
"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
Re: inner classes
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home