Input needed on FoxPro array support

[kevclark64]

I don't know how hard it would be to implement, but 1 of the things that I've always wished I could with Foxpro arrays is to declare an array with members, such as Dimension myArray = {1,2,3}

It would be great to be able to use that syntax but otherwise have the array be a standard Foxpro array.

[robert]

Kevin,

Right now we do not support this for FoxPro arrays. But we could add that when needed.

FYI: FoxPro arrays are implemented as a type that inherits from the "normal" XBase array and the literal that you specify in your example is a "normal XBase array" at this moment.

These XBase arrays are quite different from FoxPro arrays, since every array element may contain another array element. And you can nest them infinitely. You can even point an array element back to the root of the array (circular arrays).
So you cannot redimension them from (2,5) to (5,2) and expect the values to be saved.

However if you code in the FoxPro dialect then you can use the Normal XBase arrays as well.
You just have to declare them in a different way:

Code: Select all

LOCAL myArray = {1,2,3}   AS ARRAY    // AS ARRAY is optional but will produce better code 

or

Code: Select all

VAR myArray := {1,2,3}     // := required at this moment

or

Code: Select all

myObject.Property = {1,2,3}

You can also use similar functions ALen(), AIns() and ADel() but they work a bit different.

Robert

[mainhatten]

We plan to release a new version (2.8 ) of the product 2-3 weeks from now. This will include the new FoxPro array support
...
The Dimension statement should also work and it should also allow you to re-dimension arrays without loosing the contents of the array.

Hi Robert,
there is a chance I might enhance GetWord.Prg in August to cover alines() functionality as well (if it is not already assigned or done). There are a few kinks in alines() having more features (read behäviours to implement) than what is plausible or expected from documentation.
This could lead to sometimes having discrete implementations for edge cases to keep performance at vfp expectation level. But I already have some ideas how to to hook up the patterns currently used with the approach already for some scenarios - should cover most usage currently done in vfp similar to the "separators" from there for default, single parse char and list of single parse chars. Perhaps take a stab at table munging with GetWordCount/GetWordNum "better practice". Hope by then a good idea for string "Parsechar" list comes up.
Till August I'll get myself reaquainted with x# (have not played a lot with newer versions). Will holler if I get bribed into doing other stuff and have not enough time to do it.

regards
thomas

[mainhatten]

Robert,
looked up current version of GetWord - I still recognize it

When fumbling along without real knowledge what declarations like "new export method" map to when overriding I was glad when I found something working (tested in detail only speed differences of delegate method vs. classic method overload for single char, Whitespace and so on).

Are your changes just more in line with current coding style, but resolving to equally performant IL (or perhaps identical IL sometimes) or are some constructs addled with slower performance ?

Can you point me somewhere in the docs to read up on, as I saw nothing on "best practice" and more or less coded by trial and error ? I believe I know more than typical vfp coder about runtimes like IL or JVM and their concepts, but when searching back then in part in C# literature and x# docs I was info overloaded without guiding light, map or compass. Will probably happen to other vfp as well. I can read "Core-x#" now better and will try to find my hints in those sources, but a hint in the docs on what keywords map to and are best practice might help those coming in and run headlong into new world of Dotnet, Visual Studio, Compiler switches and much more.

tia
thomas