>>That's more than just cool - I've had a case where it saved me about 40000 IF statements.
>
>Sorry, Dragan, I should have said "Way Cool!"

Actually, thanks for the cue, so I could chime in with one of my favorites :)

>>BTW, how does one create an object factory in dot net? In VFP, I know the easiest way is to just have a table with user-friendly class names, and actual class names and classlib names. Then it's a piece of cake to
>>
>>newobject(alltrim(factory.classname)), alltrim(factory.classlib))
>>
>>I'm mentioning this because the ADO paradigm has already brought some of the name expression mechanism into any language that uses it - the field names need not be hardcoded; I'm wondering whether there's a similar name expression mechanism for class names. Yes, I have Kevin's book, but I'd rather hear a live comment.
>>
>
>I don't have Kevin's book, and I'm only a week into C# :)
>
>Using the method in the following website, in addition to defining the new class, you'd have to modify the factory class to make it aware of the new class definition.
>
>http://www.c-sharpcorner.com/Language/FactoryPatternsinCSRVS.asp

That's hardcoding the numbers... i.e. your factory class has to know the actual keys of the classes you want to add. It can't just add classes from an arbitrary library you can add later.

The VFP's ability to run code outside an executable goes beyond Compile and ExecScript() - you can literally give it a vcx and add its names into a table. And it can instantiate an object based on a .prg or a .vcx which didn't exist when the app was deployed. I've seen this work, and it worked great. And the executable really doesn't need to know all the classes it may use.