Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dotneter, Вы писали:
D>>adontz вроде предлагает не делать два типа, компилятор смотрит есть ли структурный интерфейс IPropertyBarMethodFoo, если есть использует, если нет генерит.
VD>Подумайте на досуге что делать при наличии двух сборок в которых уже сгенерированны и использованы разные типы.
Использовать Type Equivalence. http://stackoverflow.com/questions/3290544/can-we-use-typeidentifierattribute-in-net-without-com
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[12]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, jazzer, Вы писали:
FR>>>просто не скомпилируется, ну и другие подобные шаблонные ошибки невозможны. J>>ну, вообще-то, в С++ этот код тоже не скомпилируется
FR>В сферическом С++ возможно, но VC 2010 и мой "любимый" bcc без писка кушают
не в сферическом, а в стандартном.
J>>причем именно потому что функция not_exist_func неизвестна
FR>Да gcc так и говорит.
Естественно, потому что так по стандарту положено.
test.cpp:4: error: there are no arguments to 'not_exist_func' that depend on a template parameter, so a declaration of 'not_exist_func' must be available
test.cpp:4: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
И Comeau точно так же говорит:
"ComeauTest.c", line 4: error: identifier "not_exist_func" is undefined
Это просто очередная мелкософтовская бага:
The compiler does not implement two-phase name lookup for templates.
причем я так и не понял, собираются ли они ее фиксить Не надо их баги распространять на весь язык.
Ну а bcc — это вообще за гранью.
FR>Но все-таки шаблонная и обычная функция в C++ вещи разные, в отличии от окамла.
Это да, в С++ шаблонных функций (как и шаблонных классов) вообще не существует (если заниматься буквоедством), существуют шаблоны функций и классов. Это, в частности, выражается в том, что нельзя завести указатель на шаблоную функцию в целом, только на ее конкретное инстанцирование.
Но с точки зрения отношения к объявленным именам там все просто и согласовано: все использованные имена, которые не зависят от шаблонных параметров, должны быть объявлены к моменту использования в твоей функции. Всё.
В случае обычных функций/класов, так как шаблонных параметров нет, это, очевидно, вообще все имена.
FR>Тут не понял, если они у нас используются будет вывод типов тут никакой завязки на вызов друг друга нет.
я имею в виду, если у нескольких функций одинаковые (и, возможно, сложные) ограничения на аргументы — не копи-пейстом же их размножать
Здравствуйте, jazzer, Вы писали:
J>причем я так и не понял, собираются ли они ее фиксить Не надо их баги распространять на весь язык.
В теории да, на практике приходится учитывать.
J>Ну а bcc — это вообще за гранью.
template <typename T>
void dummy(T t)
{
(* Зато на bcc в шаблонах, если их не инстанцировать, можно писать на ocaml *)
let x = 123;
}
int main()
{
}
FR>>Но все-таки шаблонная и обычная функция в C++ вещи разные, в отличии от окамла. J>Это да, в С++ шаблонных функций (как и шаблонных классов) вообще не существует (если заниматься буквоедством), существуют шаблоны функций и классов. Это, в частности, выражается в том, что нельзя завести указатель на шаблоную функцию в целом, только на ее конкретное инстанцирование.
В реальных компиляторах различий гораздо больше, и они как раз проявляются в диагностике ошибок.
J>Но с точки зрения отношения к объявленным именам там все просто и согласовано: все использованные имена, которые не зависят от шаблонных параметров, должны быть объявлены к моменту использования в твоей функции. Всё. J>В случае обычных функций/класов, так как шаблонных параметров нет, это, очевидно, вообще все имена.
Угу, но из массовых компиляторов только gcc эти правила соблюдает.
FR>>Тут не понял, если они у нас используются будет вывод типов тут никакой завязки на вызов друг друга нет. J>я имею в виду, если у нескольких функций одинаковые (и, возможно, сложные) ограничения на аргументы — не копи-пейстом же их размножать
А зачем их явно выражать-то? Компилятор сам со всем справляется.
Если нет очень жесткой типизации и вывода типов, да явные ограничения необходимость, иначе они нужны редко и обычно только на уровне модулей.
Re[12]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, FR, Вы писали:
J>>Ну а bcc — это вообще за гранью.
FR>
FR>(* Зато на bcc в шаблонах, если их не инстанцировать, можно писать на ocaml *)
FR>let x = 123;
FR>
FR>Угу, но из массовых компиляторов только gcc эти правила соблюдает.
Еще EDG (фронт-енд) и все, кто его использует, например, Comeau, Intel.
Еще Clang, который на LLVM
Clang was designed with complete support for two-phase name lookup
http://blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.html
J>>я имею в виду, если у нескольких функций одинаковые (и, возможно, сложные) ограничения на аргументы — не копи-пейстом же их размножать
FR>А зачем их явно выражать-то? Компилятор сам со всем справляется. FR>Если нет очень жесткой типизации и вывода типов, да явные ограничения необходимость, иначе они нужны редко и обычно только на уровне модулей.
Ну ты вон описывал, что должна быть функция put с двумя параметрами.
let f o = 1 + o#put 2 2
А теперь пусть нам нужно наложить не одно условие относительно того, какие методы должны быть в классе, а десяток. Как это будет выглядеть?
А теперь пусть у нас будет не одна функция с таким набором требований, а семейство из дюжины таких фукнций. Как это будет выглядеть?
А теперь пусть нам понадобилось добавить одиннадцатое условие во все эти функции. Как? И насколько это будет удобно?
FR>>А зачем их явно выражать-то? Компилятор сам со всем справляется. FR>>Если нет очень жесткой типизации и вывода типов, да явные ограничения необходимость, иначе они нужны редко и обычно только на уровне модулей.
J>Ну ты вон описывал, что должна быть функция put с двумя параметрами. J>
J>let f o = 1 + o#put 2 2
J>
J>А теперь пусть нам нужно наложить не одно условие относительно того, какие методы должны быть в классе, а десяток. Как это будет выглядеть? J>А теперь пусть у нас будет не одна функция с таким набором требований, а семейство из дюжины таких фукнций. Как это будет выглядеть? J>А теперь пусть нам понадобилось добавить одиннадцатое условие во все эти функции. Как? И насколько это будет удобно?
Ты не понял, в большинстве случаев функция будет выглядеть именно так let f o = 1 + o#put 2 2 и больше никаких описаний, вывод типов
позволяет их не делать.
Я вообще не понимаю зачем нужны явные ограничения (кроме стандартизации интерфейсов на уровне модулей) для языка с жесткой типизацией и
сильным выводом типов. Ничего кроме раздувания кода это не дает, ошибки типизация прекрасно ловит и без явного описания ограничений.
Если же нам вдруг потребуется явный интерфейс, то никаких проблем добавить:
class type my_interface =
object
method put : int -> int -> int
end
и изменить функцию на
let f (o : my_interface) = 1 + o#put 2 2
Re[5]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, dotneter, Вы писали:
D>Насколько я понял, в scala это работает через рефлексию. Сигнатура получается вида D>
D>public void inTheForest(Object duck)
D>
D>Хотя на первый взгляд что мешало генерировать интерфейсы и делать враперы их реализующие?
На второй взгляд рефлексия похоже оптимальный вариант, осталось придумать как сделать что бы перфоманс не просидал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[14]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, dotneter, Вы писали:
D>Не будет обобщеных структурных типов, делов то.
Это весьма неприятное ограничение. Да и то что можно только интерфейсы использовать снизит производительность таких решений. С кортежами они уже посоревноваться не смогут.
В общем, конечно наличие структурной эквивалентности для не дженерик-интерфейсов конечно лучше чем полная ее отсутствие, но все же это не лучшее подспорье.
Кроме того проблема сопоставления интерфейса с типом который его не реализует остается. Она тоже обходится очень некрасиво и приводит к существенному снижению производительности (для случаев критичных к ней).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, dotneter, Вы писали:
D>Не обязательно их использовать для числодробления, вот в шарпе есть dynamic, все понимают что медленно и используют там где не критично.
Вот это я и называю кривостью языка, когда для преодоления ограничений языка приходится использовать не подходящие для этого возможности этого языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, VladD2, Вы писали:
VD>И если может, насколько при этом такой язык будет "своим" в этих рантаймах?
Очевидно, своим не будет, т.е. метаинформацию этих типов надо будет описывать самим и таскать вместе с бинарными либами (рядом, либо в ресурсах оных). Как пример можно посмотреть "предкомпиленные" либы Хаскеля или даже банально h-файлы C++/CLR, содержащие описания шаблонных типов (в этом диалекте С++ генерики могут сосуществовать с шаблонами, что дает возможности для интересных комбинаций в целях кодогенерации).
VD>И чем придется платить за совместимость (подозреваю, что производительностью)?
Если ограничить это всё только временем компиляции, то придется платить лишь своим форматом метаинформации, т.е. практически ничем. Если же речь о динамике, то чем оно будет лучше скриптовых языков, со всеми вытекающими?
Re[2]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, vdimas, Вы писали:
V>Очевидно, своим не будет, т.е. метаинформацию этих типов надо будет описывать самим и таскать вместе с бинарными либами (рядом, либо в ресурсах оных).
Дык таскай не таскай, а как обходить ограничения дотнетной системы типов? Структурные типы представлять всегда кортежами? Но это значит придется отказаться от защиты данных и быть не совместимыми с типами дотнета.
V>Как пример можно посмотреть "предкомпиленные" либы Хаскеля или даже банально h-файлы C++/CLR, содержащие описания шаблонных типов (в этом диалекте С++ генерики могут сосуществовать с шаблонами, что дает возможности для интересных комбинаций в целях кодогенерации).
С++ не компонентный. В нем все метаданные всегда берутся из исходников. На счет Хаскеля не скажу. Там наверно есть бинарные метаданные.
VD>>И чем придется платить за совместимость (подозреваю, что производительностью)?
V>Если ограничить это всё только временем компиляции, то придется платить лишь своим форматом метаинформации, т.е. практически ничем. Если же речь о динамике, то чем оно будет лучше скриптовых языков, со всеми вытекающими?
Кроме динамики и времени компиляции еще есть компонентность, т.е. когда все в бинарном виде и статически типизировано, но при этом допускается вольная интерпретация типов.
Опять же обращаюсь за примером к Go. Любой его тип может быть приведен к интерфейсу, если тип реализует методы этого интерфейса (с теми же именами и сигнатурами).
Если писать рантайм с нуля (или хотя бы иметь возможность его изменять), то не трудно доработать его так, чтобы такое приведение не давало сильного оврехэда. Если в зять к примеру рантайм дотнета, то можно тупо расширять список интерфейсов конкретного класса в рантайме. Скажем потребовалось привести класс A к интерфейсу IX. При первом приведении рантайм проверяет структурную эквивалентность и расширяет таблицу интерфейсов класса A включая в нее ссылку на IX. При следующих обращениях все будет работать с той же скорость как будто этот интерфейс реализован в А явно. Но для этого нужно иметь доступ к рантайму. Насколько я знаю дотнет там подхачить не удастся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, VladD2, Вы писали:
VD>Если писать рантайм с нуля (или хотя бы иметь возможность его изменять), то не трудно доработать его так, чтобы такое приведение не давало сильного оврехэда. Если в зять к примеру рантайм дотнета, то можно тупо расширять список интерфейсов конкретного класса в рантайме. Скажем потребовалось привести класс A к интерфейсу IX. При первом приведении рантайм проверяет структурную эквивалентность и расширяет таблицу интерфейсов класса A включая в нее ссылку на IX. При следующих обращениях все будет работать с той же скорость как будто этот интерфейс реализован в А явно. Но для этого нужно иметь доступ к рантайму. Насколько я знаю дотнет там подхачить не удастся.
А что мешает такого поведения добиться с рантаймовой кодогенерацией?
А в nemerle и в compile-time можно генерировать обертки.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>А что мешает такого поведения добиться с рантаймовой кодогенерацией? VD>А есть возможность в рантайме прилепить реализацию интерфейса к типу?
Нет, зато есть возможность сгенерить wrapper.
G>>А в nemerle и в compile-time можно генерировать обертки. VD>В компайлтайме нельзя менять уже скомпилированные сборки.
Снова wrapper.
G>>Примерно как тут: http://clay.codeplex.com/ VD>Сорри, но это фигня какая-то. Причем тут динамик и проблемы C#-а?
Разберись прежде чем говорить.
Re[6]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, gandjustas, Вы писали:
G>Нет, зато есть возможность сгенерить wrapper.
Для этого рантайм не нужен. Но у оберток есть очевидные недостатки. Во-превых, как любая прослойка она будет жрать производительность (особенно когда речь идет о примитивных типах), во-вторых встает проблема прозрачности ссылок (ведь ссылка на обертку не равна ссылке на объект).
G>>>Примерно как тут: http://clay.codeplex.com/ VD>>Сорри, но это фигня какая-то. Причем тут динамик и проблемы C#-а? G>Разберись прежде чем говорить.
Честно говоря, разбираться во всех фигне что есть в Интернете желания нет. Описание на первой странице не внятное. Из него следует, что они что-то там на безе "динамик" предлагают. Меня скриптовые технологии ни разу не интересуют. Если я что-то понял не так, то поясни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, FR, Вы писали:
FR>Я вообще не понимаю зачем нужны явные ограничения (кроме стандартизации интерфейсов на уровне модулей) для языка с жесткой типизацией и сильным выводом типов. Ничего кроме раздувания кода это не дает, ошибки типизация прекрасно ловит и без явного описания ограничений.
Это ты заблуждаешься. Ограничения несомненно нужны. Чем больше проект, тем важнее ограничения.
Вообще вопрос: наличия аннотаций типов vs. вывод типов — это очень тонкий и многоаспектный вопрос. Пописав на языке с выводом типов и сделав для него интеграцию с IDE я многое понял. К сожалению все мысли трудно изложить в маленьком сообщении, но вывод мой таков — публичный интерфейс нужно аннотировать. Так же аннотации типов не помешают и внутри кода. Иногда без них тяжело понять суть происходящего. Спасают IDE которые позволяют видеть типы во всплывающих подсказках и т.п.
Однако и засилье аннотаций типов тоже вредит. Иногда код от них распухает, так что за деревьями становится не видно леса.
Так что надо соблюдать баланс. Лично я пришел к выводу, что имеет смысл аннотировать параметры локальных функций (в добавок к публичному интерфейсу), если это не приводит к замусориванию кода. Иногда достаточно частичной аннотации. Это повышает читаемость, делает сообщения об ошибках боле внятными и улучшает интеллисенс.
FR>Если же нам вдруг потребуется явный интерфейс, то никаких проблем добавить:
FR>
FR>class type my_interface =
FR> object
FR> method put : int -> int -> int
FR> end
FR>
FR>и изменить функцию на
FR>
FR>let f (o : my_interface) = 1 + o#put 2 2
FR>
А в таком случае, в ОКамле, можно вместо my_interface передать структурно-совместимый с my_interface тип?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, dotneter, Вы писали:
D>Тоесть, давайте выкинем все движки aop работающие на враперах, из-за того что нельзя вызвать GetType? Да есть такое ограничение, нужно о нем узнать один раз и больше GetType не вызывать.
Чем больше невнятных (не интуитивных) ограничений, тем хуже язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Может ли в .Net жить язык со структурной типизацией?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dotneter, Вы писали:
D>>Тоесть, давайте выкинем все движки aop работающие на враперах, из-за того что нельзя вызвать GetType? Да есть такое ограничение, нужно о нем узнать один раз и больше GetType не вызывать.
VD>Чем больше невнятных (не интуитивных) ограничений, тем хуже язык.
Да, лучше быть здоровым и богатым, кто же спорит. Можно еще компилятором отслеживать вызов у враперов GetType и выдавать ошибку. Все сценарии не покроет, но как вариант.
Не надо их баги распространять на весь язык.
