This page is no longer maintained — Please continue to the home page at www.scala-lang.org

ju.Properties

4 replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

"No implicit conversion of a mutable.Map[String,String] to a java.util.Properties"

I'd be happy to write this (and would like to have it) but it strikes me
as something which was intentionally not done. But, like the reporter I
can't find any verbiage to that effect. Can you comment?

milessabin
Joined: 2008-08-11,
User offline. Last seen 33 weeks 3 days ago.
Re: ju.Properties

On Thu, Jul 1, 2010 at 7:40 PM, Paul Phillips wrote:
> Re: https://lampsvn.epfl.ch/trac/scala/ticket/3589
> "No implicit conversion of a mutable.Map[String,String] to a java.util.Properties"
>
> I'd be happy to write this (and would like to have it) but it strikes me
> as something which was intentionally not done.  But, like the reporter I
> can't find any verbiage to that effect.  Can you comment?

It was intentional. java.util.Properties is a complete basket case:
note that it implements Map and given that the
conversion were originally designed to be bi-directional I couldn't
see any way to make it work sanely in this case.

Cheers,

Miles

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: ju.Properties

On Thu, Jul 1, 2010 at 10:28 PM, Miles Sabin wrote:
> On Thu, Jul 1, 2010 at 7:40 PM, Paul Phillips wrote:
>> Re: https://lampsvn.epfl.ch/trac/scala/ticket/3589
>> "No implicit conversion of a mutable.Map[String,String] to a java.util.Properties"
>>
>> I'd be happy to write this (and would like to have it) but it strikes me
>> as something which was intentionally not done.  But, like the reporter I
>> can't find any verbiage to that effect.  Can you comment?
>
> It was intentional. java.util.Properties is a complete basket case:
> note that it implements Map and given that the
> conversion were originally designed to be bi-directional I couldn't
> see any way to make it work sanely in this case.
>
Even if we could mak it sanely (and we can't, I agree with Miles
here), it still would make no sense.
ju.Properties is a special case of Map[String, String]. For instance,
consider anoter Map[String, String] hat associate regexps with search
results. I'd be hard pressed to call that a ju.Property. But an
implicit convesrion would make it seem like one.

Cheers

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Re: ju.Properties

On Thu, Jul 01, 2010 at 10:37:30PM +0200, martin odersky wrote:
> Even if we could mak it sanely (and we can't, I agree with Miles
> here), it still would make no sense. ju.Properties is a special case
> of Map[String, String]. For instance, consider anoter Map[String,
> String] hat associate regexps with search results. I'd be hard pressed
> to call that a ju.Property. But an implicit convesrion would make it
> seem like one.

OK that's fine, I'm not actually so interested in the "implicit" part:
but can I write the conversion unimplicitly for those who may just be
dealing with honest Strings like nature intended?

Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: Re: ju.Properties
> Date: Thu, 1 Jul 2010 14:45:30 -0700
> From: paulp@improving.org
> To: martin.odersky@epfl.ch

> > Even if we could mak it sanely (and we can't, I agree with Miles
> > here), it still would make no sense. 
>
> OK that's fine, I'm not actually so interested in the "implicit" part:
> but can I write the conversion unimplicitly for those who may just be
> dealing with honest Strings like nature intended?

Yes please and many thanks! - I probably should have asked for a non-implicit conversion in the first place as I realized that ju.Properties was (in theory) a Map[Object,Object]. However, the conversion *is* possible and should follow the lines of the getProperty(String key) method. That is, if the Properties contains non-String values, they are simply ignored when converting to a scala Map[String, String]


Get a new e-mail account with Hotmail - Free. Sign-up now.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland