Structkeyexists or Yes, No, Maybe So
Perhaps I'm just being picky here but why do some functions in CF return a boolean (true/false) and others return a boolean (yes/no)?
For example StruckKeyExists() is one such culprit it returns a Yes or a No, which in CF is boolean. The problem naturally comes in if you decide to send the results from a StructKeyExits to a language that doesn't understand that yes/no in reality means true/false. Even if you use the serializeJSON() function to convert your data to a JSON formatted string, the Yes/NO does not convert to a boolean in JavaScript whereas a True/False is. In fact serializeJSON converts Yes/No to a string!
The CF9 documentation for StructKeyExists even indicates that the result of the function is True if the key exists. They say nothing about Yes.
What I would like to see in the next release of ColdFusion (Railo too) is that all Functions that return a boolean return it as True/False and we say goodbye to this Yes/No nonsense.
Subscribe
Subscribe via RSS
Follow me on Twitter
Or, Receive daily updates via email.
Tags
adobe air ajax apple cf community cfml coldfusion examples ext flash flex google javascript jquery max2007 max2008 misc open source programming railo software technology ui
Recent Entries
No recent entries.
Blogroll
An Architect's View
CFSilence
Rey Bango
TalkingTree
Wish List
It's set as on or off.
Always buggered me :-)
Oh dear *red face*
Oh I do realize that CF is loosely typed but a little consistency goes a long way, and will go a long way to making serializejson a little more predicable. While javacasting in some cases may help in some cases, I feel it to be more of a work-around than a solution.
It is my opinion that a consistent approach to boolean return values is the first step. In the end if it really becomes an issue a switch to a typed language is always an option.
Just meant that it's one of the downsides of working with a loosely typed language.
Have you filed a bug on CF too?
You may claim that it's because CFML is loosely typed, but CF has a lot of baggage - I honestly wouldn't be surprised if this is for compatibility.
I have to agree with T Rafferty here I think it's baggage myself and not really to do with a loosely typed language. It has always been one of my pet peeves in cfargument that required can be true/false or yes/no.
I don't think this would have bothered me so much if I wasn't doing so much jQuery and passing json back and forth and seeing numeric, true/false, and "yes"/"no" all being returned from serializejson where a true/false "should" be returned. The only place where it really works is when we use true/false in CF for true/false.
I guess I can't blame CF for the "bad" return structures but I can blame the language for making it harder to or perhaps impossible to refactor the legacy code to return clean boolean values.
as many tabs as required