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

Re: default parameter values and constructors

1 reply
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.


On Thu, Aug 11, 2011 at 7:12 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
2011/8/11 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
> On Thu, Aug 11, 2011 at 7:03 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
>>
>> 2011/8/11 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
>> >
>> >
>> > 2011/8/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>> >>
>> >> Generating overloaded variants has always the risk that unexpected
>> >> clashes
>> >> appear, and some call becomes ambiguous. So it should not be done
>> >> lightly. I
>> >> think Java interop is not a sufficiently strong reason to
>> >> mess with the language, as long as alternatives exist. And I think
>> >>
>> >> https://issues.scala-lang.org/browse/SI-4278
>> >>
>> >> does show valid ways to deal with the problem. Specifically, what's so
>> >> bad
>> >> about writing the missing constructors yourself?
>> >
>> > Because I have to both write a lot of BP, in my case it's a class with
>> > 10
>> > parameters with default parameter values, which means quite few extra
>> > lines,
>> > and also, when I want to rearrange the parameters or add or remove a
>> > parameter, I need to remember to change and/or create new constructors
>> > as
>> > well as adding all of them to unit-tests so I'm sure that the Java API
>> > works
>> > as expected and doesn't crap out silently.
>> >
>> > There shouldn't be any clashes since any user defined constructors with
>> > the
>> > same signature should take priority over constructor generation.
>> >
>> > Also, it's kind of a silent killer, because unless you actually test in
>> > Java, you won't notice the interop problem until some Java, JRuby,
>> > Groovy
>> > user tells you they don't know how to create an instance of the class...
>> >
>> > Now, clearly this is just a Java interop issue, but alas.
>>
>> Sounds like a good candidate for an opt-in annotation, a-la
>> @BeanProperty. It could also be useful on methods.
>>
>
> I'd be completely fine with that as well, I could even envision some kind of
> @JavaFriendly that could be sprinkled all over the place, or a compiler
> flag, but that's a bit more blunt.
>
>>
>> But I wouldn't want to see this by default.
>
> What problems do you envision?

Bytecode bloat.

Well, it would only be generated where you use default parameter values in constructors.
 

-jason



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: default parameter values and constructors
I like the idea of an opt-in annotation. Generally, I'd be wary of increasing language spec size or code size for removing boilerplate from Java interop.  You are dealing with Java, boilerplate is a fact of life then.

 -- Martin

2011/8/11 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Thu, Aug 11, 2011 at 7:12 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
2011/8/11 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
> On Thu, Aug 11, 2011 at 7:03 PM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
>>
>> 2011/8/11 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>:
>> >
>> >
>> > 2011/8/11 martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>> >>
>> >> Generating overloaded variants has always the risk that unexpected
>> >> clashes
>> >> appear, and some call becomes ambiguous. So it should not be done
>> >> lightly. I
>> >> think Java interop is not a sufficiently strong reason to
>> >> mess with the language, as long as alternatives exist. And I think
>> >>
>> >> https://issues.scala-lang.org/browse/SI-4278
>> >>
>> >> does show valid ways to deal with the problem. Specifically, what's so
>> >> bad
>> >> about writing the missing constructors yourself?
>> >
>> > Because I have to both write a lot of BP, in my case it's a class with
>> > 10
>> > parameters with default parameter values, which means quite few extra
>> > lines,
>> > and also, when I want to rearrange the parameters or add or remove a
>> > parameter, I need to remember to change and/or create new constructors
>> > as
>> > well as adding all of them to unit-tests so I'm sure that the Java API
>> > works
>> > as expected and doesn't crap out silently.
>> >
>> > There shouldn't be any clashes since any user defined constructors with
>> > the
>> > same signature should take priority over constructor generation.
>> >
>> > Also, it's kind of a silent killer, because unless you actually test in
>> > Java, you won't notice the interop problem until some Java, JRuby,
>> > Groovy
>> > user tells you they don't know how to create an instance of the class...
>> >
>> > Now, clearly this is just a Java interop issue, but alas.
>>
>> Sounds like a good candidate for an opt-in annotation, a-la
>> @BeanProperty. It could also be useful on methods.
>>
>
> I'd be completely fine with that as well, I could even envision some kind of
> @JavaFriendly that could be sprinkled all over the place, or a compiler
> flag, but that's a bit more blunt.
>
>>
>> But I wouldn't want to see this by default.
>
> What problems do you envision?

Bytecode bloat.

Well, it would only be generated where you use default parameter values in constructors.
 

-jason



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang



--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

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