didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
I don't think we shouldn't touch these until we know what accessors on property behaviors are going to look like. We could very well change these now and then change them back in the next version; that kind of bouncing back and forth is maddening for users. Better leave them alone for now and change them later if we decide to, than change them in Swift 3 and then have a high probability of changing them back in Swift 4.
···
--
Brent Royal-Gordon
Architechies
+1 to consistency!
···
On Wed, May 18, 2016 at 10:10 Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:
didSet and willSet remain outliers in the general rule of conjoined
lowercase keywords. Is there any support for bringing these outliers into
the fold?-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
I would rather like to see them disappear completely — although those "decorators" [is there any established term to describe them?] can be quite handy, they add a lot of special syntax to the language...
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):
public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}
I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}
That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
···
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Not really sure, Like the way the camel case ones look. I’m not sure I understand why keywords are lowercase? To reduce clashes with variables?
···
On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Agreed. Personally I prefer willSet and didSet, but consistency of rules is higher priority. +1.
···
On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions.
`typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be `associatedtype`, `associatedType`, or `associated_type`. There are also a number of attributes like `@noescape` and `@discardableResult`, which aren't 100% consistent.
···
--
Brent Royal-Gordon
Architechies
Just some context:
"We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers"
and
"On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well."
-- E
···
On May 18, 2016, at 2:50 PM, Sean Heber <sean@fifthace.com> wrote:
+1 on not getting rid of willSet and didSet for sure!
As for naming, it doesn’t bother me much either way, but I think lowercase makes sense with the direction everything else is going.
l8r
SeanOn May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
+1 on not getting rid of willSet and didSet for sure!
As for naming, it doesn’t bother me much either way, but I think lowercase makes sense with the direction everything else is going.
l8r
Sean
···
On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
I don't think we shouldn't touch these until we know what accessors on property behaviors are going to look like. We could very well change these now and then change them back in the next version; that kind of bouncing back and forth is maddening for users. Better leave them alone for now and change them later if we decide to, than change them in Swift 3 and then have a high probability of changing them back in Swift 4.
I generally agree, but is that an option? Changing `didSet` to `didset` is a breaking change. Or are you arguing that this is a special case as it is already going to change when property behaviors are introduced?
I wish we had a clearer sense of how breaking changes will be evaluated in future versions of Swift.
···
On May 18, 2016, at 3:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions.`typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be `associatedtype`, `associatedType`, or `associated_type`. There are also a number of attributes like `@noescape` and `@discardableResult`, which aren't 100% consistent.
Yeah, some of these changes which may feel like low hanging fruit to some turn out to take a lot of energy.
If we’re going to pursue more of these kinds of changes, I would prefer a comprehensive proposal that evaluates everything, establishes well defined conventions, and then applies the changes holistically.
···
On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions. I would agree best to change these keywords for others
consisting of only one word but I myself have no suggestion what those
could be. Otherwise I'd rather keep them as-is.
···
On 18 May 2016 at 17:38, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Matthew's right. The first thing here is to define a consistent rule
which takes no exceptions and then apply this rule to every existing
or new keyword and attribute.
···
On 18 May 2016 at 18:02, Matthew Johnson <matthew@anandabits.com> wrote:
On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions.`typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be `associatedtype`, `associatedType`, or `associated_type`. There are also a number of attributes like `@noescape` and `@discardableResult`, which aren't 100% consistent.
Yeah, some of these changes which may feel like low hanging fruit to some turn out to take a lot of energy.
If we’re going to pursue more of these kinds of changes, I would prefer a comprehensive proposal that evaluates everything, establishes well defined conventions, and then applies the changes holistically.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Not to mention @NSApplicationMain, @NSManaged, ...
I'd personally keep it camelCase.
···
On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Just some context:
"We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers"
and
"On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well."
-- E
On May 18, 2016, at 2:50 PM, Sean Heber <sean@fifthace.com> wrote:
+1 on not getting rid of willSet and didSet for sure!
As for naming, it doesn’t bother me much either way, but I think lowercase makes sense with the direction everything else is going.
l8r
SeanOn May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Yeah I agree completely with this. They may be camel case with property behaviours, so best to keep them as is for now.
···
On 19 May 2016, at 6:53 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
I don't think we shouldn't touch these until we know what accessors on property behaviors are going to look like. We could very well change these now and then change them back in the next version; that kind of bouncing back and forth is maddening for users. Better leave them alone for now and change them later if we decide to, than change them in Swift 3 and then have a high probability of changing them back in Swift 4.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Because some posts explicitly stated the willSet/didSet-functionality should be kept (and I mentioned the option of discarding them):
My statement had the same background as Brent's — I expect there will be a "cleaner" and more versatile replacement in the future, so "don't fix it if it isn't broken, and will be replaced soon anyways" ;-)
I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words,
dynamicType, associatedtype, typealias, privatefile
so I believe these should be
exceptions. I would agree best to change these keywords for others
consisting of only one word but I myself have no suggestion what those
could be. Otherwise I'd rather keep them as-is.
At some point (I think it was during the bike shedding for associatedtype), somebody declared that camel case for keywords is abhorrent and everybody accepted it without question. Looking back on it, I think that was a mistake. The point of camel case is to help resolve the individual words in an identifier. I don’t see why that shouldn’t also apply to keywords, especially as, in the list above, Apple Mail kept inserting spaces into the ones that weren’t in camel case, which is really annoying.
A better convention might be to put keywords in ALL CAPS like in Algol. << Ducks >>
···
On 18 May 2016, at 21:51, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:
On 18 May 2016 at 17:38, Michael Peternell via swift-evolution > <swift-evolution@swift.org> wrote:
Hi Erica,
"didset" and "willset" are outliers in the general rule that when combining multiple words into an identifier, that you should use camelCase. which rule is more important? I'd like to introduce a third rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep it the way it is. or another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
=> I vote for "didSet" and "willSet".
I think we should be more careful when trying to argue with "consistency". It sounds objective, when in reality it's often very subjective, because Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If you are saying that something is inconsistent, you either assert a specific rule of consistency (like "keywords are always lowercase"), or you must argue that there is no general/sane rule under which the individual parts of the system are consistent.
And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, from code in my bachelors thesis (it's about polygons):public var points: Array<CGPoint> = {
didSet {
_area = nil
_centroid = nil
}
}I want to cache the _area and _centroid of a polygon, because I'm going to use it many many times more often than I change points. I would have to rewrite that code to something like
private var _points: Array<CGPoint> =
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}That's not better, and it probably breaks the COW-optimization of the underlying array. (And don't tell me that my design is bad because I use "didSet", I really don't think so.)
-Michael
Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:
didSet and willSet remain outliers in the general rule of conjoined lowercase keywords. Is there any support for bringing these outliers into the fold?
-- E, going through her "ttd notes" this morning
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Just some context:
"We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers”
Hmm, that’s kind of spurious isn’t it? Camel case has nothing to do with whether the concept referred to is atomic but whether the label for it is composed of multiple words.
If you came across the following
let databaseTransaction = database.beginTransaction()
you wouldn’t change the T's to lower case on the grounds that database transactions are atomic.
···
On 18 May 2016, at 21:53, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
and
FWIW, I still agree with the logic you quote. These seem like they should be lowercase to me.
Although it is not literally the case, programmers will treat them effectively as though they are keywords in the language, and that is what matters. When we introduce property behaviors, the surface level syntax for this sort of thing is likely to remain the same, and it therefore stands to reason that the behavior “accessors” would follow the same convention as keywords.
-Chris
···
On May 18, 2016, at 1:53 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Just some context:
"We have a few conjoined keywords already (typealias, associatedtype, fallthrough). In the discussion about these terms, we decided that these read best when all lowercase, because they are treated as atomic concepts by programmers"
and
"On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well.”