RE: [API] Code snippet I .- fast property retrieval (not unit aware)

I was just proposing that the string representations of unequal values should also be unequal. Using the string representations to test for inequality would not, however, be appropriate. It would probably be inefficient anyway.

What is the justification for not including units in the string representation? Perhaps it would be the temptation to parse the string (which is definitely not something I would want to see). However, if an application intends to display the strings to a human then there should be some way to know a) if the human should be interpreting the string in some units, and b) what those units are. So either we introduce the idea of default units for the toString() of any value to which units can apply, or we include the units in the string. If I were to merely present "0.000000000001" as an output with no indication of what it means, then what's the point? It's meaningless garble.

---Rotan

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
Sent: 20 November 2007 07:35
To: public-ddwg@w3.org
Subject: RE: [API] Code snippet I .- fast property retrieval (not unit aware)



I think it would be better if we simply said tat string representations should not be used for testing equality - use .equals instead. It will be hard to ensure that different string representations are not the same for arbitrary values and units of measure.

And yes, +1 to that toString(); though we need to be clear that it returns the value without units i.e. it returns

0.000000000000000001

Not

0.000000000000000001 parsecs

Jo

> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of Rotan Hanrahan
> Sent: 19 November 2007 23:22
> To: JOSE MANUEL CANTERA FONSECA; public-ddwg@w3.org
> Subject: RE: [API] Code snippet I .- fast property retrieval (not unit
> aware)
> 
> 
> +1 to the proposal to have a toString() method in the property value
> class. We should also require that if two property value object represent
> different values (i.e. they are not equal) then their toString() methods
> should also return strings that are not equal.
> 
> I think the values returned should be boxed types. We should be able to
> make a reasonable assuption that the developer will know what return type
> is appropriate. I also think that helping the developer during compile
> time is useful, so appropriate typing that can be tested during
> implementation/compilation would be useful.
> 
> The "fast food" version is starting to look good.
> 
> ---R
> 
> ________________________________
> 
> From: public-ddwg-request@w3.org on behalf of JOSE MANUEL CANTERA FONSECA
> Sent: Mon 19/11/2007 23:12
> To: public-ddwg@w3.org
> Subject: [API] Code snippet I .- fast property retrieval (not unit aware)
> 
> 
> 
> Hi,
> 
> Here a start a series of code snippets trying to center the discussion
> on the DDRPropertyValue object and its methods. The most simple property
> retrieval is the so-called fast food version. Here is an example
> 
> DDRPropertyValue value = ddr.getPropertyValue("resolution_width",key);
> System.out.println("Retrieved value:" + value.getValue());
> 
> So here comes the first question:
> 
> Now the DDRPropertyValue has a getValue method that returns an Object.
> Do we want it to be as generic as an object or do we want specific
> methods such as
> 
> getBoolean()
> getInteger()
> getDouble()
> getString()
> 
> ???
> 
> Also from my example it seems to be good (at least in Java) to have an
> implemented toString() method at the level of DDRPropertyValue that will
> return the property value as an String, simplifying even more the task
> for the developer, that will print the value with
> System.out.println(value) where value is a DDRPropertyValue object. That
> toString() method will actually call the getString() method.
> 
> Best Regards
> 
> ----
> José Manuel Cantera Fonseca
> Telefónica I+D
> 
>

Received on Tuesday, 20 November 2007 10:08:49 UTC