Hi Thomas,

the DLR has call-site cacheing, which is why IPy has the speed it does. On second execution, it will be as fast, or in certain circumstances faster, than C#. It remembers signatures, basically. It's basically what you pointed out about IPy and Python. Boo will be using the DLR for dynamic dispatch, so I would expect similar results.

The reason I am using Boo for development of the tools, and for the initial version of the framework, is that I will not be constrained in the use of .net class attributes, which IPy still can't do, and probably will never do in .Net fashion (for fear of offending the pure-Python constituency, a valid concern from MS's perspective), and because debugging for Boo in SD works beautifully, and for IPy in SD, it's still pretty messy. Plus I like Boo's attitude. If I have to live with someone, I have to like their attitude. <s>

re: classes -- Boo classes are like VFP classes in terms of functionality. They are by default Public and Virtual, which is true for VFP as well.

Boo does not have the ability to add properties at runtime; however class methods are objects, and most of the time I can get what I want that way. When an object is declared as duck, it can be anything at runtime. E.g., declare an array as duck, and each member can be a different .Net type; and can be passed to .Net framework methods as .Net types -- at least I think I've done that. <s>

Boo does not have optional parameters, which is something of a pain; but when it moves to .Net 4, it should gain that capability as well, since .Net 4 has it.

IPy returns .Net types with difficulty, using clrtype() and the super properties (double underscores). Boo does it natively. It has that quality of being to-the-point.

With regard to the future: Boo's extensibility (plus the new Microsoft.Data assembly) looks to make it possible to streamline datahandling (the DynamicDataRoy collection looks like it could be a .Net Datasource, but I haven't given that a go yet). Right now, though, I'm focusing on making data access easy through methods. Playing with the AST is easily done in Boo, but that's just the icing on the cake. Right now I believe I have the ingredients, and am starting to mix them. <s>

Hank





>Hank,
>>The speed difference between static and dynamic languages is basically eliminated by innovations in the DLR, based on real-world testing.
>
>Is this specifically based on your Boo experiences ? (If so, pls tell me more <g>)
>
>From my POV the DLR mechanisms for addproperty()-functionality follow closely the Ironpython implementation
>(add a new dict for such properties) - speaking of expando objects. So there is a lookup penalty for dynamic properties
>even if the code is of "traditionally compiled" C#/VB CLR.
>
>In the traditional compiled languages you still have a heavier hit on reflection compared to exec and eval in IPy,
>but running in IPy is generally slower compared to pure C# - just like vfp function call is slower than C++ function call,
>method calling in IPy is slower than C# for instance. [That it is good enough fore most tasks is on another page
>as well as the lousy startup hit Dotnet shares with java, but not with CPython or vfp]
>
>What is truly amazing is the fact that IPy general speed is sometimes faster than CPython -
>especially when taking the slowness of the Jython interpreter into account as base line for a managed runtime.
>But that is also a different topic.
>
>Other currently argued concepts (as the prototype based approach of Googles javascript compilation)
>I haven't read about as implemented in the CLR/DLR languages AFAIR.
>[vfp had some nice ideas - I view the vfp inheritance implemetation as prototype based,
>while the addproperty() is akin to adding a new key into the vfp equivalent of the dict]
>
>> So now it's down to what language does the job better for a given individual, in a given context: there is no more straight-jacket.
>Not so fast...
>There are some API's (Datagrid... grrr) which explicitely need set/get property accessors or steer you again into ADO.Net.
>So while its getting better, there are static crystallized contexts still in the fwk.
>
>Again: if you can shed some light on the Boo mechanism (aka "true" .Net objects even for addpropertied), tell us....
>
>regards
>
>thomas