Lightweight peer implementation

[Bryce McKinlay]

On Tuesday, Aug 12, 2003, at 03:46 Pacific/Auckland, Scott Gilbertson 
wrote:

> Bryce wrote:
>> Yup, I agree. Lightweights should be implemented entirely in the
>> "generic" part of the code, not in the peer code.
> Thanks, guys.  I've been trying to get someone to express an opinion 
> one way
> or the other on this issue for some time.  I look forward to getting 
> the
> lightweight components issue off my "pending" list.
>
> I agree with all of what Bryce said:
>  - lightweights should be generic
>  - there should be no need to check for a null peer

Well, I actually said there might be reason to check for null peer. In 
the JRE implementation, creation of the peers doesn't happen until the 
component is added to a container and/or its made visible. Just 
guessing - but this might be because some windowing systems don't allow 
the native widget to be created unless it already has a parent?

> Bryce wrote:
>> Does anyone have an idea on how
>> much this matters in the real world?
> I think that whenever get/set operations are available and not final, 
> you
> are obliged to use them, even if you're not sure whether it matters in 
> the
> real world.  If something is allowed, you've got to assume someone 
> will do
> it.  When I'm subclassing Component in an application, I don't 
> hesitate to
> override whatever method I think will get the job done.  Of course 
> "get"
> methods are kind of special that way, but if Sun says they're 
> overridable,
> so be it.

What makes this worse is that there are so many different get methods 
to do the same or similar things in the AWT. eg:

getX() getY() getWidth() getHeight() getSize() getBounds() 
getBounds(Rectangle) getLocation() getLocation(Point) etc

A client could decide to override any of these, so to be compatible 
with every peice of code that might be out there we'd need to call the 
same methods that that the JRE's implementation does in the same 
situations. In the lightweight case it seems to be getBounds(), which 
ain't the most efficient since it allocates every time we call it.

Perhaps we could adopt a policy of making sure to be compatible with 
the JRE with regard to what set methods are called but being relaxed as 
to what get methods are used. But its probably best to match the JRE 
wherever its possible.

Regards

Bryce.