Reachability.swift: Conflitos de ReachabilitySwift com Reachability (Objective-C)

Obrigado por levantar este problema, mas a compatibilidade reversa com projetos Objective C / mistos não é um objetivo para esta biblioteca.

Saúde
Cinza

Oi @ashleymills

Estou tendo o mesmo problema, recebendo conflitos sobre outras bibliotecas
ReachabilitySwift e Reachability

existe alguma alternativa para fazer funcionar?
no lado do Xcode?

Pesquisei algumas soluções, mas realmente não entendi.
eles disseram que Renomeie o arquivo.

você pode fornecer uma solução?

Bem, você está publicando uma biblioteca gratuita do que muitas pessoas usam e certamente ajudou a comunidade de muitas maneiras, então devo começar com isso, obrigado (sou mais forçado a usá-la como um dep temporário e outras decisões / inclusões , mas não há necessidade de mergulhar nisso, ainda quero expressar minha gratidão por sua criação, manutenção e compartilhamento de uma biblioteca que tem ajudado a comunidade, um grande obrigado por isso !!!).

Eu sugeriria que esta não é uma questão de "compatibilidade com versões anteriores", mas sim de "respeitar a convenção e a norma" usando um identificador único na frente do nome do módulo (especialmente quando ele colide com uma plataforma ou existente bem conhecida. fornecido!), e ainda mais ao criar algo que, sem dúvida, se tornará uma dependência temporária.

Quase um ano depois, esse problema persiste e força os desenvolvedores e usuários a recorrerem a chicanas que em grande parte anulam todo o propósito ou vantagem do software de código-fonte aberto, quando o problema é amplamente evitável.

O que seria tão ofensivo sobre ASHReachability? As chances de uma colisão de namespace são incrivelmente menores. E você também tem um primeiro nome legal!

Eu não escolhi o graphql_flutter e a conectividade para usar ReachabilitySwift e Reachability (respectivamente) e resultou em um erro de construção estranho que me força a ondulações estranhas que mais se assemelham a poses com nomes de sânscrito antigo do que soluções razoáveis ​​e modernas, mas aqui estamos, muitos de nós (se minhas pesquisas de GH, etc são qualquer indicação), simplesmente porque um nome não foi escolhido exclusivamente ao tentar melhorar outro?

Claro, vou fazer um fork do ReachabilitySwift e consertar o problema ou graphql_flutter e fazer com que use Connectividade_swift em vez disso, mas isso não executa um anátema para todo o código-fonte aberto, modelo de contribuição compartilhada? Prefiro gastar o tempo que invariavelmente vamos gastar agora mantendo isso (isso inevitavelmente vai quebrar em algum ponto) contribuindo para o avanço de seu projeto ou de outro do que trabalhar em torno de um nome que é absurdamente escolhido, por quê?

Mais uma vez, não quero soar ofensivo (minha intenção não é essa), mas questionar seriamente a sabedoria em um mérito puramente técnico de incitar intencionalmente o espaço de nomes e a colisão de símbolos, e dobrar ainda mais para esse fim em nome do que, exatamente ?

PS - Sim, eu conheço a ironia de um americano dizendo coisas como "respeite a convenção e a norma" e "todos nós devemos jogar bem com os outros" e "por que dobrar na decisão errada" não passou despercebido para mim, mas você sabe , "não meu presidente" e eu sinto muito pelos meus 63 milhões de compatriotas idiotas que ainda arrastam os nós dos dedos ...

Obrigado por levantar este problema, mas a compatibilidade reversa com projetos Objective C / mistos não é um objetivo para esta biblioteca.

Saúde
Cinza