Type-Specific vs Type-Casting member functions

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:

  1. myString.dateTimeMemberFunction()

  2. myString.numericMemberFunction()
  3. myNumber.stringMemberFunction()
  4. myXMLAttribute.structMemberFunction()
  5. myXMLNode.arrayMemberFunction()

These fail:

  1. myDateTime.stringMemberFunction()
  2. myDateTime.numericMemberFunction()
  3. 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

2 Responses

  1. 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.

Leave a reply

Related