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

VD>>А а А он предпочтет по эвристике которая гласит, что если есть функция без дженериков, то она будет более предпочтительной. И связано это не с Foo, а с конструктором А. Именно на нем и отрабатывает это правило.

А>А вот C# выберет конструктор с дженериком (если это будет реализовано).

На сегодня, C# просто ничего не выбрет так как для конструкторов он требует задавать параметтры типов.
если же говорит огипотетическом будущем, то конечно же эвристика "предпочтение" не дженерик-метода — это особенность Nemerle. На мой взгляд это очень удачная эвристика. но авторам C#-а кикто и ни что не мешает использовать другой подход. В общем, в еашем случае эта эвристика не имеет ровным счетом ни какого значения.
Главное, что нет разумных причин чтобы запрещать вывод типов для конструкторов.

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

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

N>>Внимание, вопрос. Как должен работать такой код в Nemerle и как он работает на самом деле?

VD>Да, никак не работает, как и должен на самом деле. Ошибку он выдаст, так как Foo нет в А.
VD>А а А он предпочтет по эвристике которая гласит, что если есть функция без дженериков, то она будет более предпочтительной. И связано это не с Foo, а с конструктором А. Именно на нем и отрабатывает это правило.

1) А где это правило написано? Ты говорил, что если правило нигде не написано, то нужно брать соответствующее правило из спеки C#. А в C# overload resolution производится после вывода типов-аргументов и их подстановки в сигнатуру. После этого мы имеем сигнатуры A(long) и A(int), и последняя, естественно лучше, так как есть точное совпадение типов.

2) Хорошо, допустим, в Немерле другое правило. Почему после замены A(long) на A(long?) код начинает компилироваться и выбирается generic тип?

3) А как же пресловутый вывод типов из использования? Я ожидал, что компилятор будет рассуждать так: У нас есть два конструктора. Но постом у сконструированного объекта вызывется метод Foo. Ага, такой метод есть только у generic типа. Значит, его конструктор мы и вызываем. Я неправильно понял идею вывода из использования?

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

N>1) А где это правило написано? Ты говорил, что если правило нигде не написано, то нужно брать соответствующее правило из спеки C#. А в C# overload resolution производится после вывода типов-аргументов и их подстановки в сигнатуру. После этого мы имеем сигнатуры A(long) и A(int), и последняя, естественно лучше, так как есть точное совпадение типов.

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

Что до точного совпадения, то это тонкий вопрос и я не готов на него сейчас ответить.
Там играет роль констант-фолдинг и кое что другое.

N>2) Хорошо, допустим, в Немерле другое правило. Почему после замены A(long) на A(long?) код начинает компилироваться и выбирается generic тип?

Можно пример?

N>3) А как же пресловутый вывод типов из использования? Я ожидал, что компилятор будет рассуждать так: У нас есть два конструктора. Но постом у сконструированного объекта вызывется метод Foo. Ага, такой метод есть только у generic типа. Значит, его конструктор мы и вызываем. Я неправильно понял идею вывода из использования?

Дык вывод идет из первого использования. Сначала выводится конструктор, а уже на основании типа конструтора определяется тип переменной и производится разрешение перегрузки.
Вообще там все очень не просто. Вывод типов — подразумевает построение графа завмостей между всеми типами используемыми в методе.
Но в шарпе такого нет. Так что даже не стоит об этом говорить. Но это как раз упрощает ситуцию. Вывод типов конструкторов может делаться по тем же принципам, что и статических методоа.

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

N>>2) Хорошо, допустим, в Немерле другое правило. Почему после замены A(long) на A(long?) код начинает компилироваться и выбирается generic тип?

VD>Можно пример?

module Program
{
  Main() : void
  {
    def x = A(1);
    x.Foo();
  }
}

class A
{
    public this(_ : long?) { } // Поменяли 'long' на 'long?'
}

class A[T]
{
    public this(_ : T) { }
    public Foo() : void { }
}

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

VD>И все же попробуй абстрагироваться. Забудь на минуточку о том что ты знаешь о внутреннем устройстве CLR и попробуй подумать о том как можно варазить создание обекта (для программиста, а не для CLR).

