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:
and returns the "abcde". So the type of the 2 expressions does not have to be the same
This returns 1234
But look at it from vfp POV:
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.
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
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
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
