[swift-evolution] Issues with 0005-Better Translation of Objective-C APIs Into Swift

[Kevin Schlei]

Sorry for the premature send! Continuing:

let content = listItemView.text.trimming(.whitespaceAndNewlines)

For a beginning programmer, there is no indication of what .trimming does.
In this case, it returns a new string instance. Where is that explained? In
the documentation. Nowhere near the method call.

So are we reduced now to looking up documentation just to read code? What
does this line do:

let next = current.updating(p)

It's 100% unclear because you're relying on parameter names to contain all
the hints. But this line:

let next = current.locationByUpdatingProximity(p)

Lets you know that:

1. we're returning a *'location'*
2. '*by* *updating' *current with a new *'proximity'*

When is the last time you saw a gerund (-ing) as a method name? I wouldn't
let my students write that. Gerunds make good boolean properties. How would
you even read the first line above out loud? Probably by filling in the
words in the second line, magically.

My second major issue is that autocomplete grouping is totally lost when
dropping the type returned at the beginning of the call. How many of us
learned a *ton* when we just autocompleted .stringBy? Look at all the
things you can do! But by removing the 'useless word' (really don't like
that flag name) we have no grouping of constructor methods.

I see a lot of discussion on how to deal with 'with' and 'by' and other
words, but I want to strongly suggest that the current naming practices
provide context and clarity. It makes code readable and accessible. Don't
forget about when you didn't know how to code! These method names are
teaching tools!

Finally, I just want to ask: why? What is the great benefit? Shouldn't
clarity be prioritized over brevity (where have I seen that...)

I can't put it better than another forums poster:

Does the Swift team seriously believe that systematically parsing and
> extensively munging patterns in not-quite-natural-language is tractable to
> support all the corner cases for? And that, even if it were, that it could
> avoid confusion in less-than-perfect codebases? The idea that this will
> somehow benefit a language, particularly one in which clear and obvious
> bridging is so vital is *insane*. The best it can do is a reasonable job,
> with some amount of either unfixable brokenness forced upon developers in
> perpetuity, or constant churn stemming from perpetual fixing of brokenness.
> Swift's translation is currently simple to reason about, and the language
> as a whole has got a really great thing going on. I'm really happy with
> where it is at this moment. Why ruin it by boneheadedly detonating the
> utility of two years of progress in literature and the library of online
> information about Swift? Seriously, why?
>



On Tue, Feb 2, 2016 at 1:04 PM, Kevin Schlei <kevinschlei at gmail.com> wrote:

> I am strongly against the proposed changes to the translation of
> Objective-C APIs. I think the changes promote terseness for terseness sake,
> lose vital context in method names, and are a huge loss pedagogically.
>
> If you teach programming, you'll know why this line will be a nightmare:
>
> let content = listItemView.text.trimming(.whitespaceAndNewlines)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160202/4c901b44/attachment-0001.html>