Ну что Вы, я весьма слабо знаю внутреннюю кухню. CLR. Зато достаточно неплохо представляю способы, какими подобные вещи реализуются. Но призыв "абстрагироваться от внутренней кухни", на мой взгляд, выглядит несколько странно при обсуждении, почему то или иное поведение не реализовано в той самой внутренней кухне.

VD>Так вот конструктор можно представит банальной функцией получаюжей нолили более аргументов и создающей объект определенного типа.

VD>Паттерн "Фабричный метод" пользуется таким представлением дляя инкапсуляции логики создания объекта.
VD>Так почему же нельзя рассматривать и обычные конструктораы подобным образом?

VD>Вот Nemerle и поступает подобным образом.

VD>Что же это дает?

VD>Оказывается весьма не мало.
VD>1. Это позволяет обращаться с конструкторами как с обычными функциями (передавать их в качестве параметра, помещать в переменные, формировать на их основе другие функции). Другими словами рассмитривать конструктор как первоклассную сущность языка.
VD>2. Упростит концепции (правила) языка и реализацию компилятора. Ведь для конструкторов становятся применимы все павила применимые к обычным функциям.
VD>3. (пожалуй самое важное в контексте данной темы) Становится ясно, что к констукторам можно без проблем применять все правила вывода типов применимые к обычным функциям.

VD>На лицо унификация одновременно упрощающая восприятме, использование и реализаци.

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

VD>Теперь, что касается статических методов и свободных фенкций. Формально вдотнете нет свободных функций. И вообще — это терминология C++. Однако можно просто считатические методы и свободные функции синонимами так как если абстрагироваться от деталей, классы для статических методов скорее служат для целей выделения пространств имен/модулей. Так что по фигу как их называть.

"Не плоди сущности без необходимости". Экзэмплярный метод должен иметь (и имеет) полный доступ к экзэмпляру, с учётом ограничений видимости. Классовый метод должен иметь полный доступ, с теми-же ограничениями, к информации класса, к его RTTI. А если это свободная функция, то она ею должна быть. А если это класс, то он и должен быть классом, а не пространством имён. Но всё это моё чистое IMHO, без претензий на высшую истину.

VD>Просто, какое-то "Горе от ума".

Извините, что сдуру вмешался в вашу высоинтеллектуальную дискуссию.

Здравствуйте, nikov, Вы писали:
N>>>2) Хорошо, допустим, в Немерле другое правило. Почему после замены A(long) на A(long?) код начинает компилироваться и выбирается generic тип?

VD>>Можно пример?

N>

N>module Program
N>{
N>  Main() : void
N>  {
N>    def x = A(1);
N>    x.Foo();
N>  }
N>}

N>class A
N>{
N>    public this(_ : long?) { } // Поменяли 'long' на 'long?'
N>}

N>class A[T]
N>{
N>    public this(_ : T) { }
N>    public Foo() : void { }
N>}
N>

Потому, что ncc (незнаю с какого переполоху) не считает возможным привести int к Nullable<long>. Это хорошо видно если удалить класс A[T] или поменять константу "1" на "1L".
В первом случае компилятор заорет:

Error: in argument #1 (_N_wildcard_2658), needed a System.Nullable[long], got int: System.Int32 is not a subtype of System.Nullable.[T] [simple require]

Во втором:

Main.n(10,5):Error: there is no member named 'Foo' in A with type ?
Main.n(10,5):Error: unbound name 'Foo' in 'x'

т.е. все вернется на круги своя.

Так что если это и баг, то в другом месте.
К рассматриваемому вопросу вывода типов конструкторов это отношения не имеет.

ЗЫ

Боюсь, что проблемы МС банально смешны. Ребята просто не додумались посмотреть на конструктор как на статическую функцию. Они рассматривают конструктор как уникальную сущность. Отсюда и проблемы.
А может они уже просто зашились в коде компилятора написанном на С++ и любое изменение дается настолько болезненно, что проще отбрехаться нежели что-то переделать.

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

VD>Так что если это и баг, то в другом месте.
VD>К рассматриваемому вопросу вывода типов конструкторов это отношения не имеет.

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

Здравствуйте, Мизантроп, Вы писали:

М>Ну что Вы, я весьма слабо знаю внутреннюю кухню. CLR. Зато достаточно неплохо представляю способы, какими подобные вещи реализуются. Но призыв "абстрагироваться от внутренней кухни", на мой взгляд, выглядит несколько странно при обсуждении, почему то или иное поведение не реализовано в той самой внутренней кухне.

