>And in fact, base properties don't have a type identifier, so by adding one to our own (extended) set of properties, are we relegating them to second-class citizenship in our object? And if so, maybe that's not a bad thing - it might be good to see what was there already in the base language, and what I, the programmer, added.

This is one of the main reasons I like to type-name my properties - to know that it's a native or custom at a glance. With the syntax coloring, I don't worry about native v. custom methods.
With strong typing, it's my understanding that the typing will not be used w/in VFP development but rather by an app using a VFP COM object; so I'll be sticking to it.

>
>I am undecided as of now on this matter. What are your thoughts? I think I am being influenced here by strong-typing in my VB work, in which case parameter call expected values and property enums are more readily available -- as I hope they will be in VFP 7. As a result, I see a lot more properties without type identifiers. As you well know, I tend to type-identify my properties (cSSN, nAmount) but these days I am not so certain about that approach.

In the VB stuff I've been doing, I haven't cared a whit about type naming variables, since there aren't any fields to worry about, but I habitually add a type prefix anyway.

I forget, is VFP7 going to store custom pems in mixed-case, or is it supposed to keep it all lowercase like it is now? I hope it keeps it or gives some other way of telling custom from native quickly.