I have recently begun to experiment more with Anonymous Inner classes
(I still consider them a devils deal). However, I did come upon a
situation where it was nice:

JPanel myPanel = new JPanel() {
   public String toString() { return "Default";}
};

I used this so I could added panels to my JComboBox and swap them on
and off of another portion of the display. However, my hopes were
dashed when I wanted that Anonymous Inner Class to implement and
interface.

JPanel myPanel = new JPanel() implements QueryFormatter {
   public String toString() { return "Default";}
   public String getFormat() {return "";} // interface method.
};

I got an unexpected token compile error. So, is it possible to do this
with anonymous inner classes? I am thinking not, judging by the
compiler errors and the fact that the lanaguage specification is silent
on this.

Comments?

Christian
http://christian.bongiorno.org/resume.PDF

In message <1109787295.577274.178570@l41g2000cwc.googlegroups.com>,
cbongior@stny.rr.com wrote on 2 Mar 2005 11:01:13 -0800:

[...]
> JPanel myPanel = new JPanel() implements QueryFormatter {
>    public String toString() { return "Default";}
>    public String getFormat() {return "";} // interface method.
> };
> 
> I got an unexpected token compile error. So, is it possible to do this
> with anonymous inner classes? 

  Not this way. Think about it: JPanel already declares which classes it
extends and which interfaces it implements. You can't change that for
JPanel itself. If you want to add to that, you'll need to subclass it
instead. So you could create an abstract class MyJPanel that extends
JPanel and implements QueryFormatter and then do

MyJPanel myPanel = new MyJPanel() { ... }

to get what you desire. No idea if that would be useful though.

-- 
Cheers, Tilman

`Boy, life takes a long time to live...'      -- Steven Wright

cbongior@stny.rr.com wrote:
> I have recently begun to experiment more with Anonymous Inner classes
> (I still consider them a devils deal). However, I did come upon a
> situation where it was nice:
[...]
> 
> I used this so I could added panels to my JComboBox and swap them on
> and off of another portion of the display. However, my hopes were
> dashed when I wanted that Anonymous Inner Class to implement and
> interface.
> 
> JPanel myPanel = new JPanel() implements QueryFormatter {
>   public String toString() { return "Default";}
>   public String getFormat() {return "";} // interface method.
> };

The way I understand it (which is not nescessarily The Truth (tm)), is
that anonymnous inner classes are used as parameters to methods and/or
constructors. These parameters have one type only (either a class or
method name). I'm assuming clean OO here, so there is no use of the
instanceof operator to determine additional functionality.

The object you create is created as a JPanel; not a QueryFormatter (that
is the type of the variable). Even though the object may be used as such.
Assuming that you do not use a programmer-informed cast nor the instanceof
operator, it doesn't need to be a QueryFormatter. It may be more useful in
it's current form of couse, but in that case the concept of what the
object is for is big enough that the object's class merits its own name.


-- 
Oscar Kind                                    http://home.hccnet.nl/okind/
Software Developer                    for contact information, see website

PGP Key fingerprint:    91F3 6C72 F465 5E98 C246  61D9 2C32 8E24 097B B4E2

In article <1109787295.577274.178570@l41g2000cwc.googlegroups.com>,
 cbongior@stny.rr.com wrote:

> I have recently begun to experiment more with Anonymous Inner classes
> (I still consider them a devils deal). However, I did come upon a
> situation where it was nice:
> 
> JPanel myPanel = new JPanel() {
>    public String toString() { return "Default";}
> };
> 
> I used this so I could added panels to my JComboBox and swap them on
> and off of another portion of the display. However, my hopes were
> dashed when I wanted that Anonymous Inner Class to implement and
> interface.
> 
> JPanel myPanel = new JPanel() implements QueryFormatter {
>    public String toString() { return "Default";}
>    public String getFormat() {return "";} // interface method.
> };
> 
> I got an unexpected token compile error. So, is it possible to do this
> with anonymous inner classes? I am thinking not, judging by the
> compiler errors and the fact that the lanaguage specification is silent
> on this.
> 
> Comments?
> 
> Christian
> http://christian.bongiorno.org/resume.PDF

Why implement that interface?  You're casting the result to a JPanel.

It is possible to implement interfaces.  I do it to avoid having a 
public run() method for thread entry.

Runnable r= new Runnable ()
{
   public void run () {myProtectedMethod();}
};
new Thread (r).start();

cbongior@stny.rr.com wrote:

> JPanel myPanel = new JPanel() implements QueryFormatter {

If you are using /anonymous/ inner classes, then you are restricted in what you
can do.  You can't specify both a superclass and a list of interfaces as you
can with a normal, named, class (even an inner class).  You can only specify
/either/ the superclass of your inner class, /or/ one interface that it will
implement.

For that reason (and the to avoid the horrible syntax) I generally prefer to
give my inner classes names.

    -- chris

Oscar kind wrote:

> cbongior@stny.rr.com wrote:
> 
>>I have recently begun to experiment more with Anonymous Inner classes
>>(I still consider them a devils deal). However, I did come upon a
>>situation where it was nice:
> 
> [...]
> 
>>I used this so I could added panels to my JComboBox and swap them on
>>and off of another portion of the display. However, my hopes were
>>dashed when I wanted that Anonymous Inner Class to implement and
>>interface.
>>
>>JPanel myPanel = new JPanel() implements QueryFormatter {
>>  public String toString() { return "Default";}
>>  public String getFormat() {return "";} // interface method.
>>};
> 
> 
> The way I understand it (which is not nescessarily The Truth (tm)), is
> that anonymnous inner classes are used as parameters to methods and/or
> constructors.

Being nitpicky, it is instances that are used for these purposes, not 
the classes themselves.  These are indeed some of the common cases, but 
inner class instances are no more restricted in how they can be used 
than are any other objects.  For example, you might choose to create a 
special Comparator by use of an anonymous inner class.  If you 
anticipate wanting to use it multiple times, then you might choose to 
store its reference in an instance variable of one of its containing 
classes.

>                 These parameters have one type only (either a class or
> method name).

The type of method / constructor parameters has nothing to do with the 
syntax of anonymous inner class declarations, although it may be that 
expectation of this kind of use persuaded the designers to not provide a 
more general facility.

>                I'm assuming clean OO here, so there is no use of the
> instanceof operator to determine additional functionality.

If one could do as the OP desires, then one could, via a cast, assign 
the instance reference to multiple variables of different declared 
types, and otherwise use it as each type.  Use of instanceof need not be 
required.

> The object you create is created as a JPanel; not a QueryFormatter (that
> is the type of the variable). Even though the object may be used as such.
> Assuming that you do not use a programmer-informed cast nor the instanceof
> operator, it doesn't need to be a QueryFormatter. It may be more useful in
> it's current form of couse, but in that case the concept of what the
> object is for is big enough that the object's class merits its own name.

This is all true.  Moreover, it seems likely to me that any design that 
requires a JPanel to be a "QueryFormatter" (whatever that may be) is a 
bit bolluxed up anyway.  A custom JPanel subclass might _have_ a 
QueryFormatter, or a QueryFormatter implementation might _have_ a 
JPanel.  It might even be the case that some higher-level object _has_ 
both a QueryFormatter and a JPanel.  But a JPanel shouldn't _be_ a 
QueryFormatter, nor vise-versa.

-- 
John Bollinger
jobollin@indiana.edu