- About Scala
- In the Enterprise
- Scala Community
- Language Research
- In the Press
- The Scala Team
- Scala's Prehistory
- Contact Us
- Learning Scala
- Tour of Scala
- Scala API
- Setup & Getting Started
- Programming Guides
- Other Guides
- Code Examples
- Scala Developers
Re: default parameter values and constructors
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?
Well, it would only be generated where you use default parameter values in constructors.
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts