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