Lukas and I have discussed these issues a long time. There is for me a
strong incentive to avoid further complexity, both in the compiler and
in the spec. That's why I prefer the restriction, because it
simplifies several things.
Cheers
-- Martin
On Tue, Jun 2, 2009 at 4:46 PM, James Iry <
jamesiry@...> wrote:
> Good point. I hadn't thought about refinement types. I don't have a good
> answer short of devising an internal naming scheme for them, which might be
> more trouble than its worth.
>
> I don't think the limitation is too onerous. As you say, defaults replace a
> common use for overloading. If put to a vote I wouldn't vote to hold up 2.8
> over it. It's just that limitations and irregularities driven by
> implementation challenges tend to have an "arbitrary" feel to users who
> aren't involved in the implementation and I can foresee a lot of "why
> doesn't this work" messages in the mailing list around this issue in the
> future.
>
> On Tue, Jun 2, 2009 at 6:17 AM, Lukas Rytz <
lukas.rytz@...> wrote:
>>
>>
>> On Tue, Jun 2, 2009 at 14:43, James Iry <
jamesiry@...> wrote:
>>>
>>> Would it be feasible to mangle the getter's name using the parameter
>>> types of the overloaded methods?
>>>
>>> def foo(x : T1 = xdef, y : T2 = ydef)
>>> def foo(z : T3 = zdef, zz : T4 = zzdef)
>>>
>>> def foo$T1$T2$defaul1 = xdef
>>> def foo$T1$T2$defaul2 = ydef
>>> def foo$T3$T4$default1 = zdef
>>> def foo$T3$T4$default2 = zzdef
>>
>> That would probably work, except that for some types it's not obvious
>> how to convert them into a name:
>>
>> def foo(x: { def bar(): Int } = new { def bar() = 1 })
>> def foo(x: String = "uh")
>>
>>
>> What do people think, is it too much limitation if we restrict defaults
>> to one overloaded alternative? After all, defaults often allow you to get
>> rid of overloads.
>>
>> Lukas
>>
>
>
