Addressing A Comment About Array Syntax
In the comments to my last post (http://www.horwith.com/index.cfm/2008/7/2/frequently-under-implemented-cf-functions#comments) Ben Nadel made a few comments that require a lengthy enough response that I had to post a blog entry in response to clarify my position. Let me begin by first thanking Ben for "forcing" the issue - that's a very good thing. Now, to address his comments/concerns.
First, to address my comment that "I would also, probably 99% of the time, not hire a candidate who did it on a code test" - referring to dynamically naming a variable inside if quotes on the left hand side of an equals statement in a set. Yup, I definitely stand by that statement. "Yes", Ben, for using a "documented feature of the language" and "No", it's not at all "silly" nor should you "pretend you didn't read that". I stated quite deliberately that I wouldn't be likely to hire someone who did that on a code test. After 13 years of doing code reviews, peer evaluations, and troubleshooting other people's code believe me - I know what's easy to read and maintain and what isn't. I'd never fire a developer for doing it, but in the code you submit for a code test that's part of a job interview, you're supposed to be submitting a sample of the best work you can do. Though I do first need to determine if you can technically fulfill the role you're applying for, after that the first thing I care about is whether or not your code will be easy to read and maintain... and that type of code is not. I'm expecting a great example of your work in an interview. If it helps to put things into perspective, I'd also be unlikely to hire someone who did a "SELECT * FROM" in a query they submitted as part of an interview code test, too. If you want more examples I've got a ton of them... there are plenty of things that you REALLY don't want to submit to me (or anyone else) when you're interviewing for a job (how about CFINSERT or CFPDATE tags to name a few more?)
Now, to get to the "meat" of Ben's comment that needs addressing - the statement that array notation "seems to be a bug and violates the general rule about struct notation". Wow - I'm not sure where to start. First of all, it's not at all a bug, it's quite deliberate and it works exactly as it should 99% of the time (I keep using that number - "perhaps I do not know what it means"... or I'm just generalizing). The example given (http://www.bennadel.com/index.cfm?dax=blog:224.view) is a specific example of a bug in how the caller scope works within custom tags (the first comment to the post, made by Ray Camden, even states that very fact). While I'm still on the subject of things I don't ever want to see from applicants (or in ANYONE else's code in general) - you should not pass a string that "paths" a variable in the request scope to a tag and then set it in the caller scope. While I do agree that what Ben stumbled on in that experiment is a bug in the server behavior, it's also only able to be replicated if you do something completely wrong in your code to begin with. The caller scope is supposed to be a pointer to the "variables" scope of the page that called it... you shouldn't be trying to force it to do something other than that to begin with. From an architecture point of view, encapsulated code is supposed to be data-in and data-out... the last thing you should ever do is try and "force" encapsulated code to set a variable in a specific scope - that violates so many best practices that I don't know where to begin.
Getting back to the behavior Ben discovered and describes in the blog post he referenced, array notation per-se, work exactly as it should everywhere that I can think of, and under "proper use" that includes the attributes scope. Also, I see know evidence that it has "clearly been overloaded in an undocumented way" any where but in the example he showed... and if you use the caller scope as intended (to write to the variables scope of the caller page) you'll find that it works just fine as well. Array notation is not a bug, so please don't call it such and please try to use it (at very least, I don't think it's fair to tell people they shouldn't use it). If nothing else, you'll be glad you did when moving to other environments (so many of which support array notation for accessing object properties and associative array keys).
For the record, this wasn't an attempt to pick on Ben or to flat-out reject what he had to say (I suppose I owe you a coffee after this one, Ben)... the world needs guys like Ben to try and hunt down obscure behavior. The simple fact that his commentary prompted me to write this post is a testament to the value of his input. It's ALWAYS important to see/hear both sides of any argument - no matter how much people may religiously oppose or support your opinion. It also happens that in this case I also happen to be very confident that I am able to show that the arguments aren't that relevant. There also isn't necessarily a "right or wrong" answer in this case, but hopefully folks have gotten some food for thought from it all.
First, to address my comment that "I would also, probably 99% of the time, not hire a candidate who did it on a code test" - referring to dynamically naming a variable inside if quotes on the left hand side of an equals statement in a set. Yup, I definitely stand by that statement. "Yes", Ben, for using a "documented feature of the language" and "No", it's not at all "silly" nor should you "pretend you didn't read that". I stated quite deliberately that I wouldn't be likely to hire someone who did that on a code test. After 13 years of doing code reviews, peer evaluations, and troubleshooting other people's code believe me - I know what's easy to read and maintain and what isn't. I'd never fire a developer for doing it, but in the code you submit for a code test that's part of a job interview, you're supposed to be submitting a sample of the best work you can do. Though I do first need to determine if you can technically fulfill the role you're applying for, after that the first thing I care about is whether or not your code will be easy to read and maintain... and that type of code is not. I'm expecting a great example of your work in an interview. If it helps to put things into perspective, I'd also be unlikely to hire someone who did a "SELECT * FROM" in a query they submitted as part of an interview code test, too. If you want more examples I've got a ton of them... there are plenty of things that you REALLY don't want to submit to me (or anyone else) when you're interviewing for a job (how about CFINSERT or CFPDATE tags to name a few more?)
Now, to get to the "meat" of Ben's comment that needs addressing - the statement that array notation "seems to be a bug and violates the general rule about struct notation". Wow - I'm not sure where to start. First of all, it's not at all a bug, it's quite deliberate and it works exactly as it should 99% of the time (I keep using that number - "perhaps I do not know what it means"... or I'm just generalizing). The example given (http://www.bennadel.com/index.cfm?dax=blog:224.view) is a specific example of a bug in how the caller scope works within custom tags (the first comment to the post, made by Ray Camden, even states that very fact). While I'm still on the subject of things I don't ever want to see from applicants (or in ANYONE else's code in general) - you should not pass a string that "paths" a variable in the request scope to a tag and then set it in the caller scope. While I do agree that what Ben stumbled on in that experiment is a bug in the server behavior, it's also only able to be replicated if you do something completely wrong in your code to begin with. The caller scope is supposed to be a pointer to the "variables" scope of the page that called it... you shouldn't be trying to force it to do something other than that to begin with. From an architecture point of view, encapsulated code is supposed to be data-in and data-out... the last thing you should ever do is try and "force" encapsulated code to set a variable in a specific scope - that violates so many best practices that I don't know where to begin.
Getting back to the behavior Ben discovered and describes in the blog post he referenced, array notation per-se, work exactly as it should everywhere that I can think of, and under "proper use" that includes the attributes scope. Also, I see know evidence that it has "clearly been overloaded in an undocumented way" any where but in the example he showed... and if you use the caller scope as intended (to write to the variables scope of the caller page) you'll find that it works just fine as well. Array notation is not a bug, so please don't call it such and please try to use it (at very least, I don't think it's fair to tell people they shouldn't use it). If nothing else, you'll be glad you did when moving to other environments (so many of which support array notation for accessing object properties and associative array keys).
For the record, this wasn't an attempt to pick on Ben or to flat-out reject what he had to say (I suppose I owe you a coffee after this one, Ben)... the world needs guys like Ben to try and hunt down obscure behavior. The simple fact that his commentary prompted me to write this post is a testament to the value of his input. It's ALWAYS important to see/hear both sides of any argument - no matter how much people may religiously oppose or support your opinion. It also happens that in this case I also happen to be very confident that I am able to show that the arguments aren't that relevant. There also isn't necessarily a "right or wrong" answer in this case, but hopefully folks have gotten some food for thought from it all.
Funny you say that. After writing the comment a couple days ago in which I mentioned that paying attention to the contents of loops is one of the "golden rules" I discuss when I teach my classes on software architecture and application optimization. There are more... a lot more. I have at least 5 days worth of materials, actually (I teach architecture classes that are anywhere from 1 - 5 days long). After posting that comment, I began thinking about whether or not I should begin porting the golden bits of those materials to blog posts... I'm happy to say I've decided that I will begin introducing my readers to that content. It may take a little while to begin, as I have a list of about a dozen more topics I've been meaning to blog about that I really want to get to first... but make no mistake, it's coming.
I am sorry - I believe that I misspoke. I did not in any way intend to say that array notation was bad or buggy. I love array notation / struct notation and use it all over the place. It is not buggy at all. In fact, its beauty is the reason that Evaluate() have become all but useless in the everything but the most extreme cases of dynamic method evaluation. My only comment on buggy was directed towards the way the CALLER scope works.
I have to say that my understanding of CALLER was a bit off. I had thought of it more as a pointer to the calling page, not a specific pointer to the VARIABLES scope. I just took at the documentation and you are correct... **HOWEVER**, the documentation is wrong (which is probably why I never looked at it that way). If you run this code:
<cfset "CALLER.REQUEST.Foo" = "Bar" />
The value "Bar" gets saved into the REQUEST scope, not the VARIABLES scope. However, at a top level page, if you tried to run this:
<cfset VARIABLES.REQUEST.Foo = "Bar" />
It would save it to a nested struct off of the VARIABLES scope. So, it seems that the documentation is not truthful in terms of how the CALLER scope should be used - it is not a pointer to the VARIABLES scope, but seemingly a pointer the execution context of the calling page.
However, the documentation does seem to align with you as far as *intent* goes. They *want* you to think it is a the VARIABLES scope, just as you state that it is (it just turns out that intent and the implementation are different... or the intent was just not explained correctly).
That being said, I am not sure how any of that violates any ideas about encapsulation. In fact, the very idea that you are passing in the return variable name feels like it upholds encapsulation. The use of a variable is like saying "Here is a container, when you are done, just throw your value into this container." It doesn't require the custom tag to know anything about where that is going. As you say, all it cares about is "data-in and data-out."
To me, the return variable is the same as a Callback function in Javascript. The handling logic might be passed through, but it is still not coupled to the executing code in any way other than the fact that is has to be executed.
As far as not pathing a variable, I don't see any other way to do this without having to first store an intermediary variable in the VARIABLES scope. If that is the case, you end up seeing a lot of code like:
<cf_tag variable="tmpValue" />
<cfset REQUEST.Foo = tmpValue />
When I see stuff like this it definitely makes me cringe (come on, you gotta agree with me on that one :) ) This is something that I would point out as a step that should be eliminated.
Of course, this whole conversation got started because of the CALLER scope. In reality, this is the only place that I ever used quoted dynamic naming. Any other place allows for dynamic Struct/Array notation for variable (ex. FORM[ "field#i#" ]).
As for the readability and maintainability and employability of quoted variables - I stand by my opinion as strong as you do. If I saw this technique being used all over the place, I would suggest using struct notation; however, if I saw this in sample code for a job interview, I would not automatically dismiss - rather, I would use that as a flag to say "Wait a minute, here's a guy who really understandings ColdFusion's dynamic power - I better not toss him aside just yet, especially since there is such a shortage of ColdFusion programmers around these days."
And just to calm people, as Simon said, we are not singling each other out - it is just good to see both sides of an issue.