I think camelCase is richer and easier to read.
> On May 20, 2016, at 10:26 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Sent from my iPad > > On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >>> 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. >> >> Yes, but what will the conventions be? Is the accessor for the "did change" >> behavior going to be `didchange` or `didChange`? If I write a JSON behavior, >> is my accessor going to be `toJSON` or `tojson`? >> >> *That*—not some general rule about keywords which is primarily designed to >> address things like `fallthrough` and `associatedtype`—is what I think >> `willSet` and `didSet` ought to match. Users do not care whether something >> comes out of the standard library or the language grammar; they care whether >> it has the feel of other things which fit that syntactic slot. > > +1. Standard library behaviors should use a convention that is appropriate > to recommend for user behaviors as well. > >> >> (For instance, a perhaps controversial opinion: I think `dynamicType` is >> properly capitalized for the syntactic slot it's in. That's not to say I >> think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is >> more appropriate than `foo.dynamictype` would be.) > > +1. 'foo.dynamictype' seems strange to me. > >> >> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, >> accessors. If user-defined accessors are not going to go into that syntactic >> slot, or if they are going to have all-lowercase accessor names, then by all >> means, lowercase `willSet` and `didSet`. But if user-defined accessors are >> going to be mixed-case, then `willSet` and `didSet` should be too. And if we >> aren't sure whether user-defined accessors will be all-lowercase or mixed >> case, then let's not jump the gun and make a change that we're likely to >> reverse later. > > +1. > >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> 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
