Підтримуйте API проти використання ідіом у порту


12

Я працюю над портом від Python до Rust і натрапив на якийсь код, який не може бути виражений так природно в Rust, як вони можуть в Python.

Один випадок цього - використання параметрів за замовчуванням:

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

У Rust ви можете реалізувати це за допомогою будівельника:

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

Для використання класу в Python просто:

foo = Foo("Hello, World!")

Однак у Русті вам потрібно буде написати щось на кшталт:

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

Це призводить до питання: чи краще підтримувати API для порту, чи краще використовувати ідіоми мови перенесення? Чи залежить це від того, наскільки добре відомо API для початку?


2
API класу полягає в тому, як ви його використовуєте, а не як він виражається в коді. Отже, цей переклад має надзвичайно інший і просто неприйнятно громіздкий ABI.
Дедуплікатор

Де сказано, що це ідіоматичний Іржа?
Надір Сампаоолі

Вибачте, я, мабуть, зрозумів неправильно. Ви опублікували деякий код іржі разом із дилемою: погода ви будете підтримувати API для порту або використовуєте ідіоми мови перенесення . Цей код не схожий на жоден із цих випадків. Якщо це правильне тлумачення, яка мета цього зразка коду? Що це описує і як воно пов'язане з фактичним питанням?
Надір Сампаоолі

Відповіді:


18

Ви хочете, щоб ваші ідеї були чітко виражені мовою, яка їх розміщує. Це означає використання ідіом мови хосту.

Візьміть популярну бібліотеку підкреслення: js та lua . Порт Луа здебільшого функціонально еквівалентний . Але коли це доречно, реалізація дещо відрізняється. Наприклад:

_.toArray()

стає

_.to_array()

Ця зміна змушує ім'я функції відчувати себе більш рідним для програмістів Lua.

Аналогічно, _.each () вимагає об’єкт, масив або щось подібне до масиву в JavaScript, але _.each () в Lua також може взяти ітератор - механізм, який не був доступний у JavaScript, коли оригінальна бібліотека підкреслення було створено.

Автор Луа грамотно переклав те, що задумав би оригінальний автор , якби вони написали це в Луї. Ось ключ. Запитайте себе про оригінальний намір, а потім реалізуйте цей намір на своїй обраній мові - ідіоми та все. Залежно від мови джерела та мови, це може означати додавання, редагування чи видалення функцій.

Пам’ятайте, що користувачі між мовами будуть рідкісними. Більшість користувачів використовуватимуть ту чи іншу мову. Для них відмінності не мають значення. Якщо хтось використовує обидва, вони, ймовірно, досить складні, щоб оцінити ваш переклад. Це не відрізняється від перекладу розмовних мов. Деякі ідеї не можна безпосередньо перекласти. Найкращі перекладачі дотримуються наміру оригіналу, а не приреченого буквального перекладу «слово за словом».

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.