Ясно. Ну, да нет разницы в какие дебри закапываться. Кишки CLR ни чем не интереснее кишков бэканда компилятора.

М>Так ведь я вроде и не предлагал рассматривать конструктор как нечто особенное, разве нет?

Ты предлагал не рассматривать его как ординарную функцию. А как раз это решает тучу проблем.

М>Всё это замечательно, за исключением одного — зачем использовать для этого передачу конструктора, когда то-же самое, и даже большее можно получить, передавая ссылку на RTTI — при условии, что язык позволяет использовать RTTI для создания экэмпляров.

Э... Однобокий у тебя взгляд какой-то. Просто таки просвечивает С++.
Какой RTTI? (кстати в дотнете это называется рефлексия)
Зачем оно тут?
Мы ведь о языках говорим, а не о их рантаймах.

Нам нужно удобно и просто работать с конструкторами. Конечно на конструктор можно смотреть как угодно. Можно думать о нем как об инмперативной конструкции меняющей биты у объекта. Еще можно вести речь о каких то там операторах new которые выделяют память и вызвают этот императивный метод. Конечно можно! Но нужно ли?
У нас есть задача — создать объект имея некоторую входную информацию. Функция справится с этой задачей на ура. При этом мы можем мыслить о создании объекта как об атомарной операции.

VD>>Теперь, что касается статических методов и свободных фенкций. Формально вдотнете нет свободных функций. И вообще — это терминология C++. Однако можно просто считатические методы и свободные функции синонимами так как если абстрагироваться от деталей, классы для статических методов скорее служат для целей выделения пространств имен/модулей. Так что по фигу как их называть.

М>"Не плоди сущности без необходимости".

Тфу, ты. Как будто в богадельню попал.
Отче, какие сущности? Есть платформа, есть используемая ею терминология.
Хочешь понимать о чем говорят и чтобы тебя понимали — изучи эту терминологию и придерживайся ее.

М> Экзэмплярный метод должен иметь (и имеет) полный доступ к экзэмпляру, с учётом ограничений видимости. Классовый метод должен иметь полный доступ, с теми-же ограничениями, к информации класса, к его RTTI. А если это свободная функция, то она ею должна быть. А если это класс, то он и должен быть классом, а не пространством имён. Но всё это моё чистое IMHO, без претензий на высшую истину.

Так С++ с его RTTI идет лесом на этом форуме. Ты пришел в другую компанию. Будь добр принять ее правила и традиции.

Нет в дотнете свободных функций. Тот же C++/CLI эмулирует их создавая невидимые классы и объявляя в них статические методы. RTTI в дотнете тоже нет. Вместо него System.Reflection который позволяет получать информацию о любом типа до которого только можно дотянуться.

VD>>Просто, какое-то "Горе от ума".

М>Извините, что сдуру вмешался в вашу высоинтеллектуальную дискуссию.

А, ну, да. Жаль, что ты реально это так и не понял. Дискуссия и правда высокоинтеллектуальная в том плане, что обсуждаются весьма не тривиальные вопросы вывода типов. Если бы ты знал насколько это нетривиальная задача, то вряд ли стал бы иронизировать.

Извини если покажусь надменным, но позволю дать тебе один совет. "Козьма Прутков" говорил — "Специалист подобен флюсу: полнота его односторонняя". Вот ты похоже специалист в С++. Но других вещей в жизни не видел и пытаешься судить о вещах с колокольни С++. Точнее на уровне бито/байто дробления. Меж тем есть множество других весьма увлекательных миров. Есть ФП в котором функция является объектом в большей степени нежели объектом является экземпляр класса в С++. Есть дотнет в котором есть рефлексия по сравнению с которой RTTI кажется недоразумением. Так вот нельзя все мерить одной линейкой С++ (или чего-бы то ни было). Надо изучить и понять концепции этих разных миров, изучить их терминологию, и тогда можно будет судить об "высокоинтеллектуальных" беседах более осмысленно. А так. Влез. Брякнул что-то и пошел дальше в полной уверенности что вокруг стадо баранов не понимающих как устроен мир.

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

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

VD>>Так что если это и баг, то в другом месте.
VD>>К рассматриваемому вопросу вывода типов конструкторов это отношения не имеет.

