Господа, просветите пожалуйста на такую тему:
У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)
При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.
Тем не менее, на обе платформы более-менее успешно портируются разные языки, изначально для этих платформ не предназначенные (хотя бы IronPython, Jython, J#, JScript.Net, F#, та же Scala изначально работала на обеих платформах).
Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
Спасибо.
FAQ — це мiй ай-кью!
Re: Совмещение разных объектных моделей на одном фреймворке
ЗХ>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
на столько, насколько позволяет виртуальная машина.
а она, в общем, позволяет очень многое.
С Уважением Сергей Чикирев
Re[2]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, vladserge, Вы писали:
ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
V>на столько, насколько позволяет виртуальная машина. V>а она, в общем, позволяет очень многое.
Хоцца конкретики какой-то
FAQ — це мiй ай-кью!
Re: Совмещение разных объектных моделей на одном фреймворке
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
Возможно, чтобы ответить на этот вопрос, стоит начать с модификации Си++ для дотнета:
C++ --> Managed C++ --> C++/CLI. http://en.wikipedia.org/wiki/Managed_C%2B%2B http://en.wikipedia.org/wiki/C%2B%2B/CLI
Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI.
Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[2]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
AVC>Возможно, чтобы ответить на этот вопрос, стоит начать с модификации Си++ для дотнета: AVC>C++ --> Managed C++ --> C++/CLI. AVC>http://en.wikipedia.org/wiki/Managed_C%2B%2B AVC>http://en.wikipedia.org/wiki/C%2B%2B/CLI AVC>Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI. AVC>Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.
Я не думаю, что это хороший пример. C++/CLI это все же сильно измененный язык, и изменений требовала не только объектная модель, но и работа с памятью, например. Плюс к тому, насколько я понимаю, MS вообще не ставила задачу полностью сохранить аутентичность языка. И еще плюс к тому, насколько я могу судить, объектные модель дот-нета и плюсов ничем радикально не отличаются (хотя это, может быть, и слишком сильное утверждение).
FAQ — це мiй ай-кью!
Re[3]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Зверёк Харьковский, Вы писали:
AVC>>Насколько я понимаю, среди RSDN-щиков достаточно программистов, пишущих на Managed C++ или C++/CLI. AVC>>Пусть поделятся впечатлениями, насколько им пришлось (и пришлось ли) пересмотреть подход к ООП под влиянием изменений в языке.
ЗХ>Я не думаю, что это хороший пример. C++/CLI это все же сильно измененный язык, и изменений требовала не только объектная модель, но и работа с памятью, например. Плюс к тому, насколько я понимаю, MS вообще не ставила задачу полностью сохранить аутентичность языка. И еще плюс к тому, насколько я могу судить, объектные модель дот-нета и плюсов ничем радикально не отличаются (хотя это, может быть, и слишком сильное утверждение).
Собственно, я потому и предложил начать с Си++, что объектная модель у него родственная (поэтому казалось, что проще найти и понять различия между "чистым Си++" и "Си++ для дотнета" -- ограничения на множественное наследование и т.п.).
Но может быть, и правда лучше начать, наоборот, с языка, объектная модель которого принципиально отличается от дотнетовской.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[4]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Господа, просветите пожалуйста на такую тему: ЗХ>У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)
ЗХ>При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.
Не совсем так, все что там есть сначала компилируется в СIL/Java bytecode, это соответствует assembler'у (правда типизированному и объектно-ориентированному) в обычном (нативном) случае.
Все что они (СIL/Java bytecode) позволяют (а это довольно много) то можно сделать и в языке. С другой стороны для взаимодействия с другими языками в .NET надо соблюдать CLS (см. ниже).
ЗХ>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
Возможно стоит посмотреть на Common Language Specification для .NET, чтобы понять в каких рамках надо оставаться чтобы обеспечивать прозрачное взаимодействие с другими языками.
А так .NET достаточно гибкая платформа и механизмы рефлексии (System.Reflection и System.Reflection.Emit) позволяют делать динамические вызовы и динамически создавать классы, что нужно для Python,Ruby,Smalltalk...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Андрей Хропов, Вы писали:
ЗХ>>Господа, просветите пожалуйста на такую тему: ЗХ>>У многих ОО-языков разные ОО-модели (то есть, понятия о том что есть объект, класс, метод/сообщение, наследование и т.п. — и следующие из этого возможности)
ЗХ>>При этом, насколько я понимаю, платформа Java, платформа .Net имеют более-менее конкретную объектную модель, и предполагают, что все языки, работающие поверх этих платформ, должны исповедовать именно ее.
АХ>Не совсем так, все что там есть сначала компилируется в СIL/Java bytecode, это соответствует assembler'у (правда типизированному и объектно-ориентированному) в обычном (нативном) случае. АХ>Все что они (СIL/Java bytecode) позволяют (а это довольно много) то можно сделать и в языке. С другой стороны для взаимодействия с другими языками в .NET надо соблюдать CLS (см. ниже).
Угу, имелся в виду именно этот аспект.
ЗХ>>Вопрос в том, насколько такое портирование требует смены семантики языка? Или вопросы "совместимости объектных моделей" как-то по-другому решаются? Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
АХ>Возможно стоит посмотреть на Common Language Specification для .NET, чтобы понять в каких рамках надо оставаться чтобы обеспечивать прозрачное взаимодействие с другими языками.
АХ>А так .NET достаточно гибкая платформа и механизмы рефлексии (System.Reflection и System.Reflection.Emit) позволяют делать динамические вызовы и динамически создавать классы, что нужно для Python,Ruby,Smalltalk...
Во! То, что надо было. Огромное спасибо.
А у тебя нет опыта/сведений, во что это выливается на практике? (то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")
Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет"). Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.)
FAQ — це мiй ай-кью!
Re[3]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>А у тебя нет опыта/сведений, во что это выливается на практике?
Из .NET-языков я пишу только на C# и Nemerle, а они изначально создавались под эту платформу. На IronPython насколько я знаю запускается практически любой обычный Питоновский код (правда Psyco нет, что неудивительно). Про остальное не знаю.
ЗХ>(то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")
Ну больше всего проблем как я понимаю с C++, поэтому и пришлось создавать такого совершенно убийственного монстра как C++/CLI .
Ну вообще зависит от дизайна языка. Понятно что низкоуровневые языки с небезопасными фичами типа указателей (C/C++) практически невозможно сделать полностью managed. Также не слишком хорошо сочетаются с .NET не ОО-языки.
Зато хорошо портируются ОО-языки с GC .
ЗХ>Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет").
Ну как сказать... Если мы в C# пишем программу мы должны знать имена всех методов наперед, а эти имена берутся из метаданных уже скомпилированных сборок. Или же пользоваться Reflection, тогда да, мы можем вызывать произвольные методы по именам через InvokeMethod.
Впрочем я подробно не изучал этот вопрос, обратись лучше к разработчику RubyCLR (здесь). В частности я читал что для реализации Ruby используются dynamic methods.
ЗХ> Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.)
Наверное да. Впрочем внутри Integer вроде везде одинаковый (ну методы для него можно внутри языка иметь свои), а для String наверное можно cделать методы преобразовывающие его в стандартный. А вообще тебе наверное лучше напрямую посмотреть в исходниках/спросить у разработчиков IronPython или RubyCLR, например. IronPython вроде любой обычный питоновский код без изменений запускает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Андрей Хропов, Вы писали:
ЗХ>>(то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности") АХ>Ну больше всего проблем как я понимаю с C++, поэтому и пришлось создавать такого совершенно убийственного монстра как C++/CLI .
АХ>Ну вообще зависит от дизайна языка. Понятно что низкоуровневые языки с небезопасными фичами типа указателей (C/C++) практически невозможно сделать полностью managed. Также не слишком хорошо сочетаются с .NET не ОО-языки.
АХ>Зато хорошо портируются ОО-языки с GC .
Есть мнение, что ОО бывает разное (см., например, Self/Io)
То есть слова "ОО-язык" не исчерпывают всех вариаций которые могут быть. Объект моего интереса сейчас — операции с объектами, которые допустимы в одном .Net языке и недопустимы в другом, и как это работает на передаче через границы языков.
ЗХ>>Например, насколько я понимаю, динамические вызовы/динамическое изменение кода через границы языков должно быть сильно ограничено (если Руби в объекте полученном из C#, динамически добавит метод, C# этого "не поймет"). АХ>Ну как сказать... Если мы в C# пишем программу мы должны знать имена всех методов наперед, а эти имена берутся из метаданных уже скомпилированных сборок. Или же пользоваться Reflection, тогда да, мы можем вызывать произвольные методы по именам через InvokeMethod. АХ>Впрочем я подробно не изучал этот вопрос, обратись лучше к разработчику RubyCLR (здесь). В частности я читал что для реализации Ruby используются dynamic methods.
Спасибо. Это крайне полезная информация.
ЗХ>> Кроме того, видимо, должны возникать проблемы с языками, которые "приходят на платформу" со своей стандартной библиотекой (даже, точнее, не стандартной библиотекой, а своим пониманием core objects вроде Object, String, Integer и проч.) АХ>Наверное да. Впрочем внутри Integer вроде везде одинаковый (ну методы для него можно внутри языка иметь свои), а для String наверное можно cделать методы преобразовывающие его в стандартный. А вообще тебе наверное лучше напрямую посмотреть в исходниках/спросить у разработчиков IronPython или RubyCLR, например. IronPython вроде любой обычный питоновский код без изменений запускает.
Ну, понятно что я провожу параллельные исследования в инете и в документации соответствующих проектов. Но обращение к коллективному разуму РСДН тоже приносит свои плоды.
Например, до даденных тобой в этом и предыдущем сообщении ссылок я бы сам докопался нескоро.
В общем, спасибо за помощь!
FAQ — це мiй ай-кью!
Re: Совмещение разных объектных моделей на одном фреймворке
Зверёк,
ЗХ>Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
Скажу про JVM. JVM заточена под безопасные объектно-ориентированные языки. Заточка заключается в том, что JIT надрессирован на распознавание типичных паттернов кода, которые появляются в типичной программе на Java и GC, который тоже ориентирован на типичные сценарии работы с объектами. И если новый язык чуть-чуть вылазит за эти рамки, то будут проблемы (прежде всего с перфомансом).
1. Семантика передачи объектов по ссылке (за исключением примитивов) не позволяет написать подобие обобщённых функций, работающих со значениями, (типа функции swap в C++).
2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#).
3. Недостаточный контроль над стеком в JVM не позволяет реализовать продолжения достаточно эффективным образом (нужно в определённый момент сделать снимок стека и графа объектов, чтобы потом загрузить обратно).
4. Операция "найти всех потомков" пока не может быть реализована достаточно эффективным образом.
5. Операция "найти все инстансы класса" пока не может быть реализована достаточно эффективным образом.
6. Не поддерживается перегрузка по типу возвращаемого значения.
7. Не поддерживается горячая замена класса, затрагивающая метаданные.
8. Не поддерживается хвостовая рекурсия.
9. Тяжёлые потоки.
10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
11. Нет быстрых замыканий.
12. Не умеет вышивать крестиком.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
ЗХ>>Насколько эти вопросы ограничивают совместимость разноязычных библиотек в рамках одной платформы?
LCR>Скажу про JVM. JVM заточена под безопасные объектно-ориентированные языки. Заточка заключается в том, что JIT надрессирован на распознавание типичных паттернов кода, которые появляются в типичной программе на Java и GC, который тоже ориентирован на типичные сценарии работы с объектами. И если новый язык чуть-чуть вылазит за эти рамки, то будут проблемы (прежде всего с перфомансом).
LCR>1. Семантика передачи объектов по ссылке (за исключением примитивов) не позволяет написать подобие обобщённых функций, работающих со значениями, (типа функции swap в C++). LCR>2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#). LCR>3. Недостаточный контроль над стеком в JVM не позволяет реализовать продолжения достаточно эффективным образом (нужно в определённый момент сделать снимок стека и графа объектов, чтобы потом загрузить обратно). LCR>4. Операция "найти всех потомков" пока не может быть реализована достаточно эффективным образом. LCR>5. Операция "найти все инстансы класса" пока не может быть реализована достаточно эффективным образом. LCR>6. Не поддерживается перегрузка по типу возвращаемого значения. LCR>7. Не поддерживается горячая замена класса, затрагивающая метаданные. LCR>8. Не поддерживается хвостовая рекурсия. LCR>9. Тяжёлые потоки. LCR>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок). LCR>11. Нет быстрых замыканий. LCR>12. Не умеет вышивать крестиком.
LCR>Ты это хотел услышать?
Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).
FAQ — це мiй ай-кью!
Re[3]: Совмещение разных объектных моделей на одном фреймвор
Зверёк
LCR>>Ты это хотел услышать?
ЗХ>Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).
Ну вот следствие (ща гадость скажу): JRuby имеет проблемы из-за пунктов 3, 4, 5, 8, 9, 10, 11 и 12. И на данный момент, в JRuby невозможно наследовать от абстрактных классов, и производные в JRuby классы не видны в Яве (это уже из-за rt.jar).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Зверёк
LCR>>>Ты это хотел услышать?
ЗХ>>Честно говоря, не совсем. Это причины (т.е. свойства JVM), а мне в данный момент более интересны следствия (проблемы, возникающие при портировании других языков и взаимодействии с ними; методы решения этих проблем).
LCR>Ну вот следствие (ща гадость скажу):
А чего "гадость"-то? Как объективная информация может быть гадостью?
LCR>JRuby имеет проблемы из-за пунктов 3, 4, 5, 8, 9, 10, 11 и 12. И на данный момент, в JRuby невозможно наследовать от абстрактных классов, и производные в JRuby классы не видны в Яве (это уже из-за rt.jar).
LCR>http://jruby.codehaus.org/Limitations
Угу, я уже покопался в факах JRuby и Jython и сделал для себя некоторые предварительные выводы. Таки в текущем состоянии это не "еще один язык для платформы" (более-менее органично интегрирующийся с прочими), а "интерпретатор, реализованный на платформе...", и взаимодействие со стандартными библиотеками происходит через "специальные" точки соприкосновения. Похоже, что для IronPython/RubyCLR ситуация должна быть близкая.
Вообще, в целом эта ситуация очень похожа на "до-платформенное" взаимодействие разных языков (через C-образный API, функции с простыми прототипами, типы данных — только "фундаментальные" вроде "целое" и "массив"), только к "фундаментальным" типам данных добавились ОО-интерфейсы. То есть получить через границы непохожих языков "нечто с методами, которые я могу вызвать" — несложно; а вот работать с этим "нечто", как с полноценным объектом (скажем, для Руби — возможность доопределить методы этого объекта) — уже увы.
LCR>PS: Я думаю эта тема интересна многим, но просто у всех отходняк после веток "MIT переходит ...", и "Пиши в Немерле".
FAQ — це мiй ай-кью!
Re[5]: Совмещение разных объектных моделей на одном фреймвор
Зверёк
LCR>>Ну вот следствие (ща гадость скажу): ЗХ>А чего "гадость"-то? Как объективная информация может быть гадостью?
Морально подготовить хотел
ЗХ>Вообще, в целом эта ситуация очень похожа на "до-платформенное" взаимодействие разных языков (через C-образный API, функции с простыми прототипами, типы данных — только "фундаментальные" вроде "целое" и "массив"), только к "фундаментальным" типам данных добавились ОО-интерфейсы. То есть получить через границы непохожих языков "нечто с методами, которые я могу вызвать" — несложно; а вот работать с этим "нечто", как с полноценным объектом (скажем, для Руби — возможность доопределить методы этого объекта) — уже увы.
+1, Хотя в одну сторону (Java -> X, то есть когда в X нужно заюзать Java-класс) ситуация заметно лучше, чем в другую (Java <- X, для достаточно фичастых X).
ЗХ>А у тебя нет опыта/сведений, во что это выливается на практике? (то есть теорию я, естественно, читаю, но интересен практический опыт в духе "вот например, язык Х, портированный на .Net, изменился таким образом", или "в языке Х, портированном на .Net, появились такие ограничения по интероперабельности")
Я бы рекомендовал глянуть на статьи вот в этом блоге:
Здравствуйте, Зверёк Харьковский, Вы писали:
АХ>>Зато хорошо портируются ОО-языки с GC .
ЗХ>Есть мнение, что ОО бывает разное (см., например, Self/Io)
Ага — CLOS посмотри. Практически _никак_ (полностью) не ложится на ОО систему NET.
ЗХ>То есть слова "ОО-язык" не исчерпывают всех вариаций которые могут быть. Объект моего интереса сейчас — операции с объектами, которые допустимы в одном .Net языке и недопустимы в другом, и как это работает на передаче через границы языков.
Опять же, если начать _полностью_ реализовывать CLOS, то ОО система получится напрочь несовместима с NET. Ибо помимо того, что сплошь динамическое создание методов/объектов/классов/метаклассов, так ещё и вызов метода превратиться в вызов "вызывающего" метода метакласса (или "прометакласса" ) Работа с такими классами в других языках превратиться в кошмар
ЗХ>Спасибо. Это крайне полезная информация.
Re[4]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Андрей Хропов, Вы писали:
АХ> dynamic methods.
Кстати, интересно, что приводятся примеры, когда кодогенерация в ран-тайм приводит к увеличению скорости. А Влад до сих пор уверен в том, что таких случаев нет
Все самому, все самому. Ничего мировому разуму доверить нельзя 
.
.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Кстати, интересно, что приводятся примеры, когда кодогенерация в ран-тайм приводит к увеличению скорости. А Влад до сих пор уверен в том, что таких случаев нет 