Hi CF Community,
I’d like to get your opinions. Would you prefer CF’s member functions to be type-specific or type-casting? Currently they are type-specific.
These work:
-
myString.dateTimeMemberFunction()
- myString.numericMemberFunction()
- myNumber.stringMemberFunction()
- myXMLAttribute.structMemberFunction()
- myXMLNode.arrayMemberFunction()
These fail:
- myDateTime.stringMemberFunction()
- myDateTime.numericMemberFunction()
- myNumber.dateTimeMemberFunction()
If they were Type-Casting, then “stringy” member functions would work on any simple variable just as their BIF counterparts do.
Related ticket: https://tracker.adobe.com/#/view/CF-4187503
Please add your comments here and/or on that ticket. Please vote your opinion.
Thanks!,
-Aaron
Newbie
12 posts
I’ve commented on that ticket a few times, but here’s my most recent comment:
CFML as a language does not limit what can be done to a variable by the underlying Java objects that happen to represent it. CFML allows you to do anything with a variable that it can be cast to (automatically behind the scenes). Therefore, any BIFs that can operate on a simple value (stringy) should work as a member function. CFML doesn’t even provide a first-class method to test a simple value to see what actual java class is being used behind the scenes (and it shouldn’t– that’s an implementation detail). It is therefore incorrect to expect the CF developer to know what java classes have been used behind the scenes and to limit functionality based on that. It’s just not idiomatic to how CFML works. Some care needs to be taken here to ensure there isn’t any ambiguity in member functions and the possible underlying Java classes that might be used to represent simple values in CFML.
In past versions of ColdFusion, one could run `getMetadata(var).getName()` to find out what a variable does. I will have to try it out on 2018 beta
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
