Right, so, the bit I think you misunderstand is that the availability
of invokedynamic, or lack thereof, has virtually zero impact on the
feasibility and likeliness of a duck typing construct in java, the
language. You can implement it perfectly well today without
invokedynamic, see my 'syntactic sugar' example in my earlier post.
And, as I mentioned, I don't know of any JSR or serious effort to add
it, though I am a mild proponent to such an addition.
On Nov 21, 5:46 pm, Casper Bang <[EMAIL PROTECTED]> wrote:
> >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
-~----------~----~----~----~------~----~------~--~---
