Continuing the discussion from IsDebugMode function:
This is a very good point… I would assume it’ll be mostly the same bods using the .cfm and .lucee versions, so is this “very similar but not quite the same” gonna be a problem? Or at least something to think about, when “fixing” functions that don’t quite behave properly / ideally in CFML?
–
Adam
I don’t have a problem with different behavior between .cfm and .lucee as long as it is documented.
Andrew Penhorwood
Surely that is the whole point of .cfm and .lucee otherwise I don’t see the point of .lucee. In .lucee the tags, functions, language constructs, etc… should behave how they are “meant to” not in the broken CFML way, for me this is the main reason for having the new dialect.
I don’t think you really understood what I said.
As Igal intimated, having a function doThing() which performs [some thing] in CFML, but having doThing() in .lucee doing [something related but different] is less than ideal, as it could be confusing remembering which one does which.
This is not what was suggested for isDebugMode() really, cos I think we agree the name is wrong anyhow… but imagine if we were to leave isDebugMode() as-is in CFML, but then “fix” it to behave like ColdFusion’s function (which flags whether debug output is enabled, not debug mode) in .lucee. Igal’s point - correct me if I’m wrong, Igal - is that it would not be so cool to have a function in CFML which does one thing, and the same function in .lucee do something different. It’s a reasonable concern I think.
Does that make more sense now?
Digression:
That said… I don’t think the raison d’etre .lucee is “to fix the mistakes of CFML” is it? IE: we’re going to continue to compare CFML and .lucee after .lucee is actually “a thing”. Isn’t it supposed to be “learn from the mistakes of CFML, and don’t repeat 'em in this new offering”. Whilst the comparison gets made during requirements capture & planning, once it’s implemented we’re not supposed to be thinking “.lucee is a ‘fixed’ version of CFML”, are we?
[if you feel like responding to the digression, perhaps consider “reply as new thread”, rather than cluttering this one, eh?]
–
Adam
Ok, I’ve read all of what Igal said now and I now understand what he means. Yes, it would make more sense to change it and remove the CFML function from the Lucee dialect and yes once Lucee is a thing the comparison to CFML should essentially stop.
we don’t have that with only one exception, date/time functions. in the Lucee dialect we removed all the classic date functions that are using en_us locale in the back and replaced with the “LS” equivalent, but in the end that has simply added a new argument “locale” and it is using by default the locale defined for the enviroment.
Otherwise there is no function with the same name that acts different.