tracker issue : CF-3600334

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

Remove rule that one cannot declare and argument and a VAR with the same name

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 07/24/2013

Components: Language

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Major / Most users will encounter

Locale/System: English / Win XP All

Vote Count: 4

See: http://cfmlblog.adamcameron.me/2013/07/things-i-dislike-rules-for-sake-of-rules.html

It's a pointless rule, which serves no purpose, and is only enforced at compile time, not runtime.

All it does is get in the way sometimes.

Pls remove. Pls don't put in "rules for the sake of rules" into the language in future.

-- 
Adam

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

Watson Bug ID:	3600334

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

I second that! Very annoying rule!
Vote by External U.
14855 | July 24, 2013 04:50:04 AM GMT
Throwing this error is better in my opinion as it is saving the developer here from making silly mistakes. Compile time checks are meant to save you from these silly mistakes.
Comment by Rupesh K.
14851 | September 05, 2013 02:03:41 AM GMT
Oh, I know why you've made it work the way it does, but I think you miss the point of what I'm saying... there is simply no reason to have this restriction: it's a completely artificial/contrived restriction, and it's not uniformly policed. Having it prohibited at compile time, but actually fine at runtime is just slack-arseness. Don't create rules for the sake of it. There's nothing wrong with having a local variable with the same name as an argument, so stop having a rule that suggests there IS something wrong with it. Also don't second-guess (ie: deciding one would do this only because of a "silly mistake") why people write code. CFML has a very bad track record at second-guessing things. Stick to what you're good at. -- Adam
Comment by External U.
14852 | September 12, 2013 07:44:39 AM GMT
If they are meant to save you then why does ColdFusion make is hard? For example var myVariable = "test"; is the same as local.myVariable = "test" So if I do function(myVriable) { local.myVariable = "test"; } The code works as expected, yet if we do this function(myVriable) { var myVariable = "test"; } The compiler will crack it.... I don't care what you say Rupesh, you are not a ColdFusion developer who uses this day in day out. The inconsistencies of something like this is just plain wrong. When setting any variable with the var keyword, it should work identical to each other and of course the local scope is the one that is correctly functioning. Adobe is loosing more and more developers, maybe we should be culling the ColdFusion engineering team for half baked options in ColdFusion. Like this ticket, should have been fixed and not closed with not a bug. It is a bug, and it should be fixed.
Comment by External U.
14853 | October 09, 2013 07:12:41 PM GMT
The arguments scope and local scope are two separate scopes. There's no reason why a developer shouldn't be able to have local.foo and arguments.foo.
Vote by External U.
14856 | April 26, 2016 09:35:44 AM GMT
The arguments scope and local scope are two separate scopes. There's no reason why a developer shouldn't be able to have local.foo and arguments.foo. Why would that be a "silly mistake" any more than having a form.foo and url.foo variable??
Comment by External U.
14854 | April 26, 2016 09:36:29 AM GMT
Agree. This has bitten me recently, and for no good reason. Please fix!
Vote by External U.
14857 | April 26, 2016 10:58:18 PM GMT
+1 - function-local variables were never implemented logically from start. Unscoped variables in a function should've defaulted to function-local by default and should, of course, not conflict w/ arguments-scoped variables of the same name.
Vote by External U.
14858 | April 29, 2016 12:33:48 PM GMT