xsharp.eu • Let's write the EVL() function for X#... - Page 3
Page 3 of 3

Let's write the EVL() function for X#...

Posted: Fri May 08, 2020 5:26 pm
by Zdeněk Krejčí
Expression2 can be strong typed.
Zdenek

Let's write the EVL() function for X#...

Posted: Fri May 08, 2020 5:36 pm
by robert
Antonio,
I would not test using the indexof method
I would do something like this for a test to see if a string is empty

Code: Select all

FUNCTION EmptyString(testString AS STRING) AS LOGIC
IF testString == NULL .OR. testString:Length == 0
    RETURN TRUE
ENDIF
FOREACH VAR c IN testString   // this enumerates the characters in the string and is very fast
    SWITCH c
    CASE 32
    CASE 9
    CASE 13
    CASE 10
       NOP    // these are all empty, so continue
    OTHERWISE
      RETURN FALSE
    END SWITCH
NEXT
RETURN TRUE

Robert

Let's write the EVL() function for X#...

Posted: Fri May 08, 2020 5:38 pm
by robert
Zdeněk
Zdeněk Krejčí wrote:Expression2 can be strong typed.
Zdenek
There is very little benefit in strong typing Expression2 because is returned in a USUAL.
The only advantage would be that in the call to EVL() the expression does not have to wrapped in a USUAL.

Robert

Let's write the EVL() function for X#...

Posted: Sat May 09, 2020 12:09 am
by mainhatten
Hi Robert,
will try to explain my current thinking in more detail - beware, is work in progress...
First, from xSharp typical code your example must look strange
Btw I noticed that VFP allows this:

Code: Select all

? EVL("abcde", 1234)
and returns the "abcde". So the type of the 2 expressions does not have to be the same
This returns 1234

Code: Select all

? EVL("        ", 1234)
But look at it from vfp POV:

Code: Select all

Function FieldAppender(tcCsvFldList, tcOptionalAppendTo)
tcOptionalAppendTo = evl(tcOptionalAppendTo, "DefaultIfEmpty")
for ...
next
return tcOptionalAppendTo
= FieldAppender("VNam, NNam, Adr")
which in explicit coding first would need either a PCount() or VarType() check to correct Boolean datatype of 2. parameter if called with only 1 parameter. As 2. parameter is .f. when called with pcount()=1, evl() sets default AND corrects data type.
In xSharp I'd have an overloaded function of 1 parameter calling 2-parameter version with parameter set as evl() does in vfp code.

Code: Select all

Function FieldAppender(tcCsvFldList as String) as String
return FieldAppender(tcCsvFldList, "DefaultIfEmpty")
 
Function FieldAppender(tcCsvFldList as String, tcOptionalAppendTo as String) as String
.....
So returning different datatype as 1. parameter is does make sense (sorta...)

Now let me assume I am porting a large vfp application to xSharp, and as I hate duplicate code I strive for having a single code basis until I ditch vfp - using compiler #if to exclude xSharp parts not compilable in vfp.

One of the first things I'll add to my source would be type definitions generated from Hungarian notation for variable and parameters.
So in the above example it would result in string = evl(string, "DefaultIfEmpty"), which would get a performance hit if forced into usual wielding method signatures.

If a similar pattern is done on any other data type, the added functionality of empty() on strings is lost. There checks on empty() should be done directly comparing comparing against .f., 0, emptydate and so on AFTER vfp is ditched. This could be done either via compiler warning on compiling specific datatype signatures or via #if hook writing out location of calling code place to a text file

Code: Select all

Function Evl(t1 as Integer, t2 as Integer) : Integer
#if CC_WritePruneLog
= AddPruneLine(Program(Program(-1)-1), "Evl() with Integer")
#endif
if t1=0
  return t2
endif
return t1
to be used to (half-)automatically fix the source code into something like

Code: Select all

iif(t1=0, t2, t1)

When coding new stuff I think Wolfgangs example to strive for core-only xSharp is a good blueprint, and on porting I'd like to come close and not call down into usual-using code if not REALLY necessary. Yes, I had a usual-based evl() very early, but believe I kept that out of the stuff I sent over.

So that is the thinking pointing me to further overloads of evl() even if some make little sense if coding new stuff in xSharp.
Also perhaps for vfp dialect 2 dll should be added vfp_core and vfp_rt, with all functions working on usual datatype kept in vfp_rt.

Hope that was coherent and clear
thomas

Let's write the EVL() function for X#...

Posted: Sat May 09, 2020 12:39 am
by FoxProMatt
Github issue created to cover this function:

https://github.com/X-Sharp/XSharpPublic/issues/389