tracker issue : CF-4033628

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.

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.

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.

Looks good Pavan.Thank you.

Comment by External U.

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.

So, S V Pavankumar?

Comment by External U.

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.

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

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.

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.

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: https://docs.google.com/spreadsheets/d/1mqiaJRVgh26ljEKgvhb6yf7l6uCKmAmZlIcQqlzh1KM/edit?usp=sharing

Comment by External U.

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.

We can evaluate the packaging of related functions for the next release.

Comment by S V.

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.

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

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.

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.

These are string functions. They should work like all the other string functions do

Vote by External U.

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.

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 https://bugbase.adobe.com/index.cfm?event=bug&id=CF-3712186, 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.

Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Thanks!, -Aaron

Comment by Aaron N.