Type checking cannot be trusted.
Repro:
<cfscript>
function f1(numeric myNumeric) {
return min(myNumeric, 1);
}
function f2(numeric myNumeric) {
return myNumeric.min(1);
}
</cfscript>
<cfscript>
function f3(date myDate) {
return dateAadd(“d”, 1, myDate);
}
function f4(date myDate) {
return myDate.add(“d”, 1);
}
</cfscript>
I can break someone’s f2 by passing a date to the numeric argument. I can break someone’s f4 by passing a numeric to the date argument.
Look at f1 vs f2 and f3 vs f4. See the only difference is the use of BIF vs member functions.
If you want to use member functions on numeric or date arguments, you’re going to need to write extra code to verify that the numeric argument is numeric and the date argument is a date.
Thoughts??
Thanks!,
-Aaron
Success:
function f5(string myDateTime) {
if(isValid(“date”, trim(myDateTime))) {
writeOutput(dateAdd(“m”, 1, trim(myDateTime)));
}
}
f5(now())
f5(“2018-01-01T00:00:00Z”)
Failure:
function f6(string myDateTime) {
if(isValid(“date”, myDateTime.trim())) {
writeOutput(myDateTime.trim().add(“m”, 1));
}
}
f6(now())
f6(“2018-01-01T00:00:00Z”)
IMO, both are completely legit yes?
Adobe?
Thanks!,
-Aaron
Hi James,
Yes, myDate+1/myDate++ are shorthand for adding 1 day:
– http://www.forta.com/blog/index.cfm?mode=entry&entry=5A1DE7BC-3048-80A9-EF7E090A7E99B257
– CF10 example: https://trycf.com/gist/614f88c32797f621ab8cfa9e57250459/acf?theme=monokai
That’s why, when cfloop’ing over a date range, the index value is actually a number. And since CF is* type-casting, min(foo, 1) works even when foo is a date. And dateAdd(foo, “d”, 1) works even when foo is a number. And, side-note, isValid(“string”, now()) has always returned true, and a string argument has always allowed a date.
* Issue: Currently, member functions are type-specific, not type-casting. Meaning, foo.min(1) errors if foo is a date, and foo.add(“d”, 1) errors if foo is a number. And if a foo date passes thru a string argument (ex: an argument that accepts date objects and formatted date strings), foo.trim() errors.
This means developers cannot use member functions in many cases, unless they add additional/unnecessary checks to determine the underlying Java type (java.lang.string, coldfusion.runtime.OleDateTime, java.lang.Double, etc) before using a member function.
Question: member functions should be type-casting like the rest of CF, yes?
Thanks!,
-Aaron
You must be logged in to post a comment.