I like them camelCase.
> On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution > <[email protected]> wrote: > > >> On May 18, 2016, at 2:56 PM, Krystof Vasa <[email protected]> wrote: >> >> Not to mention @NSApplicationMain, @NSManaged, ... >> >> I'd personally keep it camelCase. > > Those are sourced external to Swift. > >>> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution >>> <[email protected]> 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 <[email protected]> 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 >>>> Sean >>>> >>>> >>>>> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution >>>>> <[email protected]> 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 >>>>>> <[email protected]>: >>>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