N>Тем не менее это показывает, что в компиляторе C# предпочитают выделять ресурсы на то, чтобы поддерживать уровень багов на низком уровне, чем на добавление множества новых фич.

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

А уж что касается стандарта языка, так я знаю одного молоца который прям таки застыдил Хейльсберга.

N>Немерле — это экспериментальный язык, и он может позволить себе гораздо больше новых фич

А я не говорю про гораздо больше. Я говорю о совсем одной и не очень уж и навороченной. Я конечно мог бы порассуждать на тему того, что при наличии готового алгоритма отдающегося под лицензией BSD ребятам из МС могли бы тупо содрать его и довести до ума. Но я понимаю, что это сверхзадача. Я говорю о совсем простом. О том, что фактически уже сделано. Остается сделать еще один шаг и применить имеющийся функционал не только к статическим методам, но и к конструкторам.

N>(разумеется, ценой уменьшения качества, стабильности и скорости компиляции).

Ты меня прости, но качество C# имеет так себе. Компилятор у него уже давно стал write-only.
Дайте мне пятую часть тех средств, что вкладывается в C# я тебе гарантирую, что стабильность, качество и скорость этого "экспериментального" языка будут как минимум не хуже чем у "промышленного".

Да и фич в немерле не сильно то больше. Просто его в отличии от C# серьезно проектировали с нуля как целостный язык, а не создали как язык у других но с событиями и свойствами, а потом начали прикручивать фичи.

N>Наиболее полезные фичи рано или поздно перекочуют в мейнстримовые языки (после написания документации, шлифовки и тщательного тестирования).

Я тоже так раньше думал. Теперь почти уже уверен в том, что этого никогда не будет. Ну, или будет после моего ухода на пенсию. Так что я все больше и больше укрепляюсь в мысли, что проще довести до ума немерле.

Думаю, что за время пока в шарп будут добавлять полноценный вывод типов, я успею сделать n2 который будет сразу проектироваться не как студенческая работа, а как промышленное решение и которому с точки зрения расширяемости будут завидовать Nemerle, Lisp и Perl 6.

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

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

VD>Думаю, что за время пока в шарп будут добавлять полноценный вывод типов, я успею сделать n2 который будет сразу проектироваться не как студенческая работа, а как промышленное решение и которому с точки зрения расширяемости будут завидовать Nemerle, Lisp и Perl 6.

Ну так выложи на сайт Roadmap, повесь кнопочку Donate, и глядишь — потекут деньги от благодарных пользователей.

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

N>Ну так выложи на сайт Roadmap,

Это надо, конечно, сделать

N>повесь кнопочку Donate, и глядишь — потекут деньги от благодарных пользователей.

Мечтать не вредно .

На Donate не могут жить даже популярные проекты. А уж мы и подавно.

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

VD>Ты предлагал не рассматривать его как ординарную функцию. А как раз это решает тучу проблем.

Я не знаю, как Вы это поняли, но я как раз предлягал рассматривать конструктор вообще не как конструктор, а как инициализатор. И тогда для вызова конструктора, существующего для любого типа в единственном числе, будет достаточно иметь ссылку на метакласс. На типизированную переменную "type". И именно с точки зрения языка, абстрагируясь от реализации. И никаких проблем с неодназначностью, и никаких проблем с выводом типов, ибо с этим вполне справятся уже существующий механизм. И с обратной совместимостью тоже никаких проблем.

VD>Э... Однобокий у тебя взгляд какой-то. Просто таки просвечивает С++.
VD>Какой RTTI? (кстати в дотнете это называется рефлексия)
VD>Зачем оно тут?
VD>Мы ведь о языках говорим, а не о их рантаймах.

RTTI — это RunTime Type Information, если что. Оно не может называться рефлексией, даже в NET, просто потому, что оно — информация, данные, обобщённый термин. А рефлексия — механизм работы с этой самой информацией. Это к вопросу о терминологии.

VD>Нам нужно удобно и просто работать с конструкторами. Конечно на конструктор можно смотреть как угодно. Можно думать о нем как об инмперативной конструкции меняющей биты у объекта. Еще можно вести речь о каких то там операторах new которые выделяют память и вызвают этот императивный метод. Конечно можно! Но нужно ли?
VD>У нас есть задача — создать объект имея некоторую входную информацию. Функция справится с этой задачей на ура. При этом мы можем мыслить о создании объекта как об атомарной операции.

