для передачи параметров функции удобно пользоваться туплом.
у меня оказываются структуры параметров (struct все с public полями), было бы здорово их как-то в туплы..
то же в другом месте пригодилось бы и для классов.. но там в тупл желательно не только public.
чувствую много хочу, но мало ли, есть ли простой способ?

Здравствуйте, _Claus_, Вы писали:

Так в чем вопрос-то?

H>Так в чем вопрос-то?

1)как использовать структуру вместо тупла для параметров вызова
2)как получить тупл эквивалентный полям класса

Здравствуйте, _Claus_, Вы писали:

H>>Так в чем вопрос-то?

_C_>1)как использовать структуру вместо тупла для параметров вызова
_C_>2)как получить тупл эквивалентный полям класса

Здесь тебе нужен макрос, который добавляет в твои структуры и классы методы для преобразования его в тупл, алгоритм таков:

— макрос на фазе before typed members, вешается на тип
— сканируешь все поля в классе и собираешь их названия и типы
— далее создаешь метод например ToTuple() с типом тупла <[ @*(..$field_types) ]>, это будет выходной тип, в нем нужно создать тупл квазицитатой (..$field_names)
— выдаешь результирующий тупл

то есть у тебя будет метод который автоматически преобразует твою структуру или класс в тупл.
Далее если ты хочешь неявное преобразование твоей структуры в тупл, обратимся к средствам .net, к так называемым операторам неявного преобразования, создаешь в твоих классах тем же макросом метод

  public static @:(a : TupleTest) : int * string // вместо TupleTest и int * string должны быть твои имя класса и тип тупла
  {
    a.ToTuple()
  }

и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

Здравствуйте, CodingUnit, Вы писали:

CU>и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

обратное преобразование тоже возможно, надо сделать оператор в том же классе:

  public static @:(tup : int * string) : TupleTest // вместо класса и тупла твое название и размерность
  {
    TupleTest(tup) // чтобы так создавать лучше класс помечать [Record] тогда конструкторы будут готовы принять тупл
  }


class Test
{
  public Testing(tup : int * string) : void
  {
  
  }
  
  public Testing2(test : TupleTest) : void
  {
  }

  public Main() : void
  {
    def test = TupleTest(1, "123");
    Testing(test);

    Testing2((1, "111"));    
  }
}

у меня такой пример компилируется

CU>и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

было бы здорово иметь возможность получения тупла из структуры/класса в любой ситуации без навешивания спец кода — хоть для маршалинга, хоть для
вызова или паттерн-матчинга... или нет?

Здравствуйте, _Claus_, Вы писали:

CU>>и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

_C_>было бы здорово иметь возможность получения тупла из структуры/класса в любой ситуации без навешивания спец кода — хоть для маршалинга, хоть для
_C_>вызова или паттерн-матчинга... или нет?


А в чем проблема, классы помечаешь макро-аттрибутом, разве это сложно? Можно определить макрос для всех структур в проекте. Автоматически такие вещи на уровне языка делать не совсем хорошо, это уже из ряда вон выходящее что то получится.

Здравствуйте, CodingUnit, Вы писали:

CU>Здравствуйте, _Claus_, Вы писали:

CU>>>и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

_C_>>было бы здорово иметь возможность получения тупла из структуры/класса в любой ситуации без навешивания спец кода — хоть для маршалинга, хоть для
_C_>>вызова или паттерн-матчинга... или нет?


CU>А в чем проблема, классы помечаешь макро-аттрибутом, разве это сложно? Можно определить макрос для всех структур в проекте. Автоматически такие вещи на уровне языка делать не совсем хорошо, это уже из ряда вон выходящее что то получится.

хотя нет в любом случае вряд ли получится, но можно поэкспериментировать с [ExtensionPattern] или макросами уровня выражений.

Здравствуйте, _Claus_, Вы писали:

CU>>и в местах где требуется int * string, ты можешь подставлять экземпляр твоего класса с волшебным макросом

_C_>было бы здорово иметь возможность получения тупла из структуры/класса в любой ситуации без навешивания спец кода — хоть для маршалинга, хоть для
_C_>вызова или паттерн-матчинга... или нет?

Было бы здорово, если бы это не служило источником проблем при работе со структурой. Программист привык, что добавление полей обычно не ломает существующий код.

Z>Было бы здорово, если бы это не служило источником проблем при работе со структурой. Программист привык, что добавление полей обычно не ломает существующий код.

Любой инструмент, если им пользоваться бездумно или не по назначению, служит источником проблем (ножи, вилки, топоры, ... ).

Здравствуйте, _Claus_, Вы писали:


Z>>Было бы здорово, если бы это не служило источником проблем при работе со структурой. Программист привык, что добавление полей обычно не ломает существующий код.

