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

> -----Original Message-----
> From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
> Sent: 20 November 2007 10:08
> To: Jo Rabin; public-ddwg@w3.org
> Subject: 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.

I was just observing that in general it is hard to guarantee that different values have different representations - unless you are prepared to specify the circumstances under which the representations are genenrated - e.g. that they are in the same units.

> 
> 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.

If I ask for the value in parsecs, then I expect the returned value in parsecs. I know what the unit is before I get it back. If I am careless enough not to represent that in user output, well, then I'm an idiot. That's not the DDR's problem. If I am less careless, I may choose to represent the unit in any way I like, especially for example, spelling "millimetre" or "millimeter".

Jo

> 
> ---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:18:48 UTC