Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
I and others fought and lost this particular battle back when the guidelines were being drafted. Just be glad you didn't end up with uppercase rules calling for things like `UrlComponents`.
--
Brent Royal-Gordon
Architechies
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Sent from my iPad
On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
+1.
I don't really like the String.utf8 etc. in the current Swift library either.
On May 19, 2016, at 7:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Hi Brandon,
Thank you for the good question! We humans have been writing and reading software for a long time now. There are some words and keywords which stand out form the rest to mean something **well know** and one of them is acronyms. It is a habit and it works quite great in Cocoa in Objective-C, that is why I would suggest to preserve it for the future generations to come. Have a good day!
Pavel.
On May 19, 2016, at 10:14 AM, Brandon Knope <bknope@me.com> wrote:
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Hi Brent,
Thank you for you encouragement! Please join in to support it **now**!
Cheers,
Pavel.
On May 19, 2016, at 11:53 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
I and others fought and lost this particular battle back when the guidelines were being drafted. Just be glad you didn't end up with uppercase rules calling for things like `UrlComponents`.
--
Brent Royal-Gordon
Architechies
I strongly prefer that things like properties and variables, even if they
start with an acronym or initialism, start lowercase. When writing
Objective-C, if I have a property or variable named just "url", I always
debate whether I should call it "URL" or "url".
This will become even trickier once Foundation classes drop the NS* prefix,
so we'll have a type named URL. In that case, what would you call a
variable of the same time? Either "url", or you come up with a more
contrived name where maybe "url" would have been sufficient.
That's not the only example, but one of my projects is in the business of
generating Swift code, and being able to predictably generate UpperCamel
for types and lowerCamel for properties goes a long way toward avoiding
collisions.
On Thu, May 19, 2016 at 10:15 AM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote:
Do you have a particular reason? I don't think because it is a certain way
in Objective-C means it must be that same way in Swift.Brandon
Sent from my iPad
> On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hi,
>
> SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in
Proposed Solution # 6 "Lowercase values" suggests “to lowercase
non-prefixed values whenever they are imported” with an example of
URLHandler property becoming urlHandler. Being long time Cocoa developer, I
object to this particular example and would like to suggest to keep
capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are
now in Cocoa. Thank you!
>
> Cheers,
> Pavel.
> _______________________________________________
> 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
Aside from ObjC developers being used to this, psychology of reading tells us that people read by shapes of the words - they are used to seeing abbreviations in capital letters - from this point, it's better readable.
On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Sent from my iPad
On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
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
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.
Sent from my iPhone
On May 19, 2016, at 11:56 AM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi Brent,
Thank you for you encouragement! Please join in to support it **now**!
Cheers,
Pavel.On May 19, 2016, at 11:53 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
I and others fought and lost this particular battle back when the guidelines were being drafted. Just be glad you didn't end up with uppercase rules calling for things like `UrlComponents`.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Do you have a source for this? While I bet there is research showing that acronyms on their own are easier to read in all caps, does it talk about when it is joined with other words such as urlHandler?
And like I said, just because ObjC devs are used to it is probably not a good enough rationale to overturn an accepted proposal.
Brandon
Sent from my iPad
On May 19, 2016, at 1:17 PM, Krystof Vasa <kvasa@icloud.com> wrote:
Aside from ObjC developers being used to this, psychology of reading tells us that people read by shapes of the words - they are used to seeing abbreviations in capital letters - from this point, it's better readable.
On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Sent from my iPad
On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
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
Thank you for you encouragement! Please join in to support it **now**!
I wasn't trying to encourage you to fight. Quite the opposite, actually.
In order for swift-evolution to work—to make progress on the language and not suck up infinite time—one of the most important things we, as list members, must do is know when to stop arguing about something, even when we've lost. And the time to argue about this was during the drafting and review of SE-0005. There was ample debate on the list about this specific subject, with many positions represented.
I was on the side that argued for maximally accurate representation of words, including all-caps acronyms even at the beginning of lowercase strings. Others argued that the first word of a non-type should always be lowercase; still others argued that all letters should be lowercase except for the first one after a word boundary, even in an acronym. If we take the example of a "URL handler" property and an "HTML string" type, there were people arguing for `URLHandler` and `HTMLString`, for `urlHandler` and `HTMLString`, for `urlHandler` and `HtmlString`, even for `uRLHandler` and `HTMLString`. And we finally settled on the current convention, `urlHandler` and `HTMLString`, because it was least offensive to everybody: it kept the initial lowercase letter that some people wanted, while also not mixing the case of acronyms and giving a decent indicator of word boundaries.
This all took up a week or two of the list's time, and even though I didn't win the argument, I don't want to reopen it. It's been argued, it's been settled, and we need to move on to other designs. And you know what? `urlHandler` isn't *that* bad. It's not what I would have chosen, but it's something I can live with.
In general, I do not support reopening designs which have already been settled by a formal proposal, review, and core team acceptance, unless the decision is either egregiously bad (I can't think of any examples off the top of my head; perhaps the issues which led to the `form` prefix might qualify) or later experience has shown the design to be worse than previously thought. I will fight a design tooth and nail while it's being proposed and reviewed, but once it's accepted, I put aside my feelings, accept the proposal as part of the language's design, and move on with it. It's the only way we can get anything done here.
Rehashing old decisions like this is just spinning our wheels. There are lots of exciting new things we *haven't* decided—things like multiline string literals, Foundation and Dispatch designs, and a world of syntax clean-ups. Let's focus on those things—things where we can make forward progress, not keep revisiting old arguments.
--
Brent Royal-Gordon
Architechies
I don't remember the exact paper I read, but e.g. on Wikipedia - Word recognition - Wikipedia - but googling for "reading by shapes" etc. turns out a lot of various articles.
But I see it myself - urlHandler - I immediately see Handler, but have to read into it letter by letter to see the "url". When it's URLHandler, I see immediately both.
If you see it in urlHandler, you might be used to it - you of course can learn new words/word combinations.
On May 19, 2016, at 7:31 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a source for this? While I bet there is research showing that acronyms on their own are easier to read in all caps, does it talk about when it is joined with other words such as urlHandler?
And like I said, just because ObjC devs are used to it is probably not a good enough rationale to overturn an accepted proposal.
Brandon
Sent from my iPad
On May 19, 2016, at 1:17 PM, Krystof Vasa <kvasa@icloud.com> wrote:
Aside from ObjC developers being used to this, psychology of reading tells us that people read by shapes of the words - they are used to seeing abbreviations in capital letters - from this point, it's better readable.
On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Sent from my iPad
On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
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
Hi,
Exactly! The reading habits increase comprehension and speed up things. That’s why I applaud here to those who developed Cocoa API over the years keeping it consistent and **easy** and **fast** to read and write. Again, please keep the good and proven things from Cocoa in Objective-C!
Pavel.
On May 19, 2016, at 11:07 AM, Krystof Vasa <kvasa@icloud.com> wrote:
I don't remember the exact paper I read, but e.g. on Wikipedia - Word recognition - Wikipedia - but googling for "reading by shapes" etc. turns out a lot of various articles.
But I see it myself - urlHandler - I immediately see Handler, but have to read into it letter by letter to see the "url". When it's URLHandler, I see immediately both.
If you see it in urlHandler, you might be used to it - you of course can learn new words/word combinations.
On May 19, 2016, at 7:31 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a source for this? While I bet there is research showing that acronyms on their own are easier to read in all caps, does it talk about when it is joined with other words such as urlHandler?
And like I said, just because ObjC devs are used to it is probably not a good enough rationale to overturn an accepted proposal.
Brandon
Sent from my iPad
On May 19, 2016, at 1:17 PM, Krystof Vasa <kvasa@icloud.com> wrote:
Aside from ObjC developers being used to this, psychology of reading tells us that people read by shapes of the words - they are used to seeing abbreviations in capital letters - from this point, it's better readable.
On May 19, 2016, at 7:14 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
Do you have a particular reason? I don't think because it is a certain way in Objective-C means it must be that same way in Swift.
Brandon
Sent from my iPad
On May 19, 2016, at 1:04 PM, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in Proposed Solution # 6 "Lowercase values" suggests “to lowercase non-prefixed values whenever they are imported” with an example of URLHandler property becoming urlHandler. Being long time Cocoa developer, I object to this particular example and would like to suggest to keep capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are now in Cocoa. Thank you!
Cheers,
Pavel.
_______________________________________________
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
Hi Charles,
Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.
On May 19, 2016, at 1:20 PM, charles@charlesism.com <charlesism.com@gmail.com> wrote:
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.
Dear Brent,
I am sorry I touched your feelings here. I am here to state my opinion even if others already made their mind. I have just signed up to the list this morning. I will bring up my point again to be clear - well known acronym capitalization is pervasive in Cocoa APIs and as a result enable fast and easy comprehension and writing good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.
On May 19, 2016, at 1:38 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
Thank you for you encouragement! Please join in to support it **now**!
I wasn't trying to encourage you to fight. Quite the opposite, actually.
In order for swift-evolution to work—to make progress on the language and not suck up infinite time—one of the most important things we, as list members, must do is know when to stop arguing about something, even when we've lost. And the time to argue about this was during the drafting and review of SE-0005. There was ample debate on the list about this specific subject, with many positions represented.
I was on the side that argued for maximally accurate representation of words, including all-caps acronyms even at the beginning of lowercase strings. Others argued that the first word of a non-type should always be lowercase; still others argued that all letters should be lowercase except for the first one after a word boundary, even in an acronym. If we take the example of a "URL handler" property and an "HTML string" type, there were people arguing for `URLHandler` and `HTMLString`, for `urlHandler` and `HTMLString`, for `urlHandler` and `HtmlString`, even for `uRLHandler` and `HTMLString`. And we finally settled on the current convention, `urlHandler` and `HTMLString`, because it was least offensive to everybody: it kept the initial lowercase letter that some people wanted, while also not mixing the case of acronyms and giving a decent indicator of word boundaries.
This all took up a week or two of the list's time, and even though I didn't win the argument, I don't want to reopen it. It's been argued, it's been settled, and we need to move on to other designs. And you know what? `urlHandler` isn't *that* bad. It's not what I would have chosen, but it's something I can live with.
In general, I do not support reopening designs which have already been settled by a formal proposal, review, and core team acceptance, unless the decision is either egregiously bad (I can't think of any examples off the top of my head; perhaps the issues which led to the `form` prefix might qualify) or later experience has shown the design to be worse than previously thought. I will fight a design tooth and nail while it's being proposed and reviewed, but once it's accepted, I put aside my feelings, accept the proposal as part of the language's design, and move on with it. It's the only way we can get anything done here.
Rehashing old decisions like this is just spinning our wheels. There are lots of exciting new things we *haven't* decided—things like multiline string literals, Foundation and Dispatch designs, and a world of syntax clean-ups. Let's focus on those things—things where we can make forward progress, not keep revisiting old arguments.
--
Brent Royal-Gordon
Architechies
Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code.
I could reply "they are confusing because they look like class names and clearly cause a higher number of errors in code."
My *actual* view is that both forms cause problems, so it doesn't much matter which we go with.
Sent from my iPhone
On May 19, 2016, at 1:30 PM, Pavel Kapinos <kapinos@twobytesoftware.com> wrote:
Hi Charles,
Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.On May 19, 2016, at 1:20 PM, charles@charlesism.com <charlesism.com@gmail.com> wrote:
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.
Hi Pavel,
I don’t agree that capitalised acronyms read better for properties and variables. I’m happy that the naming guidelines went the way they did. But that is fairly inconcequential. As Brent puts it better than I ever could, the success of the evolution process is based on making peace with previously accepted proposal, even if you were not personally there when they were debated, and especially as this discussion is not putting forward new evidence or scenarios to further the debate. Many people with similar opinion to yours were there back then to plead your cause.
Anyway, welcome to the swift evolution mailing list!
David.
On 19 May 2016, at 22:45, Pavel Kapinos via swift-evolution <swift-evolution@swift.org> wrote:
Dear Brent,
I am sorry I touched your feelings here. I am here to state my opinion even if others already made their mind. I have just signed up to the list this morning. I will bring up my point again to be clear - well known acronym capitalization is pervasive in Cocoa APIs and as a result enable fast and easy comprehension and writing good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.On May 19, 2016, at 1:38 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
Thank you for you encouragement! Please join in to support it **now**!
I wasn't trying to encourage you to fight. Quite the opposite, actually.
In order for swift-evolution to work—to make progress on the language and not suck up infinite time—one of the most important things we, as list members, must do is know when to stop arguing about something, even when we've lost. And the time to argue about this was during the drafting and review of SE-0005. There was ample debate on the list about this specific subject, with many positions represented.
I was on the side that argued for maximally accurate representation of words, including all-caps acronyms even at the beginning of lowercase strings. Others argued that the first word of a non-type should always be lowercase; still others argued that all letters should be lowercase except for the first one after a word boundary, even in an acronym. If we take the example of a "URL handler" property and an "HTML string" type, there were people arguing for `URLHandler` and `HTMLString`, for `urlHandler` and `HTMLString`, for `urlHandler` and `HtmlString`, even for `uRLHandler` and `HTMLString`. And we finally settled on the current convention, `urlHandler` and `HTMLString`, because it was least offensive to everybody: it kept the initial lowercase letter that some people wanted, while also not mixing the case of acronyms and giving a decent indicator of word boundaries.
This all took up a week or two of the list's time, and even though I didn't win the argument, I don't want to reopen it. It's been argued, it's been settled, and we need to move on to other designs. And you know what? `urlHandler` isn't *that* bad. It's not what I would have chosen, but it's something I can live with.
In general, I do not support reopening designs which have already been settled by a formal proposal, review, and core team acceptance, unless the decision is either egregiously bad (I can't think of any examples off the top of my head; perhaps the issues which led to the `form` prefix might qualify) or later experience has shown the design to be worse than previously thought. I will fight a design tooth and nail while it's being proposed and reviewed, but once it's accepted, I put aside my feelings, accept the proposal as part of the language's design, and move on with it. It's the only way we can get anything done here.
Rehashing old decisions like this is just spinning our wheels. There are lots of exciting new things we *haven't* decided—things like multiline string literals, Foundation and Dispatch designs, and a world of syntax clean-ups. Let's focus on those things—things where we can make forward progress, not keep revisiting old arguments.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code.
I could reply "they are confusing because they look like class names and clearly cause a higher number of errors in code.”
FWIW, this became an actual problem in practice with the introduction of SE-0069 (https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md\), which bridges “NSURL” to a value type “URL”, so
var URL: URL
becomes an actual, practical problem that consistent lowerCamelCasing of values avoids.
- Doug
On May 19, 2016, at 2:01 PM, charles--- via swift-evolution <swift-evolution@swift.org> wrote:
My *actual* view is that both forms cause problems, so it doesn't much matter which we go with.
Sent from my iPhone
On May 19, 2016, at 1:30 PM, Pavel Kapinos <kapinos@twobytesoftware.com <mailto:kapinos@twobytesoftware.com>> wrote:
Hi Charles,
Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.On May 19, 2016, at 1:20 PM, charles@charlesism.com <mailto:charles@charlesism.com> <charlesism.com@gmail.com <mailto:charlesism.com@gmail.com>> wrote:
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Thanks, Doug.
Sure, I see it now more clear in the light of NS prefix being dropped. Still, I am not quite convinced by your example as it is "on purpose”, while URLHandler is a real thing. But I guess, old habits die hard. Have a good day!
Cheers,
Pavel.
On May 19, 2016, at 3:14 PM, Douglas Gregor <dgregor@apple.com> wrote:
On May 19, 2016, at 2:01 PM, charles--- via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code.
I could reply "they are confusing because they look like class names and clearly cause a higher number of errors in code.”
FWIW, this became an actual problem in practice with the introduction of SE-0069 (https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md\), which bridges “NSURL” to a value type “URL”, so
var URL: URL
becomes an actual, practical problem that consistent lowerCamelCasing of values avoids.
- Doug
My *actual* view is that both forms cause problems, so it doesn't much matter which we go with.
Sent from my iPhone
On May 19, 2016, at 1:30 PM, Pavel Kapinos <kapinos@twobytesoftware.com <mailto:kapinos@twobytesoftware.com>> wrote:
Hi Charles,
Thank you for your feedback! But we are not talking here bad or good names per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a result it enables fast and easy comprehension and writing a good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!
Cheers,
Pavel.On May 19, 2016, at 1:20 PM, charles@charlesism.com <mailto:charles@charlesism.com> <charlesism.com@gmail.com <mailto:charlesism.com@gmail.com>> wrote:
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution