On May 25, 2010, at 2:12 PM, Charles Oliver Nutter wrote:
On Mon, May 24, 2010 at 8:22 PM, John Rose john.r.r...@oracle.com wrote:
Right. Here are the degrees of freedom I see at this point:
- whether to accept SAM types which are not interfaces (default: yes)
- whether to allow a query API
Le 25/05/2010 22:57, Charles Oliver Nutter a écrit :
I think that you should maintain two codebases
(I am not kidding),
because to really unleash the power of JSR 292
you have to use MethodHandle every where.
If all your codebase use method handles, you
don't need boxing anymore along
Le 26/05/2010 15:05, Attila Szegedi a écrit :
On 2010.05.25., at 22:57, Charles Oliver Nutter wrote:
On Tue, May 18, 2010 at 4:44 PM, Rémi Foraxfo...@univ-mlv.fr wrote:
[...]
One important question for me is how multi-method interfaces would be
handled. I had
On Tue, May 18, 2010 at 4:44 PM, Rémi Forax fo...@univ-mlv.fr wrote:
[...]
One important question for me is how multi-method interfaces would be
handled. I had originally tried to use Scala's Function interfaces
in Duby to represent closures, but they all have multiple abstract
methods that
On May 18, 2010, at 1:18 PM, Charles Oliver Nutter wrote:
One important question for me is how multi-method interfaces would be
handled. I had originally tried to use Scala's Function interfaces
in Duby to represent closures, but they all have multiple abstract
methods that must be handled
Changeset: e2709716a4ea
Author:jrose
Date: 2010-05-18 00:35 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e2709716a4ea
meth: add proxy maker for closures
+ meth-proxy-6953246.patch
! series
___
mlvm-dev mailing list
Well this one looks interesting. I'm generating several thousand such
abstract adapters; this would allow me to potentially use my same
abstract supertype for them all with either indy or non-indy backing
them up...
On Tue, May 18, 2010 at 7:35 AM, john.r.r...@oracle.com wrote:
Changeset:
Le 18/05/2010 09:45, Charles Oliver Nutter a écrit :
Well this one looks interesting. I'm generating several thousand such
abstract adapters; this would allow me to potentially use my same
abstract supertype for them all with either indy or non-indy backing
them up...
It's only useful
It does indeed. Am I reading this correctly that we will now(/soon) be able
to create proxies for abstract classes?
On Tue, May 18, 2010 at 9:45 AM, Charles Oliver Nutter
head...@headius.comwrote:
Well this one looks interesting. I'm generating several thousand such
abstract adapters; this
On May 18, 2010, at 1:00 AM, Tobias Ivarsson wrote:
It does indeed. Am I reading this correctly that we will now(/soon) be able
to create proxies for abstract classes?
Maybe; it's just a draft so far. I expect *not* to use reflect.Proxy; we need
something more opaque and optimizable.
There
On May 18, 2010, at 12:59 AM, Rémi Forax wrote:
It's only useful when bridging JRuby and Java,
It could also be useful for bridging language A to language B.
For example, Clojure has a suite of Function interfaces.
But the key use is as you say, for interoperating with the Java platform APIs.
On Tue, May 18, 2010 at 5:18 PM, John Rose john.r.r...@oracle.com wrote:
On May 18, 2010, at 12:59 AM, Rémi Forax wrote:
It's only useful when bridging JRuby and Java,
It could also be useful for bridging language A to language B.
For example, Clojure has a suite of Function interfaces.
[...]
One important question for me is how multi-method interfaces would be
handled. I had originally tried to use Scala's Function interfaces
in Duby to represent closures, but they all have multiple abstract
methods that must be handled completely differently. I'd need to
provide my own
13 matches
Mail list logo
