Maintenir l'API ou utiliser des idiomes dans un port

Je travaille sur un port de Python à Rust et j'ai rencontré du code qui ne peut pas être exprimé aussi naturellement dans Rust que dans Python.

Un cas de cela utilise des paramètres par défaut:

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

Dans Rust, vous pouvez implémenter cela à l'aide d'un générateur:

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,
    }
  }
}

Pour utiliser la classe en Python, c'est simplement:

foo = Foo("Hello, World!")

Cependant, dans Rust, vous auriez besoin d'écrire quelque chose comme:

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

Cela conduit à la question: est-il préférable de maintenir une API pour un port, ou est-il préférable d'utiliser des idiomes du langage de portage? Cela dépend-il de la notoriété de l'API?

api-design porting

— erip
source

L'API d'une classe est la façon dont vous l'utilisez, pas la façon dont elle est exprimée dans le code. Ainsi, cette traduction a un ABI radicalement différent et tout simplement inacceptable.

— Déduplicateur

Où est-il dit que c'est de la rouille idiomatique?

— Nadir Sampaoli

Je suis désolé, je dois avoir mal compris. Vous avez publié du code Rust, ainsi qu'un dilemme: la météo vous maintiendriez une API pour un port ou vous utiliseriez des idiomes du langage de portage . Ce code ne ressemble à aucun de ces cas. Si c'est la bonne interprétation, quel est le but de cet exemple de code? Que décrit-elle et comment est-elle liée à la question réelle?

— Nadir Sampaoli

Vous voulez que vos idées soient clairement exprimées dans la langue qui les héberge. Cela signifie utiliser des idiomes du langage hôte.

Prenez la bibliothèque Underscore populaire: js et lua . Le port lua est fonctionnellement équivalent pour la plupart . Mais quand c'est approprié, les implémentations sont légèrement différentes. Par exemple:

_.toArray()

devient

_.to_array()

Cette modification rend le nom de la fonction plus natif pour les programmeurs Lua.

De même, _.each () nécessite un objet, un tableau ou quelque chose de semblable à un tableau en JavaScript, mais _.each () en Lua peut également prendre un itérateur - un mécanisme qui n'était pas disponible en JavaScript lorsque la bibliothèque Underscore d'origine a été créé.

L'auteur de Lua a raisonnablement traduit ce que l'auteur original aurait voulu s'il l'avait écrit en Lua. Voilà la clé. Posez-vous des questions sur l'intention initiale, puis mettez-la en œuvre dans la langue de votre choix - idiomes et tout. Selon la langue source et la langue cible, cela peut signifier ajouter, modifier ou supprimer des fonctionnalités.

N'oubliez pas que les utilisateurs multilingues seront rares. La plupart des utilisateurs utiliseront une langue ou l'autre. Pour eux, les différences n'ont pas d'importance. Si quelqu'un utilise les deux, il est probablement suffisamment sophistiqué pour apprécier votre traduction. Ce n'est pas différent de traduire des langues parlées. Certaines idées ne sont pas directement traduisibles. Les meilleurs traducteurs s'en tiennent à l'intention de l'original, pas à une traduction littérale mot pour mot condamnée.

— Scant Roger
source