>>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.

---

Same here, there is nothing worse than looking at a property and thinking "that looks familiar", then assume it's a native VFP property, and then waste time searching the on-line help for more information.

Some of the comments about Strong Typing (IMO) look like they might be confusing the issue - if, in VB one spots something like:
filler = 20
one would probably (and quite reasonably) assume that filler was numeric - but what kind of numeric (integer, real, etc.)?

For me, Strong Typing, can have three flavours:
1. At run-time, an attempt to assign a value of one data type to a variable (or property) of another, causes a run-time error.
2. At compile-time, the compiler checks for mismatched assignment and generates a compile-time error. IMO this is better than number 1.
3. In the IDE, if you type a line of code that would later result in an incorrect assignment, the IDE would display an immediate warning - IMO this would be the best approach (this would probably need to have a switch so that developers who hated it, could turn it off).

The above (IMO) whilst connecting very much with data typing, does not impact on whether it is a good idea to adopt a naming standard for fields, properties, variables, etc.