| [DataBinding] Interface anomalies for types [message #447502] |
Fri, 07 April 2006 06:55  |
Eclipse User |
|
|
|
(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 12:54  |
| Eclipse User |
|
|
|
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 02:49 |
| Eclipse User |
|
|
|
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 12:42 |
| Eclipse User |
|
|
|
> 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
|
|
|
Powered by
FUDForum. Page generated in 0.08497 seconds
Home