Manter API vs. usar expressões idiomáticas em uma porta

Estou trabalhando em uma porta do Python para o Rust e encontrei um código que não pode ser expresso tão naturalmente no Rust quanto no Python.

Um caso disso é usar parâmetros padrão:

class Foo:
  def __init__(self, a="Hello"):
    self._a = a

No Rust, você pode implementar isso usando um construtor:

struct FooBuilder {
  a: &'static str,
}

struct Foo {
  _a: &'static str
}

impl FooBuilder {
  fn new() -> FooBuilder {
    FooBuilder {
      a: "Hello",
    }
  }

  fn change_a(self, new_a: &'static str) -> FooBuilder {
    FooBuilder {
      a: new_a,
      ..self
    }
  }

  fn build(self) -> Foo {
    Foo {
      _a: self.a,
    }
  }
}

Para usar a classe em Python, é simplesmente:

foo = Foo("Hello, World!")

No entanto, no Rust, você precisaria escrever algo como:

let foo = FooBuilder::new().change_a("Hello, World!").build();

Isso leva à pergunta: é melhor manter uma API para uma porta ou é melhor usar expressões idiomáticas da linguagem de portabilidade? Depende de quão bem conhecida é a API?

api-design porting

— erip
fonte

A API de uma classe é como você a usa, não como é expressa no código. Portanto, essa tradução tem uma ABI totalmente diferente e simplesmente inaceitavelmente complicada.

— Deduplicator

Onde se diz que isso é ferrugem idiomática?

— Nadir Sampaoli

Me desculpe, eu devo ter entendido errado. Você publicou algum código Rust, juntamente com um dilema: o clima manteria uma API para uma porta ou usaria expressões da linguagem de portabilidade . Esse código não se parece com nenhum desses casos. Se essa é a interpretação correta, qual é o objetivo desse exemplo de código? O que está descrevendo e como isso se relaciona com a pergunta real?

— Nadir Sampaoli

Você deseja que suas idéias sejam expressas claramente no idioma que as hospeda. Isso significa usar idiomas de idioma do host.

Pegue a popular biblioteca Underscore: js e lua . A porta lua é funcionalmente equivalente na maior parte . Mas quando apropriado, as implementações são um pouco diferentes. Por exemplo:

_.toArray()

torna-se

_.to_array()

Essa alteração faz com que o nome da função pareça mais nativo para os programadores Lua.

Da mesma forma, _.each () requer um objeto, matriz ou algo parecido com matriz em JavaScript, mas _.each () em Lua também pode usar um iterador - um mecanismo que não estava disponível em JavaScript quando a biblioteca Underscore original foi criado.

O autor de Lua traduziu sensatamente o que o autor original teria pretendido se o tivesse escrito em Lua. Essa é a chave. Pergunte a si mesmo sobre a intenção original e, em seguida, implemente essa intenção no seu idioma de escolha - expressões idiomáticas e tudo. Dependendo do idioma de origem e de destino, isso pode significar adicionar, editar ou remover recursos.

Lembre-se de que usuários de vários idiomas serão raros. A maioria dos usuários usa um idioma ou outro. Para eles, as diferenças não importam. Se alguém usa os dois, provavelmente é sofisticado o suficiente para apreciar sua tradução. Não é diferente de traduzir idiomas falados. Algumas ideias não são diretamente traduzíveis. Os melhores tradutores mantêm a intenção do original, não uma tradução literal condenada palavra por palavra.

— Roger escasso
fonte