Swift-style-guide: Sugestões para o próximo rev

Você marcaria seu @IBOutlets privado pelo mesmo motivo?

Estou um pouco dividido neste. Por um lado, @IBActions podem ser vistos como públicos, pois são expostos a uma interface. Por outro lado, não há uma boa razão para expô-los e em Obj-C, eu sempre coloco eles no arquivo do método. Outra consideração é que os veículos e ações arrastados do IB são sempre declarados internos/públicos.

Suponho que devemos nos perguntar se é ou não uma boa ideia construir uma dependência na tag @objc .

Aqui estão meus pensamentos:

1) Sou contra o uso da tag @objc . O Swift está se afastando ativamente do Objective-C, assim como os tutoriais do RW.

2) Sobre marcar @IBAction e/ou @IBOutlet como private como regra geral em tutoriais, acho que também não gosto disso.

Em meus próprios projetos, sim, limito o escopo o máximo possível. No entanto, não acho que esse seja um conceito-chave para a maioria dos tutoriais de RW.

Assim, eu questionaria: "Isso prejudicará o conceito-chave que estou tentando ensinar em um tutorial?" É bem possível que sim, especialmente se eu tiver que explicar por que estou marcando algo como private que não é imediatamente óbvio.

Além disso, acho que isso adicionaria apenas mais uma etapa de edição técnica às _numerous_ verificações que já estamos fazendo e, novamente, questionaria quanto valor isso realmente fornecerá nos tutoriais.

IMHO, acho que devemos adiar o escopo do autor e do editor de tecnologia para @IBAction e @IBOutlet s em vez de ter uma regra sobre isso.

Até onde eu sei, você PRECISA usar a tag @objc para poder marcar a função seletora como privada.

Sim, eu definitivamente marco meu @IBOutlets como privado. Eles são um detalhe de implementação que não deve ser exposto a chamadores externos, a menos que seja absolutamente necessário.

Lembre-se de que o guia de estilo não é um guia tutorial. Se essa é a intenção, então pare de anunciar e torne-o interno apenas para os escritores. Você tem toneladas de pessoas de toda a web usando isso como seu guia de estilo. Deve encorajar o bom comportamento, não apenas o que é conveniente para um tutorial.

Sempre me incomoda quando um tutorial pula as coisas apenas para facilitar, pois temos pessoas novas no desenvolvimento APRENDENDO com seus tutoriais e, portanto, você os ensinou a fazer as coisas de forma abaixo do ideal.

Obrigado pelo feedback e sugestões.

Os métodos @objc não precisam ter despacho dinâmico completo para serem marcados como privados. Controle de acesso e despacho não estão relacionados. Por exemplo, os seguintes trabalhos:

    <strong i="8">@IBAction</strong> private func buttonTapped(sender: UIButton) {
    }

Eu estou supondo que você tinha outra coisa em mente, e eu gostaria de entendê-la.

Obs:
No que diz respeito ao objetivo do guia, acredito que foi declarado muito claramente no primeiro parágrafo. Pessoalmente, eu uso uma versão bifurcada dele em meus próprios projetos com modificações na regra de espaçamento, cabeçalho de direitos autorais e algumas regras adicionais de UIKit e IB. Eu acho que muitas vezes pode ser usado como ponto de partida.

O problema ao qual o @grosch se refere é o uso de seletores.
let recognizer = UITapGestureRecognizer(target: self, action: #selector(buttonTapped(_:)))

Para que o seletor seja privado, ele precisa ser:
<strong i="10">@objc</strong> private func buttonTapped(sender: UITapGestureRecognizer)
ou
private dynamic func buttonTapped(sender: UITapGestureRecognizer)

Ah, eu vejo agora. Obrigado! 👋
Métodos marcados private de uma classe compatível com Obj-C não são despachados dinamicamente (ou seja, não são seletores). De certa forma, o guia atual já cobre isso. Coisas privadas geralmente devem ser marcadas como privadas para melhorar a clareza. Veja https://github.com/raywenderlich/swift-style-guide#access -control
Uma vez marcado private , é totalmente um detalhe de implementação da classe. Se você precisar se referir a ele como um seletor em algum lugar, você realmente não tem escolha a não ser torná-lo um. Eu acho que é melhor ser preguiçoso nesta segunda parte porque com o Swift 3 ... (oops, quero dizer Swift 4) Resiliência da ABI, mudar um método privado não será uma mudança de ruptura. Além disso, marcando métodos privados com @objc você está impedindo ativamente que o otimizador faça inlining, etc., portanto, há uma desvantagem significativa em fazê-lo.