Зачем обязательно приплетать функции к объектам там, где вполне безболезненно можно остаться в рамках объектного подхода? Вы хотите иметь возможность передавать конструктор в функцию, а я считаю это не нужным, а нужно дать полноценный метакласс, возможность объявлять переменную — ссылку на метакласс, использовать эту переменную в вызове New, и тогда эту самую переменную можно будет передавать параметром в любую функцию, какую Вам захочется. Ну вот такое вот моё личное скромное мнение.

VD>Извини если покажусь надменным, но позволю дать тебе один совет.

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

Здравствуйте, Мизантроп, Вы писали:

М>Зачем обязательно приплетать функции к объектам там, где вполне безболезненно можно остаться в рамках объектного подхода? Вы хотите иметь возможность передавать конструктор в функцию, а я считаю это не нужным, а нужно дать полноценный метакласс, возможность объявлять переменную — ссылку на метакласс, использовать эту переменную в вызове New, и тогда эту самую переменную можно будет передавать параметром в любую функцию, какую Вам захочется. Ну вот такое вот моё личное скромное мнение.

Ну, что же. Каждый волен иметь свое мнение.

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

VD>Паттерн "Фабричный метод" пользуется таким представлением дляя инкапсуляции логики создания объекта.
VD>Так почему же нельзя рассматривать и обычные конструктораы подобным образом?

Из-за особенностей CLR, наверно.

VD>Что же это дает?
VD>...

Да понятно все и взято из практики языков с алгебраическими типами, где селектор типа используется как имя функции-конструктора типа. Здесь тоже нечто вроде подобного сугубо синтаксического выверта. Вместо всего этого потока слов можно было согласиться, что да, используется не непосредственно конструктор из CLR, а некая оберточная ф-ия, делающая new с этим конструктором.

---------
А вообще, жестокая завязка системы типов CLR сугубо на объектную модель, это такой мега-сакс, что портит массу остальных достоинств платформы. От того и возникают подобные перетирания мелочей. 1-в-1 копировать Яву вовсе не стоило.

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

VD>Думаю, что за время пока в шарп будут добавлять полноценный вывод типов, я успею сделать n2 который будет сразу проектироваться не как студенческая работа, а как промышленное решение и которому с точки зрения расширяемости будут завидовать Nemerle, Lisp и Perl 6.

Да подожди ты, блин. Дай линк дописать, потом мы их всех порвём

Здравствуйте, Мизантроп, Вы писали:

М>Я не знаю, как Вы это поняли, но я как раз предлягал рассматривать конструктор вообще не как конструктор, а как инициализатор. И тогда для вызова конструктора, существующего для любого типа в единственном числе, будет достаточно иметь ссылку на метакласс. На типизированную переменную "type". И именно с точки зрения языка, абстрагируясь от реализации. И никаких проблем с неодназначностью, и никаких проблем с выводом типов, ибо с этим вполне справятся уже существующий механизм. И с обратной совместимостью тоже никаких проблем.
Это всё как раз понятно. Но с точки зрения потребителя получается некоторая несимметрия. "Пользовательская" функция static Foo NewFoo(int arg) будет работать как функция, а "инициализатор", который имеет точно такую же семантику, будет работать через какой-то там "метакласс".
Влад предлагает отвлечься от излишних подробностей и рассматривать конструкторы как частный случай порождающей функции.

М>Зачем обязательно приплетать функции к объектам там, где вполне безболезненно можно остаться в рамках объектного подхода? Вы хотите иметь возможность передавать конструктор в функцию, а я считаю это не нужным, а нужно дать полноценный метакласс, возможность объявлять переменную — ссылку на метакласс, использовать эту переменную в вызове New, и тогда эту самую переменную можно будет передавать параметром в любую функцию, какую Вам захочется. Ну вот такое вот моё личное скромное мнение.
Тогда в эту "любую" функцию нельзя будет передать альтернативную порождающую функцию (которая, к примеру, возвращает закешированный экземпляр вместо нового).

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

S>Здравствуйте, Мизантроп, Вы писали:

