class Chicken {
@Operator
This set(Obj key, Obj? val) {
return this
}
Void main() {
c := Chicken()
c["chi"] = "ken" // <-- Compilation Error!
}
}
I get a compilation error when I try to use the Set shortcut. Am I missing something?
brianWed 3 Jul 2013
This might be unintentional, but it appears that you are required to have a get operator in order to have a set operator. If you add this line it should work:
@Operator Obj? get(Obj key) { null}
SlimerDudeWed 3 Jul 2013
Cool. The good news is that I'm allowed to make the get() private.
Can't think why I should be coerced into providing a getter. Ticket? :)
SlimerDudeSat 10 Aug 2013
I just (re) came across a fix for this in my code - should this not be a ticket?
It may be unusual to provide a setter and not a getter, but I don't see why you should be forced into providing both.
brianTue 13 Aug 2013
I actually do think you should have to define a get when you have a set. Its sort of like having a write-only field. Just seems inherently wrong. But I'd like to hear if anyone else cares one way or the other? Either way I guess I should make the error message more intuitive.
SlimerDudeFri 4 Apr 2014
Just to say that this, um, feature has caught me out once again.
Not because I wanted a write-only field(*), but because I wrote test for the setter and implemented it before I thought about the getter. And obviously the setter test wouldn't compile because I hadn't yet written the getter! :(
(*) I still don't see what's wrong with a write-only field. Surely the fact that it has a name, write-only field, means it's an accepted programming paradigm!?
SlimerDude Wed 3 Jul 2013
Given the class below:
I get a compilation error when I try to use the
Set
shortcut. Am I missing something?brian Wed 3 Jul 2013
This might be unintentional, but it appears that you are required to have a get operator in order to have a set operator. If you add this line it should work:
SlimerDude Wed 3 Jul 2013
Cool. The good news is that I'm allowed to make the
get()
private.Can't think why I should be coerced into providing a getter. Ticket? :)
SlimerDude Sat 10 Aug 2013
I just (re) came across a fix for this in my code - should this not be a ticket?
It may be unusual to provide a setter and not a getter, but I don't see why you should be forced into providing both.
brian Tue 13 Aug 2013
I actually do think you should have to define a get when you have a set. Its sort of like having a write-only field. Just seems inherently wrong. But I'd like to hear if anyone else cares one way or the other? Either way I guess I should make the error message more intuitive.
SlimerDude Fri 4 Apr 2014
Just to say that this, um, feature has caught me out once again.
Not because I wanted a write-only field(*), but because I wrote test for the setter and implemented it before I thought about the getter. And obviously the setter test wouldn't compile because I hadn't yet written the getter! :(
(*) I still don't see what's wrong with a write-only field. Surely the fact that it has a name,
write-only field
, means it's an accepted programming paradigm!?