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
-~----------~----~----~----~------~----~------~--~---
