Mike,

Using your analogy,

If building a car, not all parts come individually and neither would you store them that way. For example you might receive and store your parts for motor management together to avoid having 2million individual parts all stored at individual places.

I've got a classic car repairshop as a client and if you're going through their parts warehouse, there is a clear visible organisation of parts.


Back to the software analogy. All your classes about the data objects layer might be stored together, where they are easier to find.

In short, it does not make sense to have huge class libraries with large numbers of unrelated classes, but it make no sense either to have individual libraries of classes clearly related to eachother (and often only used in one certain context) in all individual libraries.

Walter,


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