Mantenere le API e usare gli idiomi in una porta

12

Sto lavorando su una porta da Python a Rust e ho trovato un codice che non può essere espresso in modo naturale in Rust come in Python.

Un caso riguarda i parametri predefiniti:

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

In Rust, puoi implementarlo usando un builder:

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

Per usare la classe in Python, è semplicemente:

foo = Foo("Hello, World!")

Tuttavia, in Rust, avresti bisogno di scrivere qualcosa come:

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

Questo porta alla domanda: è meglio mantenere un'API per una porta, o è meglio usare gli idiomi del linguaggio di porting? Dipende da quanto è nota l'API per cominciare?

    
posta erip 18.12.2015 - 17:28
fonte

1 risposta

18

Vuoi che le tue idee siano espresse chiaramente nella lingua che le ospita. Ciò significa utilizzare gli idiomi della lingua ospite.

Prendi la famosa libreria Underscore: js e lua . La porta lua è funzionalmente equivalente per la maggior parte . Ma quando è appropriato, le implementazioni sono leggermente diverse. Ad esempio:

_.toArray()

diventa

_.to_array()

Questa modifica rende il nome della funzione più nativo ai programmatori Lua.

Allo stesso modo, _.each () richiede un oggetto, un array o qualcosa di simile a un array in JavaScript, ma _. each () in Lua può anche prendere un iteratore - un meccanismo che non era disponibile in JavaScript quando il Underscore originale la libreria è stata creata.

L'autore di Lua ha sensibilmente tradotto ciò che l'autore originale avrebbe voluto se lo avesse scritto a Lua. Questa è la chiave. Chiediti l'intento originale e poi implementa quell'intento nel tuo linguaggio di scelta: idiomi e tutto. A seconda della lingua di partenza e di destinazione, ciò può significare aggiungere, modificare o rimuovere funzionalità.

Ricorda che gli utenti di lingue diverse saranno rari. La maggior parte degli utenti userà una lingua o l'altra. Per loro, le differenze non contano. Se qualcuno usa entrambi, probabilmente sono abbastanza sofisticati da apprezzare la tua traduzione. Non è diverso dalla traduzione di lingue parlate. Alcune idee non sono direttamente traducibili. I migliori traduttori si attengono all'intenzione dell'originale, non alla traduzione letterale parola per parola.

    
risposta data 18.12.2015 - 20:43
fonte

Leggi altre domande sui tag