tracker issue : CF-3941602

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

invokeImplicitAccessor should be a CFC setting, not an Application.cfc setting

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

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

Created: 02/17/2015

Components: Language

Versions: 11.0

Failure Type: Usability Issue

Found In Build/Fixed In Build: CF11_Final / latest build

Priority/Frequency: Minor / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 5

Listed in the version 2016.0.0.297996 Issues Fixed doc
Verification notes: verified_fixed on August 24, 2019 using build 2016.0.01.298513
SSIA, really.

This functionality is specifically related to CFCs, and only makes sense if implemented on a CFC-by CFC basis.

Indeed, the setting shouldn't be necessary at all! This should just work:

// General.cfc
component {
	property x;

	function getX(){
		return x;

	function setX(x){
		variables.x = arguments.x;

// general.cfm
o = new General();
o.x = "value"; // calls setX()
writeOutput("Value from o.x: #o.x#<br>"); // calls getX()

It shouldn't *need* a setting for this to work. It should just work!

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

Watson Bug ID:	3941602

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



NB: Raised as a bug because this should never have been implemented this way from the outset.
Comment by External U.
8364 | February 17, 2015 11:38:35 PM GMT
Also raised for Lucee:
Comment by External U.
8365 | February 17, 2015 11:39:59 PM GMT
Vote by External U.
8380 | February 23, 2015 12:04:07 PM GMT
+1 - invokeImplicitAccessor should also be a CFC setting
Vote by External U.
8381 | August 12, 2015 01:28:58 PM GMT
Hi Adam, I, personally, would be fine w/ invokeImplicitAccessor defaulting to true (i.e. "value" going into the variables scope, via the setter, instead of going into the this scope). Thanks!, -Aaron
Comment by External U.
8366 | August 12, 2015 01:46:41 PM GMT
Looks to be an overkill to provide these setting at CFC level.
Comment by Awdhesh K.
8367 | August 18, 2015 07:28:33 AM GMT
I think you couldn't possibly be more wrong if you tried, Awdhesh. It is *innately* something that is class-by-class-specific, not global to an application. But I'd love to hear your reasoning here, in case I've missed something. Rather than your dismissive comment, and flagging the ticket "never fix". You need to *engage your clients* Awdhesh.
Comment by External U.
8368 | August 18, 2015 07:37:21 AM GMT
NB: Lucee's changed bugbase, so that link should be
Comment by External U.
8369 | August 18, 2015 07:37:37 AM GMT
+1, can't think of any reason why it can't be on a case-by-case (or cfc-by-cfc) basis.
Vote by External U.
8382 | August 18, 2015 08:30:06 AM GMT
A good reason to have this at a CFC level is so frameworks/libraries can leverage the feature without needing to mandate that the developer turn it on for the entire application. Or for that matter,if there is a potential incompatibility, framework/libraries can still work in an application that does have it turned on by overriding the setting.
Comment by External U.
8370 | August 18, 2015 09:38:33 AM GMT
And the other way around too Brad. I might want MY CFCs to use this feature, but it's actually completely wrong for some third-party library I'm also using. Indeed I reckon on the whole it would be appropriate for bean time CFCs, but not for services or any other flavour of CFC. I think Awdhesh is just demonstrating he's not... a CFML developer, and is not used to working with CFML code. So he should perhaps not be making these decisions.
Comment by External U.
8371 | August 18, 2015 09:45:55 AM GMT
+1. Agree that one should be able to set this on a class-by-class (CFC-by-CFC) basis.
Vote by External U.
8383 | August 19, 2015 12:26:44 AM GMT
I notice this is marked as fixed?
Comment by External U.
8372 | September 23, 2015 04:33:27 AM GMT
The functionality is fixed, but the docs have not been updated. This needs to be an integral part of any work done to the language. Also, what would have been professional from Awdhesh would have been to follow up the ticket properly, rather than just "going dark". Please reopen the ticket and do the work properly & thoroughly. That said: thanks for actually implementing the functionality.
Comment by Adam C.
8373 | March 14, 2017 09:57:24 AM GMT
I'm also glad to see this fixed :) But, yeah, agreeing w/ Adam: This ticket isn't completely fixed until the docs are updated. And, of course, "going dark" helps ensure tickets aren't properly hashed-out before being implemented (leading to future tickets, backward-compat issues, etc, etc.). Thanks!, -Aaron
Comment by Aaron N.
8374 | March 14, 2017 09:46:28 PM GMT
We need to document this , hence sending it to Saurav.
Comment by Suchika S.
8375 | March 16, 2017 10:44:31 AM GMT
Comment by Saurav G.
8376 | April 03, 2017 06:13:06 AM GMT
Comment by Saurav G.
8377 | May 08, 2017 12:52:07 PM GMT Link to the doc. We forgot to change the visibility of the comment !
Comment by Saurav G.
8378 | May 09, 2017 06:35:19 AM GMT
Ref for the public docs: (Adobe you should have done this yerselves... there's no point sharing a private draft link with us)
Comment by Adam C.
8379 | May 09, 2017 07:09: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.
31185 | August 24, 2019 09:36:19 AM GMT