Hi,

>Everything that can be done in Boo can be done in C#, without the DLR. So it's not a matter of whether it can be done, but rather how one wants to work. At the least, Boo's compiler does for one what the C# compiler could do if the designers wanted it to, without breaking static typing at all. In C#, base.<method> performs the same as dodefault() or super(); the latter two are to my mind more descriptive (although the lengthier version can be used in Boo as well).

So 'default', 'base', 'super' - just a matter of personal preference and familiarity; the behaviour is the same?

>Rodrigo's point is that the compiler should be smart enough to figure these things out; so he made a compiler that figured these things out. Not having to make methods virtual in order to be overridden; not having to type overridden to override them; etc. It's all about the compiler being smarter.

Again just preference. So the default in Boo is the C# equivalent of protected or public? FWIW I think private is the best default since it should be a conscious decision to expose class types - not something you do inadvertently. If override is the default in Boo can you also 'new' the method in a derived class ?

>At the most, Boo's compiler does more, as I indicated. For example, if I have a button b, then I can define an eventhandler and an eventhandler method like so:
>
>b.Click += def(o,e):
> b.Text = "Clicked"

How does that differ from C# ? :
b.Click += (o, e) => b.Text = "Click";

>All the rest that is missing from the C# eventhandler code is just confusion waiting to happen: words that have to be there, but which give no additional meaning. Code should be self-documenting, as an ideal; having to type a bunch of words that lend no additional meaning gets in the way of moving toward that ideal. Of course, this effect varies by person: for those who are simple-minded like myself, keeping it simple is the key to productivity.
>
>Finally, there is the issue of static typing: with -ducky set on at the compiler level (a checkbox in SharpDevelop, on the Compiling tab under Project), all variables are duck-typed by default (but can be specified as desired). Even without -ducky, type inference will handle the typing of variables that are set directly to object instances. Where speed is useful, static typing is available.

C# has dynamic typing now . But I'd only use in extremis - haven't needed it yet ......
I'm not clear on how Boo type inference differs from C# but it must surely exhibit the same restrictions (e.g not exportable outside the scope in which it is defined, etc) ?

>Boo has other strengths, too, but I didn't focus on them. It's a great language for writing other languages, as DSLs or entirely different languages (using its compiler pipeline extensibility).

I've a feeling that I'd dislke Boo for the very reasons that you prefer it. Same is probably true in reverse of C# :-}
BTW, I still don't understand what you meant by "Also, we can modify the class more than once: with a Virtual method, you get one shot at overriding it, and that’s it."


> In fact, it appears that VFP.Net was actually being written in Boo, based on the error numbers. That accounts for it having gotten as far as it did (nothing I know accounts for it having stopped in its tracks).
>
>The SharpDevelop implementation is pretty mature: the debugging is right on, better than either the IronPython debugging is at present, and better than VFP.Net was. I suspect that's because Daniel Grunwald has been working with it for 5 years, so it has had time to mature.
>
>Hank
>
>>>I've been exploring Boo as a dynamic language, and I'm seeing that it's a great fit for VFP developers who want to work in .Net, but don't want to give up the dynamic language features of VFP. Here's a blog entry I posted, http://blog.prosysplus.com/2010/07/boo-as-dynamic-language-part-1.html , on the subject of subclassing.
>>
>>I'm a bit confused about some of the things in the blog:
>>
>>>Notice that in VFP, we don’t concern ourselves with whether a class method is Virtual or not: we can override it as we will
>>Doesn't VFP support PROTECTED and HIDDEN ?
>>
>>>And we can still call the code in the parent class, when we want to in our code.
>>True - but so what? Are you implying that the same cannot be done in NET
>>
>>>Also, we can modify the class more than once: with a Virtual method, you get one shot at overriding it, and that’s it.
>>Don't understand what you mean by this .......