You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Ash .." <eq...@hotmail.com> on 2003/12/04 13:50:25 UTC

RE: FW: [collections] MapUtils.getXxx() return types - repost

Reposting this, so that if we are decided on the method signatures, I can 
work on the implementation this weekend.
Ash


[Stephen]
>I would only add the
>full signature version (with default). That way the method name can just be
>getDouble().

But that would provoke the question "if I want to retrieve a primitive
without specifying a default, why should I have to mention a default (even
0) everytime??"

I would propose we inlclude both variants (with and sans default), and have
a uniform naming for them. Even if we add only the default-taking method
today, what if we decide tomorrow that the defaultless one can be useful.

And then, I think it is ok if we cannot preserve the same method names.

so, I propose the following:

public static double getIntValue(Map map, Object key)
public static double getIntValue(Map map, Object key, int defaultValue)

etc for each prim (and String)

Waiting for feedback from others.

I can implement these methods after I am done with the subarray(prim[])
ones.


>This is a very old class in [collections] and pre-dates me. I would 
>probably
>oppose adding these methods now.

But why??


Ash



>
>-----Original Message-----
>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>
>
>This is a very old class in [collections] and pre-dates me. I would 
>probably
>oppose adding these methods now. However, now that we have them, I would
>support having the primitive methods as you propose. I would only add the
>full signature version (with default). That way the method name can just be
>getDouble().
>Stephen
>
>----- Original Message -----
>From: "Ash .." <eq...@hotmail.com>
> > I am curious to know why MapUtils does not have getters that return
> > primitive types. Perhaps there was a discussion on whether it was needed
>or
> > not, you could point me to such discussion that took place in the past
>when
> > this class was conceived.
> > In any case, I think that getters that return primitives could be very
> > useful, much more than those that return wrapper objects. Thus, I think 
>we
> > could do with methods like:
> >
> > MapUtils.getDoubleValue(Map map, Object key [,defaultValue]);
> >
> > If the answer to my question is "you can do a MapUtils.getDouble(map,
> > key).doubleValue() and so on",
> > I would say, having a built-in method enhances the use of this class 
>than
> > having a programmer resort to such multiple method call. Of course, the
> > internal implementation would do the same, but in the end, client code
>would
> > look far neater.
> >
> > Let me know,
> > Ash
> >

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: FW: [collections] MapUtils.getXxx() return types - repost

Posted by Stephen Colebourne <sc...@btopenworld.com>.
Proposed method sigs look OK to me.

> public static double getIntValue(Map map, Object key)
> public static double getIntValue(Map map, Object key, int defaultValue)

Stephen

----- Original Message -----
From: "Ash .." <eq...@hotmail.com>
To: <co...@jakarta.apache.org>
Sent: Thursday, December 04, 2003 12:50 PM
Subject: RE: FW: [collections] MapUtils.getXxx() return types - repost


> Reposting this, so that if we are decided on the method signatures, I can
> work on the implementation this weekend.
> Ash
>
>
> [Stephen]
> >I would only add the
> >full signature version (with default). That way the method name can just
be
> >getDouble().
>
> But that would provoke the question "if I want to retrieve a primitive
> without specifying a default, why should I have to mention a default (even
> 0) everytime??"
>
> I would propose we inlclude both variants (with and sans default), and
have
> a uniform naming for them. Even if we add only the default-taking method
> today, what if we decide tomorrow that the defaultless one can be useful.
>
> And then, I think it is ok if we cannot preserve the same method names.
>
> so, I propose the following:
>
> public static double getIntValue(Map map, Object key)
> public static double getIntValue(Map map, Object key, int defaultValue)
>
> etc for each prim (and String)
>
> Waiting for feedback from others.
>
> I can implement these methods after I am done with the subarray(prim[])
> ones.
>
>
> >This is a very old class in [collections] and pre-dates me. I would
> >probably
> >oppose adding these methods now.
>
> But why??
>
>
> Ash
>
>
>
> >
> >-----Original Message-----
> >From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> >
> >
> >This is a very old class in [collections] and pre-dates me. I would
> >probably
> >oppose adding these methods now. However, now that we have them, I would
> >support having the primitive methods as you propose. I would only add the
> >full signature version (with default). That way the method name can just
be
> >getDouble().
> >Stephen
> >
> >----- Original Message -----
> >From: "Ash .." <eq...@hotmail.com>
> > > I am curious to know why MapUtils does not have getters that return
> > > primitive types. Perhaps there was a discussion on whether it was
needed
> >or
> > > not, you could point me to such discussion that took place in the past
> >when
> > > this class was conceived.
> > > In any case, I think that getters that return primitives could be very
> > > useful, much more than those that return wrapper objects. Thus, I
think
> >we
> > > could do with methods like:
> > >
> > > MapUtils.getDoubleValue(Map map, Object key [,defaultValue]);
> > >
> > > If the answer to my question is "you can do a MapUtils.getDouble(map,
> > > key).doubleValue() and so on",
> > > I would say, having a built-in method enhances the use of this class
> >than
> > > having a programmer resort to such multiple method call. Of course,
the
> > > internal implementation would do the same, but in the end, client code
> >would
> > > look far neater.
> > >
> > > Let me know,
> > > Ash
> > >
>
> _________________________________________________________________
> Stay in touch with absent friends - get MSN Messenger
> http://www.msn.co.uk/messenger
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org