М>>Я не знаю, как Вы это поняли, но я как раз предлягал рассматривать конструктор вообще не как конструктор, а как инициализатор. И тогда для вызова конструктора, существующего для любого типа в единственном числе, будет достаточно иметь ссылку на метакласс. На типизированную переменную "type". И именно с точки зрения языка, абстрагируясь от реализации. И никаких проблем с неодназначностью, и никаких проблем с выводом типов, ибо с этим вполне справятся уже существующий механизм. И с обратной совместимостью тоже никаких проблем.
S>Это всё как раз понятно. Но с точки зрения потребителя получается некоторая несимметрия. "Пользовательская" функция static Foo NewFoo(int arg) будет работать как функция, а "инициализатор", который имеет точно такую же семантику, будет работать через какой-то там "метакласс".
S>Влад предлагает отвлечься от излишних подробностей и рассматривать конструкторы как частный случай порождающей функции.

Семантику как раз менять не надо. Инициализатор сейчас имеет семантику конструктора, пусть так и остаётся, только добавить возможность объявлять его виртуальным. То есть нечто вроде такого:

class Foo
{
    virual Foo(){}
}
class Bar: Foo
{
    override Bar(): Base(){}
}
metaclass FooClass: Foo;
FooClass fc = Foo;
Foo Instance = new fc(); // создали экзэмпляр Foo
fc = Bar;
Instance = new fc(); // создали экзэмпляр Bar

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

S>Тогда в эту "любую" функцию нельзя будет передать альтернативную порождающую функцию (которая, к примеру, возвращает закешированный экземпляр вместо нового).

Почему? Что мешает передать вышеуказанную fc в какую угодно функцию, либо сохранить в любом поле? Дело в том, что при передаче в функцию конструктора всё равно придётся скрыто передавать в неё и информацию о типе, иначе в функции просто невозможно будет сконструировать объект. Для его конструирования просто необходимо иметь информацию о размере объекта, чтобы выделить под него память, и реальный тип объекта, чтобы сохранить в нём ссылку на его метаинформацию. То есть по любому потребуется тот-же самый метакласс, иначе никак. Так зачем нужна лишняя сущность — конструктор — которая к тому-же ограничивает возможности?

Здравствуйте, Мизантроп, Вы писали:
М>При таком вызове и у компилятора, и у рантайма будет абсолютно вся необходимая информация для создания объекта. Единственное, что этому мешает — идеалогия. Ну как же, как конструктор может быть виртуальным? Но дело-то в том, что этот самый конструктор нигде и никогда таковым не был, а следовательно и препятствие надуманное.
Вся эта идеология уже была в полный рост освоена автором шарпа в его предыдущем языке.

S>>Тогда в эту "любую" функцию нельзя будет передать альтернативную порождающую функцию (которая, к примеру, возвращает закешированный экземпляр вместо нового).

М>Почему? Что мешает передать вышеуказанную fc в какую угодно функцию, либо сохранить в любом поле?
ОМГ. Показываю, в чём особенность:

public void Consumer(FooFactory f)
{
  var foo = f();
}

Мы хотим уметь передавать консумеру
а) ссылку на "конструктор" Foo
б) ссылку на произвольную функцию, возвращающую Foo.
Чем ты заменишь "вышеуказанную fc" для случая альтернативной порождающей функции, которая, к примеру, возвращает закешированный экземпляр вместо нового?
Если мы считаем конструктор обычным статиком, то тип FooFactory — это всего лишь синоним для Function<Foo>.


М> Дело в том, что при передаче в функцию конструктора всё равно придётся скрыто передавать в неё и информацию о типе, иначе в функции просто невозможно будет сконструировать объект. Для его конструирования просто необходимо иметь информацию о размере объекта, чтобы выделить под него память, и реальный тип объекта, чтобы сохранить в нём ссылку на его метаинформацию.
Ты лезешь в дебри. Всё это прячется внутрь замыкания.

М>То есть по любому потребуется тот-же самый метакласс, иначе никак. Так зачем нужна лишняя сущность — конструктор — которая к тому-же ограничивает возможности?
Хм. С точки зрения ФП, как раз "метакласс" является лишней сущностью, которая стоит совершенно обособленно от всех остальных "плоских функций".

Здравствуйте, Мизантроп, Вы писали:

М>При таком вызове и у компилятора, и у рантайма будет абсолютно вся необходимая информация для создания объекта. Единственное, что этому мешает — идеалогия. Ну как же, как конструктор может быть виртуальным? Но дело-то в том, что этот самый конструктор нигде и никогда таковым не был, а следовательно и препятствие надуманное.

