Pascal Costanza <[EMAIL PROTECTED]> wrote: > That still doesn't explain what DLR actually does. You can implement > these languages on top of the JVM as well. You could implement them on > any Turing-complete language, for that matter. The interesting question > how well integrated such an implementation is. > > However, Jim Hugunin seems to be willing to give more details on his > blog - the recent entry gives hints that there is indeed something > interesting going on. I'm still waiting for the meat, though...
Watch the video he linked from his blog. In short, the implementation looks really well integrated. They start with an example (in Ruby) which creates a C# control and handles the event it generates to call some VB which retrieves a list of strings from the server and then passes it to a 3d animation written in JScript. All seamless, and all running in the local browser (which in the demo is Safari). The significant part of the DLR is (I think) that you can have a single object e.g. a string, but the methods available on that object vary according to the source file from which you are accessing the object. That means in pure Python code the string has python methods, but in Python using the CLR it gains the CLR methods. Presumably in Ruby code it looks like a Ruby string and so on, but (and this is what's new) it is the same object, not a bunch of language specific wrappers around the string type. -- http://mail.python.org/mailman/listinfo/python-list
