>I think you are seriously misunderstanding
> the idea behind invokedynamic, though.
Umm ok, then let me lay out my understanding of it: To be able to
augment invokestatic, invokeinterface and invokevirtual with a way to
resolve and cache a call-site first time it's met rather than at
compile time. I realize this is to accommodate (speed up) dynamic
language which typically go through a dynamic proxy today, but what I
mean to say is that I hope Java would gain some language support for
using it as well. It would be a bloody shame not to make use of it to
solve the class of problems in Java that currently relies on painful
reflection and libraries like ASM/BCEL. And that leads us right back
on topic with the possibility of duck typing.
/Casper
On Nov 21, 3:24 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
> Eh - its useful to have especially when working with boundary system
> code (e.g. when trying to wade through a bunch of JSON sent by a
> client), but the point is more:
>
> What's in the 'blood' of the language itself? Loads of python core
> library code is fundamentally programmed to be nice and convenient in
> a dynamic structural world, and awkward in a manifest static world.
>
> C#'s code is built around manifest nominal. While structural typing
> has no been promoted to the type system itself, you could also argue
> (these things are more about how a language feels than what it can
> actually do) that this is merely syntax sugar for a more convenient
> way of calling reflection APIs. At the point the difference between a
> hybrid system and a purely static/manifest system that happens to have
> a lot of syntax sugar is theoretical only. Hence the relative
> pointlessness of trying to make a language that supports everything.
>
> invokedynamic is going to be in java7, period. There are already lots
> of tools (see the podcasts), such as the ASM library for building
> class files already supporting it.
>
> invokedynamic was never meant to be used by javac, and this hasn't
> changed. It's there just because the JRuby, Jython, et al guys -
> really-, -REALLY- want it. I think you are seriously misunderstanding
> the idea behind invokedynamic, though.
>
> The point isn't to speed up reflection API usage. In java, the few
> times you do use it, speed is not going to be the problem.
> Technically, reflection is slower than a direct call, but,
> technically, if I pee in the ocean, the water levels rise. It doesn't
> matter.
>
> In JRuby and friends, -every- -single- -call- is essentially done via
> reflection. They are smart about it, optimize things, but at the end
> of the day, a boatload of calls is done via the reflection API just to
> make it work. Its annoying for them, it inflates class size, and, yes,
> now the 2x slowdown becomes a minor nuisance. Its also kinda hard for
> the JIT compiler to work with a block with reflection access in it.
> None of these issues are relevant for java the programming language.
>
> On the issue of making some syntax sugar so you can more easily call-
> via-reflection, something like:
>
> int x = foo->bar("hi"); //syntax sugar for:
> // Method m = foo.getClass().getMethod("bar", String.class);
> // x = m.invoke(foo);
>
> There have been a few lone voices suggesting this would be useful, and
> a few scattered proposals, but nothing serious as far as I know. Very
> unlikely to show up java8, let alone java7. Again, though,
> invokedynamic doesn't really come into play.
>
> If java<->JRuby-equivalent interaction becomes extremely common place,
> I can envision a world where this use case becomes sufficiently
> important to add the syntax, and if the syntax is there, might as well
> use invokedynamic for it. But, that's a big hypothetical.
>
> On Nov 21, 1:29 pm, Casper Bang <[EMAIL PROTECTED]> wrote:
>
> > I noticed you are very much for these language-level classifications.
> > So what do you think about the C# 4.0 dynamic type, which effectively
> > allows you to specifically declare an object "duck-typable" if you so
> > fancy? I've yet to personally try this first hand but what comes to
> > mind is better/faster ways of achieving what you today would do with
> > reflection and a lot of plumbing (dynamic proxies, data-binding,
> > ORM's, legacy-system inter-op etc.). Also, is anyone up to speed on
> > how the dynamic stuff for the JVM is doing, seems like core Java could
> > benefit in the above categories as well - where reflection can be a
> > horrible experience in ceremony (mainly due to checked exceptions).
>
> > /Casper
>
> > On Nov 21, 12:27 pm, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
>
> > > Technically, duck typing is a combo of structural and dynamic typing,
> > > with emphasis on the structural.
>
> > > There are four dimensions of typing systems (and not one, as a whole
> > > host of clueless fanboys on both sides of the isle often think):
> > > (Python, Ruby, and JavaScript have the same typing system. I'll call
> > > them PRJS to be brief)
>
> > > safe vs unsafe: Objects know their own type so that trying to call a
> > > non-existent method/member doesn't cause a core dump. Used to be
> > > called 'strong v. weak' but those two terms have been mutilated beyond
> > > recognition. All languages you know except assembler and C are safe.
> > > 'safe' languages virtually always have an instanceof operation.
>
> > > dynamic vs. static: Object REFERENCES know their own type, so that it
> > > is a compile/write time error when you try to call non-existent
> > > methods. Note that this doesn't mean that you have to be explicit
> > > about it; 'var x = "foo";' is static if x itself (and not its
> > > contents) has a type of 'String'. Java is static. So is C. PRJS are
> > > dynamic. These terms have also been mangled quite thoroughly but I
> > > can't think of better names.
>
> > > latent vs. manifest (a.k.a. implicit vs. explicit): Only relevant for
> > > static languages. A Latent typing system has types but doesn't force
> > > you to declare them. A manifest type system forces you to manually
> > > declare them. Java is extremely manifest. Scala is quite latent. So is
> > > haskell. 'var x = "foo";' is latent typing. "String x = "foo" is
> > > manifest typing. Most latent typed languages allow you to be explicit,
> > > but not at all.
>
> > > structural vs. nominal: In structural languages, a type is defined by
> > > what members it has. In nominal languages, a type is defined by its
> > > name. Java is virtually entirely nominal - you cannot cast a class
> > > that has a close() method in it, but that does not implement Closable,
> > > to 'Closable', eventhough structurally that seems to be sound. PRJS
> > > are structural. Scala is a hybrid; you can declare either form of
> > > type. Java has a select few structural tendencies; classes which can
> > > also serve as an app aren't defined by a type name (such as 'extends
> > > Application' or 'implements Startable' or some such), but by a
> > > structural quirk: The presence of a static method with signature 'void
> > > main(String[])'. Also, beans are pretty much defined by the existence
> > > of methods named 'T getX' and 'void setX(T)'.
>
> > > There are overlaps. For example, you can 'do' structure with
> > > reflection in java, but the point is, these distinctions are about the
> > > typing system. While java supports manipulating, reading, and calling
> > > based on structure alone, the type system does not, and only knows
> > > about nominal types. Having a read, close, flush, seek method doesn't
> > > make you an InputStream. Implementing InputStream does. Pure
> > > structural languages generally don't have the concept of an interface.
> > > There's no point to having it - in python, any object that has methods
> > > for 'read', 'close', 'flush' and 'seek' can be fed to a method that
> > > expects an inputstream kind of thing, as those would be the only
> > > objects it would call.
>
> > > You can mix and match any of these and usually come up with a halfway
> > > sensible type system. For example, Manifest, Static, Structural would
> > > be a typing system that looks and feels a lot like java's, except that
> > > in this one, you CAN cast an object to an interface or even a class,
> > > and it'll work as long as the object has every publically accessible
> > > field/method in the interface/class. I don't know of such a language,
> > > but you could make one, and it wouldn't be too crazy.
>
> > > On Nov 21, 8:29 am, Michael Neale <[EMAIL PROTECTED]> wrote:
>
> > > > In 216, there was some talk of a desire to be able to "duck type" in a
> > > > type safe way (I think it was that episode). I believe its call
> > > > structural typing (I think traits were mentioned - but structural
> > > > typing is what was really meant).
>
> > > > Scala (of course) has this as someone guessed. You can specify that an
> > > > argument/parameter has a certain "shape" (ie list of method sigs) and
> > > > then anything that satisfies can be passed to it (in a type safe
> > > > way).
>
> > > > Of course, this must make IDE developers lives a whole lot of fun. And
> > > > by fun I mean hell. And by lives I mean no life (due to the amount of
> > > > effort it would take to help support this !).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
