I've encountered an odd bug where Apex code was assigning a value to a static property without a setter defined.
Below is a simplified version of the code:
@isTest
public class PropertySettingTest {
public static boolean testBooleanProp {
get {
return false;
}
}
static testMethod void setPropertyUnitTest() {
System.assert(!testBooleanProp);
testBooleanProp = true;
System.assert(!testBooleanProp);
System.debug(testBooleanProp);
}
}
When assigning the property I'd expect to get an error when saving/compiling like:
Save error: Variable is not visible: testBooleanProp
However, is saves and runs. The property assignment has no affect.
I did another test, and if the property isn't static the code fails to save/compile as expected.
Am I missing something or is this a bug? I'd like some confirmation before raising a support case.
Attribution to: Daniel Ballinger
Possible Suggestion/Solution #1
I just wanted to add my research: the behavior of static properties is still all screwy. Josh Kaplan said this would be addressed in Spring '13 but I am still seeing lots of problems in Spring '14. I have tried updating my class to API version 30 and it makes no difference.
Here are some varying tests for both instance and static properties, how they behave, and how I think they should behave:
Instance:
// Instance properties:
public String foo { get; } // Pubilc read-only; Private read-only
public String foo { private get; } // Public inaccessible; Private read-only
public String foo { get; set; } // Public read-write
public String foo { get; private set; } // Public read-only; Private read-write
public String foo { private get; private set; } // Public inaccessible; Private read-write
public String foo { private set; } // Compile error: unexpected token: set (should be private write-only?) [granted, this is a strange, useless case]
public String foo { set; } // Public write-only; Private INACCESSIBLE (should be write-only?) [granted, this is a strange, useless case]
// Instance methods tested
public String fooRead() { return foo; }
public void fooWrite(String value) { foo = value; }
public String fooReadWrite(String value) { foo = value; return foo; }
Static:
// Static properties:
public static String bar { get; } // Public read-WRITE (should be Public read-only)
public static String bar { private get; } // Public inaccessible; Private read-WRITE (should be read-only)
public static String bar { get; set; } // Public read-write
public static String bar { get; private set; } // Public read-WRITE (should be public read-only, private read-write)
public static String bar { private get; private set; } // Public inaccessible; Private read-write
public static String bar { private set; } // Compile error: unexpected token: set (should be private write-only?) [granted, this is a strange, useless case]
public static String bar { set; } // Public INACCESSIBLE; Private INACCESSIBLE (should be public/private read-write) [granted, this is a strange, useless case]
// Static methods:
public static String barRead() { return bar; }
public static void barWrite(String value) { bar = value; }
public static String barReadWrite(String value) { bar = value; return bar; }
I think the issue Peter Knolle found with { set; } applies to both static and instance properties, though it is different in that the instance property can be written to publicly, but not privately while the static property cannot be written to at all.
Attribution to: Kevin Gwynn
Possible Suggestion/Solution #2
According to the Apex code reference on properties a property with only a get accessor is considered read-only. The reference has a section on static properties and it does not state that they behave any differently.
I performed a quick test and added a set and removed the get and I got the error when trying to read the variable. This inconsistency adds to the case that it is an issue.
public static boolean testBooleanProp {
set;
}
static testMethod void setPropertyUnitTest() {
// Causes variable is not visible error due to no get accessor defined.
System.debug(testBooleanProp);
}
I'm with you that this looks like a defect.
Attribution to: Peter Knolle
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/1516