Expression2 can be strong typed.
Zdenek
Let's write the EVL() function for X#...
- Zdeněk Krejčí
- Posts: 19
- Joined: Wed Sep 04, 2019 8:07 am
Let's write the EVL() function for X#...
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
Robert
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
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Let's write the EVL() function for X#...
Zdeněk
The only advantage would be that in the call to EVL() the expression does not have to wrapped in a USUAL.
Robert
There is very little benefit in strong typing Expression2 because is returned in a USUAL.Zdeněk Krejčí wrote:Expression2 can be strong typed.
Zdenek
The only advantage would be that in the call to EVL() the expression does not have to wrapped in a USUAL.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
-
- Posts: 200
- Joined: Wed Oct 09, 2019 6:51 pm
Let's write the EVL() function for X#...
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
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.
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
to be used to (half-)automatically fix the source code into something like
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
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
But look at it from vfp POV:Btw I noticed that VFP allows this:and returns the "abcde". So the type of the 2 expressions does not have to be the sameCode: Select all
? EVL("abcde", 1234)
This returns 1234Code: Select all
? EVL(" ", 1234)
Code: Select all
Function FieldAppender(tcCsvFldList, tcOptionalAppendTo)
tcOptionalAppendTo = evl(tcOptionalAppendTo, "DefaultIfEmpty")
for ...
next
return tcOptionalAppendTo
= FieldAppender("VNam, NNam, Adr")
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
.....
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
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