curious what people's thoughts are on this acf 11+ vs lucee incompatibility, how SHOULD it be? https://trycf.com/gist/0226ff781f4a12b8190768ac2a5e24db/lucee5?theme=monokai

There is a ticket for this

to fix in which direction?

For both versions to work

BIF( value ) // Doesn't error

value.bif() // also shouldn't error

roger, thanks

Though I understand the underlying JVM underpinnings of why it doesn't work, CFML itself really only has "simple values" .

I'd really really prefer it if ppl could learn the difference between

someFunction(canTakeManyTypesAndDealWithThem)

and

aSpecificType.aMethodOfThatType()

. In this example although there's two things called

len

, it's just dumb to think they're the same. One is a function that is implemented to take a

SimpleType

, the other is trying to use a method

len

on a

Numeric

object. This is not complicated. @bdw429s I'm kinda with you with the "make a sort of

SimpleTypeInterface

that all simple types in CFML implement". But it still seems like a bit of a hack when just "devs conceding they're having a brain fart" would be a better solution I think. Does it make any sense, for argument's sake, that

someDate.len()

returns 26? What's the length of a date? Is that a even sensible behaviour to ask about? I mean it does make sense that

len(someDate)

returns 26 cos intrinsically it's clear that the

len

implementation needs to convert the date to a string before before checking the length of that string. But does it really make sense that the operation of

someDate.len()

- and method of the DateTime type, remember - should "convert"

someDate

to a string before calling

len()

on it? I don't really think it does. All this justification of

BIF( value ) // Doesn't error

value.bif() // also shouldn't error

isn't really that sensible to me. It's just pandering to devs not engaging their brain. Or... understanding basic programming concepts. I know we set the bar very low for CFML devs, but does it need to be that low?

not sure i had any specific expectations whether numericVar.len() working one way or the other. i was iterating a struct in lucee and was checking .len() on each key's value; it bombed on the first numeric value it came across. i checked other cf versions in trycf and it was apparent that acf, through whatever means, DOES think .len() should work the same as len(). was just curious whether that should set expectations that other member functions in acf will behave similarly when there's a datatype 'mismatch'. i actually explicitly rewrote this code not long ago from bif() to .member() to see how well i liked using all modern syntax available in lucee; it had been working before that rewrite, this issue just caught me offguard

I'm with Adam that it would be very nice to have CF's native type actually be some sort of documented interface or class. Any other language I've seen with member functions on data types have a formalized definition of what methods to expect as well as a first class citizen language construct to detect those types.

this frickin' gobsmackes me:

c = new Query();
if( isStruct( c ) ) {
  dump( c.keyList() )
}

Well. It really doesn't I guess. I just rolled my eyes and went "well of course CFML does that [f***in stupid language]".

Anyone who's written any sort of generic datastructure iteration such as recursing over an object that can contain structs, arrays, strings, numbers, etc has run into that sort of thin many times as soon as something you didn't expect was present.

I'm sooo split on this:

thingThatCanBeUsedAsNumeric.numericMember()

I 95% get where you are coming from. Well I 100% get where yer coming from. Just not 100% convinced yer right. That's the 95% It comes back to whether one should consider

function(object)

should intrinsically be considered analogous to

object.function()

. I don't think it needs to be. And your - entirely reasonable point - about

thingThatCanBeUsedAsNumeric.numericMember()

presupposes it is analogous. However CFML is already a clusterfuck of a language, so I guess I don't see why CF and Lucee shouldn't implement

thingThatCanBeUsedAsNumeric.numericMember()

and

anySimpleValue.analogToFunctionThatTakesASimpleValueWhetherItMakesSenseOrNotOnTheObjectItsBeingCalledOn()

don't exactly make things worse. I s'pose. And I also take yer point that it's all well and good teaching the CFMLers to know their objects from their elbows, but this does not help framework code that needs to use generic code. Other than the fact why don't you just stick with

function(object)

as that is the already-existing generic CFML handling of such things. Nothing's forcing this generic code to use woolly-type-specific methods when there's a generic function already?

Chaining is the main thing making me want to use them, but that normally is when I'm using struct or array member functions, which don't have near the ambiguity that simple values do.

I also think I'm being dogmatic / perfectionist (for a subjective definition of "perfection") about things, and at the end of the day, what yer suggesting @bdw429s would be helpful and save confusion.