tracker issue : CF-3036963

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

Bug 73978:(Watson Migration Closure)One of the biggest sources of confusion and err for developers transitioning from introductory ColdFusion into CFC-driven application development is scope ambiguity

| View in Tracker

Status/Resolution/Reason: Closed/Deferred/

Reporter/Name(from Bugbase): David McGuigan / David McGuigan (David McGuigan)

Created: 12/03/2008

Components: Language

Versions: 9.0

Failure Type: Unspecified

Found In Build/Fixed In Build: 0000 /

Priority/Frequency: Normal / Unknown

Locale/System: English / Win All

Vote Count: 6

Problem:

One of the biggest sources of confusion and err for developers transitioning from introductory ColdFusion into CFC-driven application development is scope ambiguity. I see it all day long and there are countless community blogs about it.

Summary:
A CFC’s variables scope is its private internal storage.
A CFC’s "this" scope is its publicly-accessible internal storage.
A CFC function’s local scope is its temporary, per-function-call, private internal storage.

Since we’re already introducing the new local. syntax, it’s an opportune time to introduce more self-describing and appropriate "variables" and "this" scope syntax for CFCs.

New

<cfset public.variable = value /> ( equivalent of this.variable )

and

<cfset private.variable = value /> ( equivalent of variables.variable )

syntax would be a strong improvement to the current CFC implementation. It should become the recommended practice ( and would likely be adopted immediately ) and can easily co-exist with the current syntax ( which becomes deprecated ).

This would solve a lot of problems and is completely consistent with local. and the access conventions of cffunction definitions, as well as providing a 10 second learning curve.
Method:


Result:

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

Watson Bug ID:	3036963

External Customer Info:
External Company:  
External Customer Name: David McGuigan
External Customer Email: 5E0D54C04462BF5E992016B6
External Test Config: 12/03/2008

Attachments:

Comments:

This would have been a good conversation to have back when CFCs were being first implemented in the CFMX6.0 alpha, but I think it's a bit late now. I agree that the existing naming is poor, but implementing this would cause more confusion than it would solve. -1 vote. -- Adam
Vote by External U.
24495 | November 10, 2011 07:05:14 PM GMT
+1 this sounds like a good change to make the language clearer in the longer term
Vote by External U.
24496 | November 10, 2011 07:05:14 PM GMT
All this will do is make something that is already confusing even more confusing.
Vote by External U.
24497 | November 10, 2011 07:05:16 PM GMT
-10,000 That the scopes could have had better names in the first place isn't at issue... it's how people learn about CFCs and whether or not they've already seen wide adoption. Changing things now would do no good and would introduce mass confusion as people mix and match old and new syntax, read the blogs and articles and wonder "is this the old or new way?" and would, in general, reduce conversion of people over to CFCs by making the whole process that much more confusing.
Vote by External U.
24498 | November 10, 2011 07:05:17 PM GMT
I'm STRONGLY AGAINST this change. There are five years of blog posts and articles (and books) out there explaining how THIS and VARIABLES scope work. This is a senseless and unnecessary change.
Vote by External U.
24499 | November 10, 2011 07:05:18 PM GMT
This bug has been voted..
Vote by External U.
24500 | November 10, 2011 07:05:20 PM GMT