Это уже сейчас есть, рефлекшн называется. Метакласс это тип.

S>>Тогда в эту "любую" функцию нельзя будет передать альтернативную порождающую функцию (которая, к примеру, возвращает закешированный экземпляр вместо нового).

М>Почему? Что мешает передать вышеуказанную fc в какую угодно функцию, либо сохранить в любом поле? Дело в том, что при передаче в функцию конструктора всё равно придётся скрыто передавать в неё и информацию о типе, иначе в функции просто невозможно будет сконструировать объект. Для его конструирования просто необходимо иметь информацию о размере объекта, чтобы выделить под него память, и реальный тип объекта, чтобы сохранить в нём ссылку на его метаинформацию. То есть по любому потребуется тот-же самый метакласс, иначе никак. Так зачем нужна лишняя сущность — конструктор — которая к тому-же ограничивает возможности?

А вот если бы это была функция (нет ничего, что мешает ей стать таковой), то ей можно было бы манипулировать как функцией. Метакласс же сам по себе ничего не может, для него требуется инфраструктура.

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

S>Вся эта идеология уже была в полный рост освоена автором шарпа в его предыдущем языке.

А я и не претендую на новизну. Но мне вот как-то не удалось найти ни одного внятного или хотя-бы полувнятного обоснования, чем она плоха. Похоже, чистый маркетинг, стремление максимальной похожести на Си.

S>>>Тогда в эту "любую" функцию нельзя будет передать альтернативную порождающую функцию (которая, к примеру, возвращает закешированный экземпляр вместо нового).

М>>Почему? Что мешает передать вышеуказанную fc в какую угодно функцию, либо сохранить в любом поле?
S>ОМГ. Показываю, в чём особенность:
S>

S>public void Consumer(FooFactory f)
S>{
S>  var foo = f();
S>}
S>

S>Мы хотим уметь передавать консумеру
S>а) ссылку на "конструктор" Foo
S>б) ссылку на произвольную функцию, возвращающую Foo.
S>Чем ты заменишь "вышеуказанную fc" для случая альтернативной порождающей функции, которая, к примеру, возвращает закешированный экземпляр вместо нового?
S>Если мы считаем конструктор обычным статиком, то тип FooFactory — это всего лишь синоним для Function<Foo>.

А зачем его чем-то заменять? Вы написали метод Consumer, принимающий параметром фабричную функцию, ну так и передавайте ему фабричную функцию, либо создающую новый экзэмпляр, либо берущий его из кэша. В чём проблема? Нет, ну я похоже действительно что-то не понимаю, но в чём будет выигрыш, ради которого есть смысл смешивать здесь объектный и функциональный подход?

М>> Дело в том, что при передаче в функцию конструктора всё равно придётся скрыто передавать в неё и информацию о типе, иначе в функции просто невозможно будет сконструировать объект. Для его конструирования просто необходимо иметь информацию о размере объекта, чтобы выделить под него память, и реальный тип объекта, чтобы сохранить в нём ссылку на его метаинформацию.
S>Ты лезешь в дебри. Всё это прячется внутрь замыкания.

Ну прячется, и что с того? Почти везде что-нибудь где-нибудь да прячется. Сохраняя метакласс с пятью конструкторами, мы можем далее вызывать по мере надобности любой из них. А сохранив делегат с конструктором, мы оказываемся жёстко привязаны к этому конструктору, и придётся хранить пять делегатов. Просто мне непонятно это стремление засунуть функциональщину куда надо и не надо. Функциональный подход, без сомнения, имеет свои сильные стороны, но господа, надо-же и меру знать

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

М>>То есть по любому потребуется тот-же самый метакласс, иначе никак. Так зачем нужна лишняя сущность — конструктор — которая к тому-же ограничивает возможности?
S>Хм. С точки зрения ФП, как раз "метакласс" является лишней сущностью, которая стоит совершенно обособленно от всех остальных "плоских функций".

А объект, о чьём конструировании мы ведём речь, есть порождение объектного подхода, а не функционального.Для него "чужеродна" как раз функциональщина, и применять её стоит там, где от этого будет действительно реальный выиграш, не достижимый в рамках объектного подхода.