Лингвофорум

Вот подумалось - неименованные аргументы это плохо, потому что нечитаемо. Напр.: new Node(false, false). Что все эти були значат? Нипанятна. А если использовать именованные аргументы, то они очень похожи на поля объекта: new Node(isLeaf = true, isVisible = false). И там, где нужно слишком мнго аргументов, многие API (напр. WinAPI и класс Process в C#) создают специальные структуры по типу ConstructionInfo, чьи поля ты заполняешь и потом единственным объектом заводишь в конструктор.

Так почему же вообще нафиг не унифицировать понятие "список аргументов" с понятием "объект с полями, чо" на уровне семантики и, может быть, синтаксиса.

То есть, любая взятая функция может получать только один объект как параметр. Как аргументы используются поля этого объекта. Т.е. вместо int sum(int x, int y) мы семантически имеем int sum(new anonymousType() { x = 10, y  = 20 })

Да, каждый раз при вызове функции создаётся новый объект просто чтобы передать аргументы. Но если правильно соптимизировать, и правильно поддержать синтаксически, то открывается большое поле для интересных манёвров. Известные "params Object[] objs" в C# или "Object... objs" есть только частный случай-хак.

В каких-то языках это есть? Я, как понимаю, в Лиспе можно рассмотреть это таким образом, но Лисп работает со списками и s-выражениями, а не реальными объектами...

Хорошая мысль.

Цитата: Алексей Гринь от февраля 10, 2012, 00:19
Напр.: new Node(false, false). Что все эти були значат? Нипанятна. А если использовать именованные аргументы, то они очень похожи на поля объекта: new Node(isLeaf = true, isVisible = false).

В C#'е в выражениях типа
new Node(isLeaf: true, isVisible: false);
почему-то используется двоеточие, а не равенство, как в
new Node() { isLeaf = true, isVisible = false };
Непонятно, зачем было так извращаться.

Немножко не понял, вы хотите С'ишные структуры как аргументы функции, но что бы эту структуру объявлять вместе с самой функцией? Что бы к примеру код:
foo(int var, int* var2, mytype var3);
Был аналогичен записи:
struct bar
{
  int var;
  int * var2;
  mytype var3;
}
bar foobar = new bar;
foo(foobar);
?

В принципе интересно, потому что в памяти все элементы структуры следуют один за другим, следовательно можно использовать всякие ништяковые бинарные операторы, но насколько часто это надо?

В JS один хрен все аргументы доступны внутри функции через массив (а любой массив есть объект Array) arguments[], так что от введения лишнего объекта беды не будет. Я, кстати, так и хочу кое-что реализовать...

ЦитироватьВ каких-то языках это есть? Я, как понимаю, в Лиспе можно рассмотреть это таким образом, но Лисп работает со списками и s-выражениями, а не реальными объектами...

В Clojure можно использовать список аргументов как структуру с именованныи полями (map):
(defn f [& {arg1 :key1 arg2 :key2}]
    (действия с arg1, arg2))

(f :key2 val2, :key1 val1) ;порядок аргументов свободный

Если в списке аргументов опустить амперсанд, то при вызове передается один аргумент-структура: (f {:key1 val1, :key2 val2})

Цитата: Тайльнемер от февраля 10, 2012, 04:19
Непонятно, зачем было так извращаться.

Видимо, потому что (isLeaf = true) само по себе вне контекста это rvalue-выражение. Напр., bool b = (isLeaf = true). Немного двусмысленно получается: то ли мы передаём именованный аргумент, то ли assign'ируем переменную некую isLeaf к true и передаём её значение в функцию...

Цитата: hurufu от февраля 10, 2012, 10:01
но насколько часто это надо?

Тут очень много профита:

1) Именованно.

2) При изменении количества аргументов (добавлении, например), API binary compatibility не ломается. Так уже сделано в событиях в C# (класс EventArgs), именно по этой причине. Обычно если меняется сигнатура, то нужно её менять во всех подклассах (в случаях с делегатами - ещё и во всех делегированных методах). В нашем же случае список аргументов просто лениво ссылается на анонимный класс и всё.

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

4) Если каким-то образом поддержать через синтаксис, то можно иметь не только анонимные типы, но и не анонимные (то есть список аргументов is backed by an explicit class). И тут уже целое море разных фич, мы имеем, как я уже писал, мини-шаблоны для валидации значений; т.к. классы полиморфны (в отличие от простого списка аргумента) мы имеем весь полиморфизм, хитрые covariance/contravariance (это надо ещё подумать, как будет полезно), и т.д.

5) Т.к. список аргументов это просто объект, то логгирование/debugging API довольно простое - можно захватить все аргументы целиком и передать куда-то в дебаг (напр. специальная обобщённая функция printArgs()).

Цитата: Python от февраля 10, 2012, 14:54
В Clojure можно использовать список аргументов как структуру с именованныи полями (map):

Но это просто map, а не реальный объект?

Ну так что господа, пишем свою реализацию языка Cи дубль-диез?

ЦитироватьНо это просто map, а не реальный объект?

Просто map. Хотя фактический параметр может быть struct-map, где есть некоторое сходство с сишными структурами.