Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
The creature that won't die
Message
From
23/03/2010 12:27:12
Walter Meester
HoogkarspelNetherlands
 
 
General information
Forum:
Visual FoxPro
Category:
VFP Compiler for .NET
Miscellaneous
Thread ID:
01456123
Message ID:
01456600
Views:
85
>>That is just a simple example, but it has far consequences:
>>
oWord = CREATEOBJECT("Word.Application")
>>I know that oWord now contains a reference to an instance of MS word. I don't know, however which version of word. Whether it is ms word 6 or ms word 2007. I don't give a hoot. I, as a developer know, that oWord will contain certain properties and methods which are common in all versions, and I can access them without having to cast it into anything.
>>
>>If I want to add an object to a form, and that object has been created through a factory, I don't know at forehand (in code) what this object is going to be typed. so in VFP you'd have something like:
>>
>>(just very simplistic, not tested)
>>
>>
FUNCTION AddObjectToContainer(cClassKey, oParent, cName)
>>LOCAL oObject
>>
>>oObject = NULL
>>
>>IF !USED("MyFactoryClasses") 
>>   USE MyFactoryClasses IN 0 ORDER ClassKey
>>ENDIF
>>
>>IF SEEK(cClassKey, "MyFactoryClasses")
>>    oParent.AddObject(cName,  MyFactoryClasses.ActualClass)
>>    oObject = oParent.&cName
>>ENDIF
>>RETURN oObject
>>
>>When writing I don't have a clue what oParent is. It could be a form, a grid, a container, a toolbar, _screen. I don't know what type of object has been added to the form etc... I don't care here either.
>>
>>The point is however, that in particular cases you don't give a hoot about its type, because YOU AS A PROGRAMMER know that certain properties and methods do exist, and telling the compiler the same might be very difficult.
>
>I've never found it difficult. Why do you regard it so ?

Because you don't know the exact type of what has been created, and you do not care either. So how am I going to tell the compiler what type it is?

O.k. can you give me a .NET equivalent for the object factory as described above.

>> This is the reason virtual classes and virtual methods exist.
>No virtual classes in .NET - maybe you're thinking of abstract?

My rant is not neccesarily about .NET but more about static typed languages in general. Thinking too much in C/C++ I guess. But thanks for the correction.

>You'll have to bend everyhting into making the compiler happy because it wants to know all at compile time.
>But, in the above, aren't you contradicting yourself?

Why?

>You use an object factory to create and add objects of an unknown type to a form.
>You then iterate over the collection of objects perfectly happily accessing the Top, Left, Width and Height properties because you know they exist.

Yeah... and how would you do that in .NET?

>On the Word example I'd much prefer, where possible, pulling it in as .COM Interop and having the full intellisense at my disposal. But, yes, there is an argument that late binding is sometimes preferable - thus the DLR in .NET4 which will give you what you need.

And DLR stands for........ exactly my point !!

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform