I'm not sure how you can compare it either (interesting example he created). What I know is that I never have to worry about it in VFP (because it just works), and I'd prefer not to worry about it in my next (.Net) language. <s>

Hank

>Hi,
>Hi,
>
>>Correct, that is only in the Constructor, since the object doesn't exist at that point (or so the MSDN docs say). This is opposite to VFP, which makes properties of the object available before the INIT runs (and in the case of a form, before the LOAD runs).
>
>I'm not sure you can directly compare the VFP model with that of C#.
>But IAC that's what C# does - i.e. it initializes the properties of a class before the constructor runs (in fact it initializes the properties of all parent classes from most derived to base before any constructors are run then runs the constructors in the opposite order.
>
>Pretty good explanation of this (and the reasons for it) here:
>http://blogs.msdn.com/b/ericlippert/archive/2008/02/15/why-do-initializers-run-in-the-opposite-order-as-constructors-part-one.aspx
>http://blogs.msdn.com/b/ericlippert/archive/2008/02/18/why-do-initializers-run-in-the-opposite-order-as-constructors-part-two.aspx
>
>Given that explanation it's hard to see how things could be organized differently without the risks described?
>
>
>I'm old enough to remember the beta (I'm old enough to forget which one) when this came about, out of real world concerns: it began with developers needing form properties before the LOAD event had completed, never mind the INIT. This is what I mean when I say that VFP is a language that was made FOR developers as the primary principle. .Net is moving in that direction. Boo is already there. <s>
>>
>>Hank
>>
>>>>Hi Viv,
>>>>
>>>>I don't know what I meant by that either. <s> I've corrected it to say what I should have meant: that the parent method must be called before any code in the sublassed method (as the first statement in fact), rather than having the flexibility to call it wherever you want in the subclassed method.
>>>
>>>In C#? Not true. You can call the parent method at any time. Or are you thinking specifically of constructors?
>>>
>>>>
>>>>Hank
>>>>
>>>>>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 .......