anonymous method call
Remi Forax
forax at univ-mlv.fr
Sat Jun 1 12:32:50 PDT 2013
On 06/01/2013 08:10 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Thanks Brian and Rémi for the response to my previous question.
>
> Now that we established my lack of knowledge about the lambda type inference,
> I have another question, but please note that it is not a suggestion for
> improvement, merely a question about the limits of what would be possible.
>
> A functional interface has only one abstract method, so is there any reason it
> would not be possible to use an anonymous call to this method?
>
> For example:
>
> IntUnaryOperator operator = f -> f + 1;
>
> and instead of
>
> int i = operator.applyAsInt(1);
>
> being able to do
>
> int i = operator(1);
>
>
> Thanks.
It's possible to implement that but it exhibits a nasty property given
the way Java scope works.
In Java, the scope that contains local variables and the one that
contains method calls are separated,
when the compiler see
int i = operator(1);
it knowns that this is a method call, and it will not check if there is
a local variable named 'operator'.
So to support the new syntax and still be able to compile old code, the
compiler has to first check
if a method is available and then check if a local variable exist if no
method was found.
This rule is awful because it means that if you add a method in a class
(or worst in a super class)
you may broke an already existing code because you introduce a method
that will be used instead
of calling the lambda.
so this syntax was rejected by the Expert Group :)
cheers,
Rémi
>
> - --
> Marc Petit-Huguenin
> Email: marc at petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRqjkuAAoJECnERZXWan7Ea4IP/056K859kyo58iLD3jBpQ2J5
> SUgNE/JuBQpj8gBIia5p7iqOcEjjCYxolhTOYaZpuHfDe6/8H9R6YVpPNYOcTyVT
> trYWwM33Kccoob1k4G31um4aYBbfjWJvBOhZVQvBcLAc2qxF65/lQGPWsrGqtOFo
> 85Pl2ZAuahGymb6p8GpfSr3gmbPiOCoofh8admgpJSIs80cDAo/E9b43fVr8JAKN
> M2F8UsZbbzQ9M/mnL37cF5EKlRC4P5rMW0AnzUyYOAoTYRK/ypc4TULaYxuLlBZa
> t38YdjjQIrUb9FPBrFDLkSfp+nq9fdb7ULUnMBluZTa3OWQ63wfKhum9VQETcS/R
> h/gzMmMWxf+QF88w/tI0gkFlpgLL89n+OTs0QmByfJVWJbMGtQsfGbMqcOMxNFWh
> 4n+SLvuHX9fw/kvfsCXL9/QxiYcyWWdCZechu9MQpp9ciOrXm9HxVMIsq61HuiHb
> yum/Id+17mWgIulTJxODVXm4Dga4gLs8A6eS8ZtXmyn+/6+EWL1q4wjbzrInTTLQ
> CwP1gDQj3iv5iSg7682Ksahuj85z+oy9lTDEsmkOyk4ASQlohErM3P3ETaIYIjoC
> wFrIq28g7kBeLZSlUdJL9hsBSYeBCy1+mgXo3R++uhjgYWK+vjg1tLnxKnCskAgk
> xwHmjjuaDY3UOOtwVAmk
> =jjhJ
> -----END PGP SIGNATURE-----
>
More information about the lambda-dev
mailing list