Meta: it would make my year if we could get one of these compiler
discussions happening once a week on a public forum like this, both for
better basic understanding about why some of these concepts are not
trivial, and for better visibility into what else is going on in the
process of continuing
I'm ok with restricting them to @JsFunction java8 lambdas. That's
likely to be the common path for web oriented code for event handling.
On Mon, Apr 18, 2016 at 10:47 AM, 'Roberto Lublinerman' via GWT
Contributors wrote:
> That is why I am
That is why I am saying that it will be easy to do for JsFunctions but due
to Java semantics (regular) lambdas are just not plain functions and thus I
don't think there is much to gain there.
I don't think there is much to gain on the regular lambdas. There are 2
different ways we can handle them
The point is that for JsFunctions you DON'T actually need to do the
makeLambda(). JsFunction was designed to be able to pass JS functions to
JAVA so there is a code path for that and we can exploit it for JsFunction
lambdas.
So x -> 42 + capture will be represented in the JAva AST as
class X {
I understand, but the trampolines cause bloat, and if you're
suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
far as code-gen is concerned, then you would not be able to make the
following code work:
foo(Callable x) { bar(x); }
foo(Runnable x) { bar(x); }
bar(Object x) { if
That seems similar to my proposal, only you're doing it in GenJsAST.
You'll still need to the makeLambda() trick to allow it to work as a
regular obejct as well, with hashCode()/equals()/getClass()
properties, as well as castMap installed. But if you use static method
delegation, the size won't be
The scheme I had in mind does not modify much the Java AST representation
but is more in the lowering to the JsAST, basically it boils down the the
following:.
1. You create the lambda body as a static method of the class where it
appears. This static method has all captures as parameters (thiis
Seems to me this'll be tricky to pull off. The GWT compiler has no
notion of captured scope. If you want to create a class type that
represents a lambda, but which doesn't actually get output as a class,
you'd have to change many many parts of the compiler.
I think perhaps the best thing you
We accept patches :)
On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley wrote:
> Given that it will be realistically a couple of years before most large
> projects could migrate to J2CL, it would be really nice to have a more
> optimal code generation for lambda's, especially
Given that it will be realistically a couple of years before most large
projects could migrate to J2CL, it would be really nice to have a more
optimal code generation for lambda's, especially for JsFunction. When 2.8
gets released, I think people will really start taking advantage of
existing
It should not be hard to make JsFunction lambdas more terse, but there are
no plans for GWT 2.x.
On Fri, Apr 15, 2016 at 8:25 AM, Paul Stockley wrote:
> Are there plans to optimize this in the GWT2.x version in the future?
>
> On Friday, April 15, 2016 at 10:57:00 AM
Are there plans to optimize this in the GWT2.x version in the future?
On Friday, April 15, 2016 at 10:57:00 AM UTC-4, Roberto Lublinerman wrote:
>
> Yes, right now all lambdas are implemented as anonymous inner classes,
> even the ones implementing JsFunction interfaces.
>
> On Fri, Apr 15,
Yes, right now all lambdas are implemented as anonymous inner classes, even
the ones implementing JsFunction interfaces.
On Fri, Apr 15, 2016 at 6:11 AM, Paul Stockley wrote:
> Am I right in saying that java 8 lambda's under the covers is implemented
> as an anonymous
Am I right in saying that java 8 lambda's under the covers is implemented
as an anonymous inner class? Is this also true for SAM interfaces annotated
with JsFunction annotated interfaces?
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To
14 matches
Mail list logo