tracker issue : CF-4033628

select a category, or use search below
(searches all categories and all time range)

Member functions for encoding

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Neil Pugh / Neil Pugh (Neil Pugh)

Created: 08/09/2015

Components: Language

Versions: 11.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Windows 7

Vote Count: 2

Listed in the version 2016.0.0.297996 Issues Fixed doc
Verification notes: verified_fixed on August 22, 2019 using build 2016.0.01.298513
Create member functions for the new encoding functions:


and for the rest

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4033628

External Customer Info:
External Company:  
External Customer Name: Neil
External Customer Email:  
External Test Config: My Hardware and Environment details:



Can you pls detail how these have been implemented? They've not just been done as methods of String, I hope? They're a separate class with static functions, right?
Comment by External U.
6315 | October 12, 2015 03:50:44 AM GMT
Hi Adam, These are added as string member functions now like for example <cfscript> s = "My url-encoded string has special characters & other stuff"; writeoutput(s.urlEncodedFormat()); </cfscript> I didn't understand what you are asking about. What do you mean by static functions in this context ? Thanks, Pavan.
Comment by S V.
6316 | October 12, 2015 04:10:20 AM GMT
Well they're a bit too focused to be methods of a String class; they're about encoding, they're not about *strings* per se. So they should be in something like: String Encode.forHtml(String stringToEncode) String methods should only relate to the general concept of what it is to be a String. They should not include handling of special types of strings. This is basic OO.
Comment by External U.
6317 | October 12, 2015 05:02:52 AM GMT
Looks good Pavan.Thank you.
Comment by External U.
6318 | October 12, 2015 04:12:40 PM GMT
Sorry, was being hasty before. That class / method name example I gave was rubbish: Encode is a verb, so makes no sense as a class name; and the method suggestion had similar grammatical shortcomings. Something more like Encoder or StringEncoder or something for the class, and the methods themselves should be the same as their procedural counterparts, so: static String StringEncoder.encodeForHtml(String stringToEncode)
Comment by External U.
6319 | October 12, 2015 04:37:17 PM GMT
So, S V Pavankumar?
Comment by External U.
6320 | November 05, 2015 03:37:41 AM GMT
Hi Adam, We don't have support for invoking a static class methods directly from CFML(other than createobject java). Also doing this requires a way to have package and import for those classes to avoid conflicts with user's variables. we can log an enhancement for such generic approach and will be done in next release. Thanks, Pavan.
Comment by S V.
6321 | November 18, 2015 04:41:37 AM GMT
> We don't have support for invoking a static class methods directly from CFM Well no, but your Java proxy allows calling of static methods on objects, eg: [code] s = ""; // String object bs = s.valueOf(true); // String static method [/code] So all you'd need to do is to expose a StringEncoder object just like you current expose headless functions, and ppl could call the static methods on that. This doesn't require any architectural change. Later, once you sort out being able to call static methods on classes from CFML (say in CF13) you swap out the StringEncoder object for just the StringEncoder class, and the transition would be seamless. Bottom line, the encoding functions don't belong as methods on the String class, so you should not be implementing it the way you have. You need to think more about OO and the language design, rather than just slapping any old thing together, or having a generic treatment of mapping string procedural functions to OO equivalents. Do it properly, or don't do it at all.
Comment by External U.
6322 | November 18, 2015 04:53:49 AM GMT
Hi Adam, Hopefully I understand.. Would having a "Cache" object, w/ methods, be another example of what you're suggesting? Example: Cache.Get() Cache.Put() Cache.Remove() instead of cacheGet(), cachePut(), cacheRemove(), etc Or maybe I'm way off? Thanks!, -Aaron
Comment by External U.
6323 | November 18, 2015 05:44:31 AM GMT
Exactly that. Not all headless functions directly map to methods of an object. Some of them are better suited to being methods of a class. eg: Procedural: myFileHandle = fileOpen(pathToMyFile); OO: myFileHandle = File::open(pathToMyFile); Adobe ballsed-up their completion of CFScript functionality coverage with their wrong-headed, poorly-designed "generic" syntax, and CFML is worse for it. We need to prevent the same sort of design-absent approach to this sort of thing. Hence my assertion that it should either be done correctly or not at all.
Comment by External U.
6324 | November 18, 2015 06:10:16 AM GMT
FWIW, I did an assessment of how to handle all *Lucee's* headless functions some time ago. Most of it would apply to ColdFusion too:
Comment by External U.
6325 | November 18, 2015 06:11:06 AM GMT
Hi Adam, I like that: File::open(pathToMyFile) Nice! Looking at the Google doc (nice work BTW!), it looks like this could possibly help towards making CF more modular (at least in an indirect way, w/ many of the "packages" in the spreadsheet correlating to "modules"). I *rly* want the modular promise delivered :) Thanks!, -Aaron
Comment by External U.
6326 | November 18, 2015 09:12:56 AM GMT
We can evaluate the packaging of related functions for the next release.
Comment by S V.
6327 | December 09, 2015 04:10:01 AM GMT
Are you going to pull the existing ones from CF12 then? You cannot release stuff that's been implemented incorrectly and needs remedial work later. This work has been done *wrong*, so should not be released as-is.
Comment by External U.
6328 | December 09, 2015 04:12:19 AM GMT
[pressed send too soon] It's better to not release something at all, than to release something done badly. Once it's out in the wild, ppl will start using 'em. At the very least the docs for them should mark them as deprecated, and will be replaced with a different implementation "later".
Comment by External U.
6329 | December 09, 2015 04:13:29 AM GMT
Hi Pavan, Thank you very much for considering. Hi Adam, I'm looking forward to Aether fixing stuff by busting backward-compat like none other :) Thanks!, -Aaron
Comment by External U.
6330 | December 09, 2015 05:05:38 AM GMT
I too would prefer this functionality be held back and done right for CF13, rather than released in a suboptimal form with CF12 (or is it CF2016).
Comment by External U.
6331 | December 09, 2015 08:02:19 PM GMT
These are string functions. They should work like all the other string functions do
Vote by External U.
6334 | December 13, 2015 01:01:46 AM GMT
There is already a whole lot of member functions on String that was added in CF 11, which ideally don't belong to String. In fact, they were not added as member functions to begin with but got added after Adam's request. As of now, we will let it go in the release. We would need to re-look at all the member functions in the next release and see if we need to have a Static class approach.
Comment by Rupesh K.
6332 | December 15, 2015 12:03:00 AM GMT
Is that the right thing to do, Rupesh? You seem to be acknowledging that these methods don't belong in String. So should they be going in there? I did raise, and that functionality *wasn't* implemented at the time. You're right that a bunch of those didn't (/don't) belong in String (a bunch of them DO though)... I have to say that at the time I was concerning myself with the fact that the functionality was missing, not where it belonged, intrinsically. I should have thought about it more and been more clear about things I guess. I do kinda expect that part of ticket planning to be done by your team though, not the person raising the ticket. I'm split here. Obviously there's a precedent set of putting any method that acts on a String in the String class. Whilst this wasn't really that clever, it's been done now for these other ones, so perhaps it follows that there's a basis for continuing that approach for the sake of completeness. On the other hand it stuff that's acknowledged to be *wrong* should be fixed. And perhaps this more suggests the issue is broader than just these encoding functions. [thinking...] I guess the horse has kinda bolted on doing this in a thoughtful manner, so we might as well just keep doing it unthoughtfully for the time being. Had Pavan not already done the work, I'd stick with "dont do it until you can do it properly", but [shrug]. As things stand you're right: let's look at the situation a bit more thoroughly in CF2018, if you can't find time to sort it out in 2016. I do have to say though, what's the point of having the pre-release programme if at every turn your response is "we don't have time to do that now... we'll do it next time...". Also I don't want you to now use "backwards compatibility" as an excuse to not do the remedial work ;-) Hopefully in the future we can give ourselves time to think things through a bit more before implementing things. Once something's implemented... it's out the door and we're kinda stuck with it. It's not the end of the world though, I guess. For your (the Team) part, can you please be more forthcoming when you've planned the work, and share the approach with us before implementing it. More eyes & more brains on an issue might help catch this stuff before it gets implemented. At the very least you should echo back what the person has asked for, and detail what your mooted solution is, so everyone knows everyone is on the same page. You should not just charge off and do the work in a "black box" fashion.
Comment by External U.
6333 | December 15, 2015 01:13:56 AM GMT
Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Thanks!, -Aaron
Comment by Aaron N.
31150 | August 22, 2019 09:54:21 AM GMT