No, sorry I still don't understand what do you mean. I didn't ask about how would I use assemblies from or in other languages. Saying we don't need ORM I assume you are trying to say something else from impedance mismatch and Linq to me (but I don't understand what). Anyway not important. We can talk about it when there is some sort of VFP that gets near Linq.
Cetin


>Hi Cetin,
>
>when writing a .Net assembly, I can reference other assemblies, and then just use them in the code, typically using their namespace in the program's header. DLL's created with the VFP Compiler for .Net can be used in this fashion by other .Net languages. A language which produces assemblies that can be used in this fashion is a first-class .Net citizen.
>
>This cannot be done with IronRuby or IronPython. I described the process through which one does use code written in those languages within .Net.
>
>I hope that makes things clearer.
>
>Hank
>
>
>>Sorry I don't understand.
>>Cetin
>>
>>>Hi Cetin,
>>>
>>>No I'm not kidding: we don't need ORM under whatever name, because we assign a controlsource, and the fields are automatically (dynamically) mapped. In VFP there are not full objects (one can't bindevent a field), but in the extensions created under the VFP Compiler for .Net they are full objects. They could have been in VFP, but development stopped.
>>>
>>>The other dynamic languages require the instantiation of the compiler to create an object. Under the VFP Compiler for .Net, the result is a .dll callable directly from C#, or any other .Net language capable of calling CLI-compliant dll's. The former is not really first-class citizenship. The latter is. I guess whether one would call the former a close distance or a far distance is subjective.
>>>
>>>Hank
>>>
>>>>A friday night commenting??? VFP has no impedance mismatch?:) Probably kidding.
>>>>You know that Beth was not serious in that "Why would I, VFP had LINQ and OOP in 1995" sentence. VFP never had something like Linq. It would be wonderful if a VFP .Net compiler could add Linq to VFP.
>>>>I don't also understand the meaning "second class and held at a distance". It should be a close distance:)
>>>>Cetin
>>>>
>>>>>Hi Mike,
>>>>>
>>>>>indeed. If you read the MSDN overview on the Entity Framework, it talks about solving the "impedance mismatch" (their term) between data and objects. And the MVC framework is yet another attempt at the same thing. Just as Linq was. Just as ADO.Net was. VFP has no impedance mismatch, of course.
>>>>>
>>>>>In Net 4.0, they have a new static type called Dynamic. So they can declare a variable dynamic and then create an object using the, e.g., IronPython compiler, as we would use newobject(). So dynamic languages within Net 4.0 can run, but they are second-class citizens, held at a distance.
>>>>>
>>>>>The eTecnologia VFP Compiler for .Net effort, however, produces first-class .Net dll's, CLI-compliant, that can be called just as though they were written in any of the static .Net languages.
>>>>>
>>>>>So, once again, VFP was there first. <s>
>>>>>
>>>>>Hank
>>>>>
>>>>>>I found this interesting comment by Beth Massi as she discusses the history of Visual Studio in her most recent blog entry:
>>>>>>
>>>>>>"I came from a different background (dbase), and not a Microsoft product until 1990 (they bought FoxPro). Always a data-based programmer I didn’t have much experience with C++ back then, and only a tiny bit of Visual Basic. (Why would I, VFP had LINQ and OOP in 1995 ;-))"
>>>>>>
>>>>>>Who knew at that time that VFP was foreshadowing things to come over 10 years later. Oh wait, if I'm not mistaken, C# 4.0 is going to be a "dynamic language" too. I'm not sure what that means, but somehow I get the feeling VFP was there already.
>>>>>>
>>>>>>What's old is new again.