Quoting Kotlin documentation on 'Backing properties'.
A backing field will be generated for a property if it uses the default implementation of at least one of the accessors, or if a custom accessor references it through the field identifier.
For example, there would be no backing field in the following case:
val isEmpty: Boolean
get() = this.size == 0
At least one of the accessors (setter) is using the default implementation, then why would there be no backing field in the above case?
At least one of the accessors (setter) is using the default implementation
The example property is a val, so there is no setter. The only accessor is the getter, and that one doesn't use the default implementation, so no backing field.
I agree it would have been clearer if they started with a var example, but this example is definitely worth noting to clarify how it works for vals.
Related
This question already has answers here:
In kotlin, how to make the setter of properties in primary constructor private?
(2 answers)
Closed 3 years ago.
class kotlass(var propOne:String, var propTwo:String) {...}
So this is the concise way of declaring properties in Kotlin. I want to change setters (default implementation) to private. Is this possible without giving away the concise syntax?
You can use the val keyword instead of var. val stands for value, and means the property will be immutable and only a getter will be generated (var stants for variable and generates both a getter and a setter).
See also the official reference:
Much the same way as regular properties, the properties declared in the primary constructor can be mutable (var) or read-only (val).
This doesn't strictly "change the setter to private". It actually causes the property to be immutable. If you want the variable to be mutable internally, then no, there is no way to do that using only the default constructor. You would have to use methods described in Kotlin : Public get private set var.
How would you return an object from a method, so it is read-only for the caller?
Please note that this isn't a property that can be simply set to read-only when it's getter is declared
i.e #property(nonatomic,retain,readonly) NSDate* pub_date;
For example:
-(SomeClass*)getObject
{
SomeClass* object = [[SomeClass alloc] init];
//Don't allow writing to 'object'
return object;
}
Thanks.
Short answer: there's no simple way of doing this.
Longer answer: Apple's framework defines a sort of standard for its collection classes where the immutable collection is the base class and the mutable collection is the inheriting class. So, for example, NSMutableArray inherits from NSArray. You can follow that standard, and have methods that return MyClass to clients while using MyMutableClass inside them. Technically the client can still send the mutating messages, of course, but IMHO that's not a big risk (after all, the client doesn't know your implementation details).
There are other, more complicated options - you can use pointer swizzling, or subclass and override all mutating methods, or simply copy the mutable class into an immutable counterpart (that's not complicated but may incur a performance hit). But for best results you should probably follow Apple's example.
It depends what the object is. If it has a mutable / immutable pair (like NSString/ NSMutableString) then your getter method can return the immutable version.
Otherwise, you can't control the behaviour of other objects - once you've returned an object, there is no control over it from the object that originally provided it.
If you are concerned that another object may alter an object returned from a getter, and thereby amend the property held within the original object, then you should return a copy of the object instead.
Example:
Object A has a mutable string property, object B asks for this mutable string, the getter directly returns the instance variable backing the property.
Object B then changes the string - the property of object A has also been amended because both objects have a pointer to the same mutable string.
In this case, you would return a copy of the object rather than the object itself. If your object is a custom one, you must implement the NSCopying protocol to allow this.
A further note - declaring a property as read only simply means that no setter accessor will be generated - i.e. objectA.property = newValue; will result in a compiler error.
So, I've already read up on the documentation which notes
Objective-C 2.0’s dot syntax and key-value coding are orthogonal technologies. You can use key-value coding whether or not you use the dot syntax, and you can use the dot syntax whether or not you use KVC. Both, though, make use of a “dot syntax.” In the case of key-value coding, the syntax is used to delimit elements in a key path. It is important to remember that when you access a property using the dot syntax, you invoke the receiver’s standard accessor methods.
It then provided an example that supposedly showed the difference between the two. However, I still don't get, what's the difference between KVC and property accessor methods? Aren't they the same? And how do I distinguish between dots that call setValue:forKeyPath: and simple accessors?
However, I still don't get, what's the difference between KVC and property accessor methods?
KVC is a way to call property accessor methods, or otherwise access a property.
What do I mean by “otherwise access”? For KVC purposes, an instance variable with no accessor methods counts as an informal property. It'll get or set the value of the instance variable directly if no matching accessor pair can be found. (Yes, this is not worth using in modern code. Always declare an #property for anything you intend to access elsewhere, and, inversely, don't use KVC to access anything that isn't a public property.)
Property accessor methods are what KVC will call if they exist (preferred, both by KVC and by every sane programmer, over direct ivar access). An accessor may get or set an instance variable, as synthesized accessors do, or access some other storage.
Accessors are implementation, properties are interface, and KVC is one way to use them.
And how do I distinguish between dots that call setValue:forKeyPath: and simple accessors?
A key path is a string, whereas a property-access expression is an expression. The compiler evaluates a property-access expression and translates it into one or more Objective-C messages, whereas a key path is evaluated by KVC at run time.
So, when you use a key path:
[someObject setValue:theValue forKeyPath:#"foo.bar.baz"];
You know it's a key path because (1) it's a string, as indicated in this case by the string-literal syntax #"…", and (2) you're passing the key-path string to setValue:forKeyPath: for it to evaluate.
Using a key path is using KVC to access the named properties. It will send any relevant accessor messages on your behalf.
When you use a property-access expression:
someObject.foo.bar.baz = theValue;
You know it's a property access expression because you are not identifying the properties with a string. You are accessing them (sending the accessor messages) yourself, in your own code.
There isn't much reason to use KVC in any form; when you know the property at authorship/compile time, it's best to have an #property declared and to access the property yourself, whether with property-access expressions or message expressions ([[[someObject foo] bar] setBaz:theValue]). The time to use KVC is when you don't know what property you want to access until run time, which is pretty rare. It's mainly a building-block technology behind KVO, Cocoa Bindings, parts of Core Animation, etc.
Mostly, you'll only want to access properties yourself.
Key value coding allows you to set and get the value of properties through code using the string name of the property. For example, if I had a property named foo which is of type NSString:
[self setValue:#"mystring" forKey:#"foo"];
// read the value by key
NSString *s = [self valueForKey:#"foo"];
Dot syntax is compile syntax sugar. As a personal preference (as some don't agree - fine) I don't use dot syntax but I still use KVC:
[myObj setFoo: #"someString"]
equals:
myObj.foo = #"someString";
They are orthogonal, different concepts but both dealing with how you interact with properties
Finally, you mention property syntax. Yet another orthogonal concept but related to dealing with properties.
With objective-c, convention is important. Follow them. Properties are the name of the property for the get and set[Name] for the assignment:
- (NSString*)foo
{
return _foo; // defined as (NSString*)_foo in header
}
- (void) setFoo: (NSString*)foo
{
if (foo == _foo)
return;
NSString* curr = _foo;
_foo = [foo retain];
[curr release];
}
Now, who wants to write something like that every time. So, enter #property syntax:
In header:
#property (retain) NSString *foo;
Then in .m:
#synthesize foo;
That's the equivalent of the hand written property accessors. It's compiler syntax sugar which expands the property code based on how you attribute the properties.
Docs:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html
In my quest to update a Core Data model within my iOS project, I'm querying a server for JSON objects that correspond - to some extent - with the managed entities of my model. The end result I'm striving for is a reliable update solution from JSON output.
For the examples in this question, I'll name the core data managed object existingObj and the incoming JSON deserialized dictionary updateDict. The tricky part is dealing with these facts:
Not all properties of the existingObj are present in the updateDict
Not all properties of the updateDict are available in the extistingObj.
Not all types of existingObj's properties match the JSON deserialized properties. (some strings may need a custom Objective-C wrapper).
updateDict may contain values for keys that are uninitialized (nil) in existingObj.
This means that while iterating through the updated dictionaries, there has to be some testing of properties back and forth. First I have to test whether the properties of the updateDict exist in existingObj, then I set the value using KVC, like so:
// key is an NSString, e.g. #"displayName"
if ([existingObj respondsToSelector:NSSelectorFromString(key)) {
[existingObj setValue:[updateDict objectForKey:key] forKey:key];
}
Although this part works, I don't like the fact that I'm actually testing for displayName as a getter, while I'm about to call the setDisplayName: setter (indirectly via KVC). What I'd rather to is something like [existingObj hasWritablePropertyWithName:key], but something that does this I can't find.
This makes for subquestion A: How does one test for a property setter, if you only have the property's name?
The next part is where I'd like to automate the property identification based on their types. If both the updateDict and the existingObj have an NSString for key #"displayName", setting the new value is easy. However, if the updateDict contains an NSString for key #"color" that is #"niceShadeOfGreen", I'd like to transform this into the right UIColor instance. But how do I test the type of the receiving property in existingObj so I know when to convert values and when to simply assign? I was hoping for something along the lines of typeOfSelector:
if ([existingObj typeOfSelector:sel] == [[updateDict objectForKey:key] class]) {
// regular assignment
} else {
// perform custom assignment
}
Of course this is boguscode. I can't rely on testing the type of the existingObj-property's value, for it may be unitialized or nil.
Subquestion B: How does one test for the type of a property, if you only have the property's name?
I guess that's it. I figured this must be a dupe of something that's already on here, but I couldn't find it. Maybe you guys can?
Cheers, EP.
P.S. If you'd have a better way to synchronize custom Objective-C objects to deserialized JSON objects, please do share! In the end, the result is what counts.
If you want to query whether an object has a setter for a given KVC key called key which corresponds to a declared property, you need to check whether it responds to a selector method called setKey: (starts with set, capitalise the first character in key, add a trailing colon). For instance,
NSString *key = #"displayName";
NSString *setterStr = [NSString stringWithFormat:#"set%#%#:",
[[key substringToIndex:1] capitalizedString],
[key substringFromIndex:1]];
if ([obj respondsToSelector:NSSelectorFromString(setterStr)]) {
NSLog(#"found the setter!");
[obj setValue:someValue forKey:key];
}
Two remarks:
Even though properties can have setters with names that do not follow the pattern described above, they wouldn’t be KVC compliant, so it is safe to check for set<Key>: since you’re using KVC to set the corresponding value.
KVC doesn’t use the setter method only. If it doesn’t find a setter method, it checks whether the class allows direct access to instance variables and, if so, use the instance variable to set the value. Also, if no setter method or instance variable is found, it sends -setValue:forUndefinedKey: to the receiver, whose class might have overridden the standard implementation that throws an exception. This is described in the Key-Value Coding Programming Guide.That said, if you’re always using properties, checking for the setter method should be safe.
As for your second question, it is not possible to query the runtime to know the actual Objective-C class of a property. From the runtime perspective, there’s an implementation specific type encoding for properties and general types (such as method parameters/return types). This type encoding uses a single encoding (namely #) for any Objective-C object, so the type encoding of an NSString property is the same as the type encoding of a UIColor property since they’re both Objective-C classes.
If you do need this functionality, one alternative is to process your classes and add a class method that returns a dictionary with keys and corresponding types for every property (or the ones you’re interested in) declared in that class and superclasses, or maybe some sort of description language. You’d have to do this on your own and rely on information not available during runtime.
Should one use under any circumstances getters-setters of a class within the class?
Getters setters are generally used from outside class from inside directly access the fields.
The main advantage/purpose is encapsulation of getter setters,
If your getters setters has some logical code then use it.
for example :
public void setValue(int val){
if(val > 100)
this.val = 0;
else
this.val = val;
}
Also see
why-use-getters-and-setters
More on getters and setters
Yes, getters and setters are useful. Because PHP doesn't support type hinting for simple types like int or string, you cannot force a value to be of the right type.
By using a setter, you always have the possibility to check the value that is set. When a value set to an int property isn't an int, you can choose to typecast it, or raise an error, instead of just accepting the wrong value.
That will make debugging and maintaining your application a lot easier. So it's a good idea to use getters and setters, even if they do not contain much logic other than these checks.
#GolezTrol
There is no PHP badge on topic and you are wrong. What you are describing has nothing to do with setters. You can force type on parameter (in PHP) by using any method not only a setter.
You can write:
setX( X $x ){ ...}
setY( Y $y ){ ...}
or just:
iAmMethodNotASetter( X $x, Y $y){
//20lines of code here end then:
$this->x = $x;
$this->y = $y;
}
Like you see I didn't need setters to enforce type in object properties.
And throwing error in setter after checking variable type is bad idea anyway. It is common error of programmers who transitioned from the language statically typed to dynamically type language.
Setters and geters are CONVENTION and they don't enforce anything!
Today we usually use them for creation of Plain Old Java Objects. (POJO - in php word POPO) So it is just a convetion (standard) for creation of object that can by use between libraries or projects.
You can combine setters with type checking or whatever but it dosn't make them somthing more than they are.
About Encapsulation:
#org.life.java - Jigar Joshi
"The main advantage/purpose is
encapsulation of getter setters, "
#Peter Alexander
"You're supposed to use the getters
and setter almost everywhere,
including inside "the class. If you
don't, then you are potentially
breaking encapsulation" "Getters and
setters are encapsulation"
Wrong, wrong, wrong. Encapsulation has nothing to do with getters and setters and it is very common mistake. I know there is many articles repeated it over and over all upside down...
Getters and setters don't help encapsulation even worse, they may break encapsulation. They do so when you use them to get some data from object instead of asking object to do something for you with its own data.
Encapsulation == object is taking full responsibility for its data and dosn't give it's row data. And getter on private property is nothig more than making that property public in complicated fashion == braking encapsulation.
Chceck paragraph encapsulation: http://en.wikipedia.org/wiki/C%2B%2B or http://en.wikipedia.org/wiki/Encapsulation_%28computer_science%29
Not even one word about setters or getters...
You're supposed to use the getters and setter almost everywhere, including inside the class. If you don't, then you are potentially breaking encapsulation, and even worse, you could invalidate your invariants.
As a simple example in C++:
class BankAccount
{
public:
void withdraw(int amount)
{
m_balance -= amount;
m_withdrawals++;
}
void transfer(BankAcount& other, int amount)
{
m_balance -= amount;
other.m_balance += amount;
}
private:
int m_balance;
int m_withdrawals;
};
See the bug? transfer withdraws money, but it doesn't increment m_withdrawals. This could have been avoided if it simply called withdraw rather than manually decrementing the balance.
The same applies to getters and setters. For example, its quite common to have getters that lazily initialise their values. If another member function tries to access the uninitialised member directly then you're going to get a null pointer dereference.
Essentially, you should always try to use the getters and setters whenever they provide the functionality they want. The more low level things you do, the more low level bugs you are going to have. There's no point writing getters and setters if you aren't going to use them.