xsharp.eu • FoxPro function list updated - Page 7
Page 7 of 7

FoxPro function list updated

Posted: Fri Mar 13, 2020 4:34 pm
by mainhatten
Hi Robert,
doing the cut to version 3 and the conversion to 4 took a bit more time than expected. Did not get everything done according to idea..
robert wrote:I have looked at your GetWord..() functions.
There are some things defined in the code that are not used (anymore) such as:
- delegates
- interface
- several classes
Do you want to keep these in there ?
The delegates were intended to be used if GetMorelanguage were to be implemented: the trick of speeding up lower half of lowest byte is fine for texts with mostly Latin chars, but texts in Greek, Cyrillic and so on suffer. Best to copy the delegates to that class and comment out the GetMorelanguage and the delegates but keep out-commented as hint on how to implement if asked.

The GetSingle class is nice, dry and reasonably fast. The GetSingleOpt does nothing but elminate the call to ::Equals() via virtual or delegate method - so not really DRY, as most of the code is copied, but it is faster by 20/25%, which I am a bit unwilling to give up.
Either go for cleaner, but slower code eliminating GetOptSingle or move the Properties and methods from GetSingle into GetSngleOpt, Fix base class reference and delete getSingle.
Some other questions:
- oActiveObjc is declared as OBJECT and then the method GetWordHandler().SetStru() calls its method SetStru(). This is compiled as a late bound call now. I would like to use early bound code in the runtime (faster and less chance of errors). Is there a special reason why this is untyped?
Reason is simple: Me not knowing enough DotNet in General, xSharp in specific ;-)
I already wrote to Chris about me not being happy with the solution compiling - I had hoped for "more". Here the Interface should come into play: idea was, that oActiveObjc can be one of the several objects lazy loaded, but ALWAYS implements the interface with identically named methods as in vfp Function and "offers" this momentarily set object with those 2 methods to the user. It was in my idea something like a pointer to specific methods, similar to an object handle gotten from an activeX object after you QueryInterface() the instance for another interface implemented, for example one of the IPersist* ones..
And yes, it should not be late bound. But first tries showed me that xSharp barfs on trying to use default C#8 methods there and I probably did not hit directly on correct syntax - was something planned for this weekend, ILSpy loaded and following C# examples, translating them to xSharp.

For me that was the biggest hurdle: not knowing how to express concepts read on the net for C#, not finding them in xSharp docs in quick-scan mode, dropping back to find someting similar in xSharp sources.
Example: Constructor calling parentclass constructor, vfp "dodefault" known to be not correct, C# "base" does not compile, so search sources for "constructor", see "super", facepalm as hope of forgetting Java is set back... I HAD searched for "Super" in the doc as keyword, nothing returned, had not tried directly in code.
I am now armed with IlSpy (thanks Fab), but other vfp-ers testing xSharp waters might be helped MORE with less, but concise docs, perhaps a table mapping C# feature to xSharp translation, similar to a cheat sheet ;-)

So if you know already how to cast all those worker objects with the/to generic interface common to them, by all means implement.
You have also introduced new classes and defines. Should these stay public (and then be documented) or can I make these internal and then they do not have to be documented.
I described the planned pattern for optimized working on billion row tables a few posts back to Chris. You work with the one or more GetWordHandler obhects, set there the filter chars or options, get the automatically loaded/enabled worker object sporting the Interface with the 2 named methods to call without other overhead on the records.
IsInDelimiter clearly better private, SetStruct should also kept from user - I use it in dev and (more) in testing. Uncertain if creating "magic string values" like "" for vfp-defaults, Null for DotNet:IsWitespace.is enough: if more languages need to be filtered, a bitwise flag-approach might be more concise
- what is the idea of iMethod in GetWordHandler() and what is the meaning of the numbers such as 22, 37, -4, 1 and 3. In DotNet I would normally use an Enum for this with descriptive names.
Is leftover from previous versions introducing new cases on member is faster dev than going via Enum, keeping the numbers identical between 3 and 4 helps on benchmarking in the wee hours.
The whole SetActive might be changed - the nullcheck and if true object creation into an access/get method, therby switching over to property, then setting oActiveObjc perhaps by just returning an object from an Array with iMethod - but this is not really time critical like the other stuff, but seems to follow Java/C# pattern closer.
I did NOT consider it "done", only fast enough to include with the vfp calling functions for vfp-like usage - adventouros devs can always look at the code. But if devs think it better to get othr functions done, no problem here...

If I left out some mental steps in description, pls ask .

regards
thomas