_C_>Любой инструмент, если им пользоваться бездумно или не по назначению, служит источником проблем (ножи, вилки, топоры, ... ).

Ну так структура в качестве тупла это и есть использование инструмента не по назначению. Одному методу нужен int * string, второму string * int. Два программиста одновременно решили заюзать фичу в очень разных частях проекта, а при merge все сломалось. Третий добавил поле, поскольку этого требовала его задача и проект внезапно перестал компилироваться в n-цати местах.

Вобщем фича очень спорная. Ее простейшая реализация тривиальна и ты можешь использовать ее на свой страх и риск. Только я бы сделал что-то более гибкое, например <- наоборот, что позволит создавать туплы просто перечисляя нужные поля. Код станет понятен и прозрачен, в отличии от конвертации в порядке перечисления полей.

Z>Вобщем фича очень спорная.

может и так. если нет механизма унификации между туплами/структурами/вариантами/классами, то возникают сложности из-за того,
что в одном месте надо то, в другом это, а моста нет, хотя по сути имеем везде одно и то же(по содержанию) с несущественными отличиями.
макросы могут снять остроту проблемы, но поддержка компилятором была бы куда серьезней. был бы такой наворот,
что все бы ошалели. гоню?

Здравствуйте, _Claus_, Вы писали:

_C_>был бы такой наворот, что все бы ошалели. гоню?
Именно что все ошалеют.
Сколько пишу на немерле мне таких мыслей даже в голову не приходило.

Здравствуйте, _Claus_, Вы писали:


Z>>Вобщем фича очень спорная.

_C_>может и так. если нет механизма унификации между туплами/структурами/вариантами/классами, то возникают сложности из-за того,
_C_>что в одном месте надо то, в другом это, а моста нет, хотя по сути имеем везде одно и то же(по содержанию) с несущественными отличиями.
_C_>макросы могут снять остроту проблемы, но поддержка компилятором была бы куда серьезней. был бы такой наворот,
_C_>что все бы ошалели. гоню?

Да нет это уже слишком, специфика статически типизированных языков как раз в том, чтобы статическими конструкциями типов упростить размещение и операции управление над данными, на этапе компиляции. Программист должен явно указать тип структуры, ее синтаксис использования, типы (в классах), за счет этого достигается безопасность и предсказуемость приложения, это достижения ООП последние 20 лет. И программист вынужден описывать многие типы явно и их использование, это большой плюс статически типизированных языков, многое сейчас компилятором делается за нас, как вывод типов, но остальное надо писать явно, сказать компилятору что то в духе возьми вон то и запусти туда, не получится потому что ему нужны конкретные типы до полей и подставить один тип, когда требуется другой не получится. Этим бы нарушалась бы безопасность и все стало быть похожим на винегрет из типов. Что то подобное можно делать в любительских и динамических языках, но это не то за что мы любим статические языки. Это все мечты на тему, как хорошо бы было если я написал пару строк, а компилятор всю программу написал за меня.

Здравствуйте, _Claus_, Вы писали:


Z>>Вобщем фича очень спорная.

_C_>может и так. если нет механизма унификации между туплами/структурами/вариантами/классами, то возникают сложности из-за того,
_C_>что в одном месте надо то, в другом это, а моста нет, хотя по сути имеем везде одно и то же(по содержанию) с несущественными отличиями.
_C_>макросы могут снять остроту проблемы, но поддержка компилятором была бы куда серьезней. был бы такой наворот,
_C_>что все бы ошалели. гоню?


Мне кажется, это вариация на тему номинальной и структурной типизации. В Немерле все-таки принята структурная типизация. Так что придется с этим жить.

Но пофантазировать на тему структурной типизации можно.

CU>Да нет это уже слишком, Это все мечты на тему, как хорошо бы было если я написал пару строк, а компилятор всю программу написал за меня.
это не слишком если Н претендует (вполне обоснованно) на портирование на другие платформы. а следовательно у него должны рано или поздно
появиться свои средства сериализации /трансформации / .. позволяющие скрывать детали того, поверх чего он работает. сейчас это невозможно.
давайте представим что у нас есть некоторый новый тип — unitype, который описывается как класс и/или как вариант, который прозрачно может
выступать как класс, структура, вариант, тупл, и так же легко может быть приводим к ним. (скажу крамолу — тогда эти понятия станут избыточными).
для .net к примеру реализация такого была бы
как класс, содержащий структуру и указатель VMT, а наследование — расширение этой внутренней структуры полями наследника. никакой динамики,
контроль такой же строгий, но становиться возможными вещи, доступные динамическим языкам, а само программирование упрощается и универсиализируется.
Н в том виде который есть — прекрасен, но иногда имеет смысл смотреть и в отдаленное будущее. особенно когда связываешься на годы.

Здравствуйте, catbert, Вы писали:

C>В Немерле все-таки принята структурная типизация.

*номинальная