Method calls vs lambda calls
Neal Gafter
neal at gafter.com
Wed Dec 16 11:38:46 PST 2009
On Wed, Dec 16, 2009 at 11:10 AM, Stefan Schulz <schulz at the-loom.de> wrote:
> Neal Gafter wrote:
>
>> On Wed, Dec 16, 2009 at 6:36 AM, Stefan Schulz <schulz at the-loom.de
>> <mailto:schulz at the-loom.de>> wrote:
>> I didn't say anything about making a method. If the short-hand
>> invocation syntax is allowed, putting names of function-typed variables
>> in the same (scope-relative) space like methods is a way to ensure not
>> to have methods and function-typed variables with the same name.
>>
>> I'm afraid it doesn't ensure that at all. Because methods may overload,
>> a given scope may have many definitions for a given name in the method
>> namespace.
>>
>
> Too bad. Is there any possibility to hold the full signature of methods and
> function-typed variables in some way to being able to resolve these
> conflicts? Maybe an additional function space? Sorry, if this sounds a bit
> naive.
I'm not sure what you're asking. The mechanism for resolving these
conflicts today is (compile-time) overload resolution. It would have to be
extended to handle the case of a mixture of methods and variables of
function type.
> As this
>> has to hold for inheritance, too, I do not see a problem in
>> function-typed variables of subclasses to @Override those of a
>> superclass, as the information is already there. (Of course, they must
>> additionally hide normal variables having the same name.)
>>
>>
>> What semantics are you imagining for this overriding? What if the thing
>> being overridden is a method?
>>
>
> I didn't mean to being able to override methods with function-typed
> variables, or vice versa (although this sounds interesting).
>
> So, what would be the conclusion?
> * If any method m exists in a class's hierarchy, one cannot define a
> function-typed field m?
> * If a function-typed field m exists in a class's hierarchy, one cannot
> define a method named m?
> * If a function-typed field m exists in a class's hierarchy, will a field
> named m (of any type?) in a subclass hide the function-typed field m?
> * If a non-function-typed field m hides a superclass's function-typed field
> m, would it be possible to define a method named m in that very subclass?
Good questions, and there are many more. Function-typed variables can be
declared as local variables and parameters too. They can also have a type
of a generic parameter in a superclass but be inherited into a subclass as a
function type:
*class Base<T> { T t; int t(int x) { return x; } }
class Derived: Base<#int(int)> {}
*
if Derived.t in the function namespace?
A complete specification must provide clear answers to all these questions.
Cheers,
Neal
More information about the lambda-dev
mailing list