Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » [DataBinding] Interface anomalies for types
[DataBinding] Interface anomalies for types [message #447502] Fri, 07 April 2006 10:55 Go to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
(I apologize for the reposting, but I noticed that I used the keyword
"Databinding" instead of "DataBinding" in my original message)

Hello!

I wonder, why IObservableValue.getValueType(), IConverter.getFromType(),
and IConverter.getToType() return Object instead of Class?

This seems both unnecessarily unsafe and inconsistent to other parts of
the library returning types, e.g. Property.getPropertyType(), which uses
the more natural return type Class.

The same questions apply to the signatures of other methods, e.g.

ComputedValue.ComputedValue(Object valueType) // Note: Object instead
//of Class!

Greetings from Bremen,

Daniel Krügler
Re: [DataBinding] Interface anomalies for types [message #447513 is a reply to message #447502] Fri, 07 April 2006 16:54 Go to previous messageGo to next message
Dave Orme is currently offline Dave OrmeFriend
Messages: 424
Registered: July 2009
Senior Member
Daniel Krügler wrote:
> I wonder, why IObservableValue.getValueType(), IConverter.getFromType(),
> and IConverter.getToType() return Object instead of Class?
>
> This seems both unnecessarily unsafe and inconsistent to other parts of
> the library returning types, e.g. Property.getPropertyType(), which uses
> the more natural return type Class.
>
> The same questions apply to the signatures of other methods, e.g.
>
> ComputedValue.ComputedValue(Object valueType) // Note: Object instead
> //of Class!

Property is used for describing JavaBeans-style properties on Java
objects, so it uses java.lang.Class to specify types.

However, in general, data binding needs to be able to work with type
systems that require metaclass objects of other than java.lang.Class.

For example, EMF uses EClass to replace java.lang.Class. db4objects
uses String names to represent types generically across Java and .NET.
This lets us be compatible with those frameworks or anything else
someone might invent.


Regards,

Dave Orme
Re: [DataBinding] Interface anomalies for types [message #447535 is a reply to message #447513] Mon, 10 April 2006 06:49 Go to previous messageGo to next message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
David J. Orme wrote:
> Daniel Krügler wrote:
>
>> I wonder, why IObservableValue.getValueType(), IConverter.getFromType(),
>> and IConverter.getToType() return Object instead of Class?

[snip]

>> The same questions apply to the signatures of other methods, e.g.
>>
>> ComputedValue.ComputedValue(Object valueType) // Note: Object instead
>> //of Class!

> Property is used for describing JavaBeans-style properties on Java
> objects, so it uses java.lang.Class to specify types.
>
> However, in general, data binding needs to be able to work with type
> systems that require metaclass objects of other than java.lang.Class.
>
> For example, EMF uses EClass to replace java.lang.Class. db4objects
> uses String names to represent types generically across Java and .NET.
> This lets us be compatible with those frameworks or anything else
> someone might invent.

Thanks for clarification, David. But I strongly recommend to emphasize
both this capability of the binding framework to support "generalized"
types and to document the fact more clearly, that getXXType does not
necessarily return objects different from Class. The current docs, which
say something like

"The value type of this observable value, or <code>null</code> if this
observable value is untyped."

do not clearly say that. Something like a note, which says that the
returned Object must not necessarily be of Class type, would be very
good.

But this discussion leads to another important point: Which requirements
(if any) does the binding framework have for those generalized types? Is
identity based on object identity or on equality? Do there exists
requirements on ordering?

Thanks and Greetings from Bremen,

Daniel Krügler
Re: [DataBinding] Interface anomalies for types [message #447603 is a reply to message #447535] Tue, 11 April 2006 16:42 Go to previous message
Boris Bokowski is currently offline Boris BokowskiFriend
Messages: 272
Registered: July 2009
Senior Member
> But this discussion leads to another important point: Which requirements
> (if any) does the binding framework have for those generalized types? Is
> identity based on object identity or on equality? Do there exists
> requirements on ordering?

See BindSupportFactory.isAssignableFromTo(). It is pretty much up to the
BindSupportFactory implementation to decide what should be done, but using
equality would make sense.

Boris
Previous Topic:[Databinding] Interface anomalies for types
Next Topic:Cancel job from status line
Goto Forum:
  


Current Time: Thu Nov 07 17:18:28 GMT 2024

Powered by FUDForum. Page generated in 0.03543 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top