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.klang@gmail.com>

On Thu, Aug 11, 2011 at 7:12 PM, Jason Zaugg <jzaugg@gmail.com> wrote:

2011/8/11 √iktor Ҡlang <viktor.klang@gmail.com>:
> On Thu, Aug 11, 2011 at 7:03 PM, Jason Zaugg <jzaugg@gmail.com> wrote:
>>
>> 2011/8/11 √iktor Ҡlang <viktor.klang@gmail.com>:
>> >
>> >
>> > 2011/8/11 martin odersky <martin.odersky@epfl.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