[BBB-DEV] re: Re: re: Re: org.jdesktop.beansbinding.Property should be interface

[Kevin Day <kevin@trumpetinc.com>]

ok - thanks for expanding on it (including examples from your other post in reply to Witold's question).  I'm still trying to get my head around how the code would change if Property were an interface (note that I'm not trying to be difficult - I just want to make sure that I clearly understand what's going on).

 

 

I think that there are a couple of things that are making this difficult to follow:

 

1.  The use of P$ for the interface name and the static variable.  This is, certainly, legal - but it makes it really hard to figure out what's going on.

 

2.  I'm not entirely clear whether the wiki is showing usage scenarios with Property as a base class or as an interface.  For example, I see the following code (provided as an example of how property objects would be accessed):

 

Person.P$.address().street();

 

 

If I understand correctly, this particular case is definitely true (this is a leaf property, so it would work).  But the following:

 

Person.P$.address();

 

would not work (unless we can make Property an interface).  Instead, it would have to be:

 

Person.P$.address().this$();

 

 

 

Have I captured that properly, or totally missed the mark?

 

If I've got it right, then the block of code that shows:

 

Person.P$.address().city(); // or
    Employee.P$.address().city(); // or
    Employee.P$.employeeNumber();

 

 

would seem to be inaccurate, right?  It would only be accurate if Property could be an interface?

 

 

I understand that Props is there to provide a reference to the properties of the base class in the hierarchy, but I'm having a hard time extrapolating from there to figure out exactly what the problem is with the abstract base class.  Is the problem more of an internal implementation detail of PropsFactory?  From the discussion so far, it sounds like it has implications that extend into the actual code of both the bean and the code that uses the properties themselves.

 

Sorry to be obtuse on this!

 

- K

 

----------------------- Original Message -----------------------

  

From: Peter Levart <peter.levart@marand.si>

To: dev@betterbeansbinding.kenai.com

Cc: Kevin Day <kevin@trumpetinc.com>

Date: Thu, 16 Jul 2009 14:29:41 +0200

Subject: [BBB-DEV] Re: re: Re: org.jdesktop.beansbinding.Property should be interface

  

On Thursday 16 July 2009 01:15:49 Kevin Day wrote:
> We do create our own Property implementations (code outside the API), but I could live with Interface + Abstract Base Class as a compromise, if there's a solid reason for making that change.
>  
> My concern, though, is that for the situation that Peter is wanting to use it for (I think - I'm still a little unclear), we would wind up with tons of little implementations of the *interface* in all of our beans, not derived from the base class.

That depends on the internal implementation. There are different strategies.

Using runtime class generation means that generated classes are "compiled" Just In Time which eliminates binary compatibility issues.

1st I was thinking of runtime class generation using javassist. In that case I would surely generate classes that extend Abstract Base Class. But even If using dynamic JDK Proxies, their Handler's could be coded in a way that delegate all Property's method invocations to a real Property implementation which is derived from the abstract base class so that adding methods to interface and abstract base class would not break it.

> A change to the interface would then have massive impact to existing code (code that really never intended to have anything to do with Property - but was just using it as a convenient way of exposing it's properties).

Only if the choosen strategy would generate classes as part of main program compilation (using javac processors for example). But I'm not a fan of that approach.

> I'm pretty sure that having an abstract base class that implements the interface would not address the issue (that would just put Peter right back where he is now, I think).
>  

Not quite so. That would be just fine.

>  
> I'm quite eager to see some examples of how interface would impact his strategy.
>

Property being an interface would enable me to get rid of Props interface (a container for "this" property) and would therefore simplify the syntax of obtaining Property instances where property paths end with a bean that has sub properties.

To be fair, even if Property is an abstract class, I can do this. I can create a special implementation of Property which is subclassable and instead of inner P$ interfaces create inner abstract subclasses of this special Property implementation.

But using this approach I cannot:
- use JDK dynamic Proxies
- use multiple inheritance for P$ types

Peter