Thomas:

>>The one function ( _BETWEEN(tu1, tu2, tu3) deals with the incoming datatypes dynamically (hence the "u" in the parameter name, meaning "unknown datatype")! What a concept!!! Try THAT in C# or VB.NET and watch the compiler puke.
>
>Duck typing is more beneficial to RAD

Quack!

>>
>>Of course, this approach uses more CPU cycles than strongly typed parameters, which WOULD necessitate overloading and run faster. But if VFP compatibility is your goal, here's your simple, 100% compatible solution, and if you don't call the function in a big loop, who will notice a fraction of a second? Honestly...
>
>sitting on a couple of fences on this topic <g>. I am somewhat of a perf nut, as I sometimes get called to speed up underperforming apps. Foremost for ETec's venture is IMO a early shipping implementation. Performance should be looked at in a second release as long as the performance is roughly in the same ball park range, as unneccesary microoptimization is evil. OTOH as between() is one of the rushmored operations, chances are it is called also on large table based operations, where cycles count.

I agree -- functionality should come first and speed-tweaking next. But with Etec's approach, you CAN use strong typing even with the first version, as long as you are willing add associated data types to your function call parameters and write the associated overloaded functions to take advantage of them. Figure out where you get most bang for the buck and start there, worry about the rest later. IOW, you CAN do this:

_BETWEEN(int nParam1, int nParam2, int nParam3)

and watch the performance go through the roof (according to ETec, some 1,000%)

>>
>>I don't doubt that more people will eventually join the effort, once it gets a little better organized. I sense "Stick-It-to-the-Man" and "Don't-Tell-Me-It-Can't-Be-Done" emotions bubbling just below the surface, waiting to be stirred into action.
>
>I sure hope so - as now there *is* an effort to open source more of a vfp-compatible runtime. As open source projects sometimes "fizzle out" having a company with business interest wanting to use the results is actually a boon in my view.

Right-o. I wouldn't be nearly as interested in this possible option if it wasn't for the pretty strong proof-of-concept publicly available today, as well as the responsiveness of the company to any problems I have encountered using more and more VFP's language features in my own testing. ETec generally fixes problems and adds needed features within 24 hours of a request. This may change, of course, as requests start adding up and coming in fast and furious, but at least they do seem to know what they are doing with .NET and VFP.

>
>>And if it finally doesn't pan out, so be it. There are other fish to fry in the ocean. But at least we will give it our best shot, no?
>
>I am not betting the farm on it and I will not put all the eggs in one nest. But I will program a few methods before I post in threads where I don't believe "results" will follow. One of my recurring thoughts whenever somebody was gleeful that vfp is still developed while "traditional" vb was shafted against quite a few public MVP resetments was that such inertia could also happen to vfp after a decision is reached.

Of course you can't and shouldn't bet the farm on infant technology like this, but what you CAN do is cover all of your bases and help out when you have some time, because that increases the odds of this effort actually succeeding.

As for VB -- It is certainly possible that VFP fizzles just like VB6 did. However, there is a difference here, because VB people had at least the lure of VB.NET as an out without abandoning their entire codebase. In retrospect this didn't seem to work out all that great, however, even after MS came out with conversion utilities years later -- there were simply way too many changes, architectural and syntactical, for a simple translation/refactoring of large VB6 -based systems... (note: I have no first hand experience on this, this is just what my VB colleagues have told me)

Therefore, since there is no clear (or even murky) route to go from here and relatively easily refactor our existing VFP apps while staying with a Microsoft development platform, this is more of a dead-end than the VB6 fork-in-the-road was. Now we have to climb a fence or backup out of the VFP dead-end. Luckily we have much more time to make educated decisions than VB6 programmers did.

Later.


Pertti