История изменений

Дятел ты про паттерн визитора слышал? И еще объясняй быстро что это за говно и где матчи с енумами https://docs.rs/serde/latest/serde/de/trait.Visitor.html ?!

О,третий дебил нарисовался.

Это говно, как ты правильно выразился, паттерн визитор. Специально для нашего друга Siborgium замечу, что реализован он без полиморфизма.

Остаётся только догадаться, что ты сказать-то хотел? Что в Расте можно визитор реализовать? Я думаю, это все знали.

Что в некоторых случаях визитор используется? Да, явно используется.

Что в некоторых случаях визитор лучше чем enum? Ну.. вообще не всегда, часто копируют решения из плюсов потому что так привычнее, но в данном случае да, вместо того чтоб вызывать serialize(Field::I32(val)) явно проще написать visitor.visit_i32(val). И не только проще, внутри serialize сэкономится работа на матче.

В остальном вынужден тебя огорчить: ты обосрался.

Во-первых, потому что речь вообще шла о ситуации, в которой объекты разных типов находятся вперемешку в рантайме и их надо обработать. Что лучше, общий интерфейс и trait object или enum. А ты мне что приволок? Где здесь переменная, способная иметь разные типы? Нет, ты приволок заготовку для сериализации/десериализации, которая позволяет макросу заниматься кодогенераций компайлтайме.

Во-вторых, да, теоретически визитор можно использовать для рисования шейпов в разные библиотеки. Но это не решение задачи, это смежная задача.

Можно написать:

draw(...) {
  match shape {
    Line(p1,p2) -> canvas.drawLine(p1.x, p1.y, p2.x, p2.y),
    Circle(center, radius) -> canvas.drawEllipse(center.x - radius, center.y - radius, ....)
  }
}

а можно

visit(...) {
  match shape {
    Line(p1,p2) -> visitor.visiLine(p1, p2),
    Circle(center, radius) -> visitor.visitCircle(center, radius)
  }
}

Как видишь, код идентичный, задачу определения «динамического типа» шейпа твой визитор не решил. Её придётся либо решать так же матчем, либо деревом наследования типа, каждый из которых реализует visit. Это, безусловно, решит проблему засирания классов шейпов тонной функций, но это будет то самое решение, которое ты же и отквотил, цитирую: Тебе настучат по башке и заставят переделывать, так что ты запилишь некий общий интерфейс канваса и сделаешь рендеринг в него, а потом для каждой графической либы запилишь обёртку над ней, с реализацией твоего канваса.

Но ты молодец, знаешь что такое визитор.

PS: и да, на всякий случай: если ты хотел помочь нашему другу Siborgium, то нет. Его поинт в пользу трейта шейп и наследников был в том, что это позволяет добавить новый тип шейпа и не придётся трогать другой код. Визитор тут не поможет, как только он добавит новый шейп, придётся добавлять новый visitX и все реализации визитора надо будет дорабатывать, т.е. он получит именно о, чего он хотел избежать, отказываясь от матча.

Дятел ты про паттерн визитора слышал? И еще объясняй быстро что это за говно и где матчи с енумами https://docs.rs/serde/latest/serde/de/trait.Visitor.html ?!

О,третий дебил нарисовался.

Это говно, как ты правильно выразился, паттерн визитор. Специально для нашего друга Siborgium замечу, что реализован он без полиморфизма.

Остаётся только догадаться, что ты сказать-то хотел? Что в Расте можно визитор реализовать? Я думаю, это все знали.

Что в некоторых случаях визитор используется? Да, явно используется.

Что в некоторых случаях визитор лучше чем enum? Ну.. вообще не всегда, часто копируют решения из плюсов потому что так привычнее, но в данном случае да, вместо того чтоб вызывать serialize(Field::I32(val)) явно проще написать visitor.visit_i32(val). И не только проще, внутри serialize сэкономится работа на матче.

В остальном вынужден тебя огорчить: ты обосрался.

Во-первых, потому что речь вообще шла о ситуации, в которой объекты разных типов находятся вперемешку в рантайме и их надо обработать. Что лучше, общий интерфейс и trait object или enum. А ты мне что приволок? Где здесь переменная, способная иметь разные типы? Нет, ты приволок заготовку для сериализации/десериализации, которая позволяет макросу заниматься кодогенераций компайлтайме.

Во-вторых, да, теоретически визитор можно использовать для рисования шейпов в разные библиотеки. Но это не решение задачи, это смежная задача.

Можно написать:

draw(...) {
  match shape {
    Line(p1,p2) -> canvas.drawLine(p1.x, p1.y, p2.x, p2.y),
    Circle(center, radius) -> canvas.drawEllipse(center.x - radius, center.y - radius, ....)
  }
}

а можно

visit(...) {
  match shape {
    Line(p1,p2) -> visitor.visiLine(p1, p2),
    Circle(center, radius) -> visitor.visitCircle(center, radius)
  }
}

Как видишь, код идентичный, задачу определения «динамического типа» шейпа твой визитор не решил. Её придётся либо решать так же матчем, либо деревом наследования типа, каждый из которых реализует visit. Это, безусловно, решит проблему засирания классов шейпов тонной функций, но это будет то самое решение, которое ты же и отквотил, цитирую: Тебе настучат по башке и заставят переделывать, так что ты запилишь некий общий интерфейс канваса и сделаешь рендеринг в него, а потом для каждой графической либы запилишь обёртку над ней, с реализацией твоего канваса.

Но ты молодец, знаешь что такое визитор.