While we're having this interesting discussion here's another thing.

It is a computer science rule that objects and methods and procedures are supposed to be small and encapsulated. In a car the design of the spark plug is such that it serves a single purpose. It has simple elegant connections to other components. That is the heart of OOP. There is a blue print for the spark plug somewhere. The blue print is not the spark plug - just as source code is not the object.

That said - if all the blueprints for every part of a car are kept in a single drawer in a file cabinet what benefit is gained? In the physical world there might be a consideration of "tidy", if they are all alphabetically arranged. However having every engineer fighting to get into that one drawer is silly, or even a single file cabinet.

In the software world, there is no reason for cabinets at all. If I want the spark plug class, I just request it. So why is it the default behavior to put anything more than one class in one vcx? The scx, the frx, the lbl all are entities, not containers of disparate, even unrelated entities.

Same goes for procedure "libraries". These were only ever needed at design time, not at runtime, and only because the old DOS 8.3 filename was too limiting.

These practices can both go the way of the dodo.


>>
>>Here's a few things I use to keep the mdot thing straight.
>>
>>1 A macro isn't a memvar. The second you use the & you have a command. So no mdot is required. However, the second I use & I immediately add the trailing optional period, just as I add the trailing ) after using a (. This practice means any time I use macros within an object reference, I automatically get the .. correct.
>>
>>2 An array isn't a memvar. It's a collection of elements. m.laArray[1,2] makes no sense at all.
>>
>>3 an object is stored in a memvar.
>>
>>4 use mdot everywhere it will permit you, even in assignments, even and especially if you have a naming convention. Mdot is built into FoxPro for a reason. I trust the creators of the language far more than the Hungarian notation camp, and far more than the most vocal mdot naysayers.
>
>I think that your points 2 & 4 are colliding.
>
>Array references hold the same ambiguity problem that other memory references have:
>
>

>CREATE CURSOR ACursor (AName C(10))
>INSERT INTO ACursor VALUES ("Hello")
>
>LOCAL ARRAY AName[1]
>
>m.AName = "World"
>
>? AName
>? m.AName
>