Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.138.141.202] |
|
Страницы: (8) « Первая ... 6 7 [8] все ( Перейти к последнему сообщению ) |
Сообщ.
#106
,
|
|
|
Сообщ.
#107
,
|
|
|
Цитата MyNameIsIgor @ А если я люблю баню? так баня и парилка -- не одно и то же вроде, не? |
Сообщ.
#108
,
|
|
|
Цитата amk @ Дело в том, что слово 'детерминированный' к объектам в программировании почти не применяется. Что подразумевается под объектами? Инстансы? Так это экземпляры конкретных классов с конкретным же способом инициализации. С какой стороны термин применить? А вот к типам, переменным - почему нет. В том же драфте индекс четко содержит variable indeterminate и активно оперирует термином (не)детерминированности как к процессу вычисления типов, так и к процессу инициализации переменных. А текущая дата - у вас псевдотекущая и пользовательский ввод - псевдопользовательский? Цитата amk @ Согласись, говорить, что сущность, которая просто обязаны быть детерминированной - детерминирована - это то же самое, что говорить, что масло является маслянистым. Если этот паттерн переложить на то, о чем я говорил, то number является integer'истым, number является natural'истым и т.п. Является полиморфный тип тем, чем он является? Или мы не можем определить наверняка, что он в данный момент представляет и смотрим сквозь замочную скважину контракта? А если я использую в качестве предиката недетерминированную функцию? Полиморфный тип все равно всех детерминирует не смотря ни на что? Это Io, как я и писал. Цитата amk @ И такой полиморфизм динамически реализуем и в языках со статической типизацией (с одной поправкой - в языке со СТ нельзя в динамике проверить существование метода или атрибута, но можно проверить тип объекта). Можешь показать на примере первой же строчки, которая модифицирует штатный тип Number и модифицировать похожим образом int? Цитата amk @ По-моему интереснее был бы пример с фабрикой, на основе свойств создающей объект нужного типа. Этот вариант тоже работает при любом виде типизации. Причем, в случае статической типизации без дополнительных накладных расходов при работе с объектом. Фабрика - это один из самых скучных паттернов, как она может быть интересней динамического изменения (не вычисления) типа переменной в момент ее инициализации. Угумс, но приходиться работать с тем, что дали Я спросил в самом начале про практичные примеры, но ответа пока не дадено. Цитата D_KEY @ Ты уверен, что ты получаешь доступ к методу foo, именно через контракт number? Ведь в этом контракте о foo ничего не сказано Я как раз уверен, что не получу С точностью до наоборот. Я хочу печеньки, а мне дают контракт с работодателем, который решил полиморфно эти печеньки у меня спереть и выдавать в конвертах, которые мне надо раскрывать, то бишь кастить, чтобы наконец насладиться кондитерским изделием. Цитата amk @ В случае если приспичит динамически добавлять/удалять атрибуты элементарно моделируется посредством отображений (map), как это делается и в языках с динамической типизацией и в общем-то с той же эффективностью. Динамика - это тебе не ассоциативные массивы прикрутить Как методы вместе с их телами будешь конструировать? Как новые типы создавать? А способом неизвестным на этапе компиляции? Цитата amk @ Зато концепция у него интересная - объекты и ничего кроме объектов. На поверку почти все они оказываются словарями, но словари опять же содержат объекты. Тогда тебе прямая дорога в Smalltalk, Self, вышеупомянутый Io. Вот там воистину все объекты. |
Сообщ.
#109
,
|
|
|
Цитата Guderian @ Цитата D_KEY @ Ты уверен, что ты получаешь доступ к методу foo, именно через контракт number? Ведь в этом контракте о foo ничего не сказано Я как раз уверен, что не получу Так в том и дело, что в случае динамики у тебя вообще нет этого контракта. На мой взгляд, статическую и динамическую типизацию можно свести грамотно в одном языке, как раз через систему контрактов(пред- и пост- условий, а также инвариантов), которая позволит в одних случаях что-то требовать, в других, что-то гарантировать, в остальных же - не препятствовать. Цитата Цитата amk @ Зато концепция у него интересная - объекты и ничего кроме объектов. На поверку почти все они оказываются словарями, но словари опять же содержат объекты. Тогда тебе прямая дорога в Smalltalk, Self, вышеупомянутый Io. Вот там воистину все объекты. А с Ruby что не так? Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный. |
Сообщ.
#110
,
|
|
|
Цитата D_KEY @ Так в том и дело, что в случае динамики у тебя вообще нет этого контракта. А кто сказал, что он мне нужен? Разные парадигмы - разные подходы. ООП: 1. Копать умеешь? 2. Тогда переоденься в спецодежду. 3. Копай. Динамика: 1. Копай. 2. Не умеешь - не копай. Как-то так Цитата D_KEY @ На мой взгляд, статическую и динамическую типизацию можно свести грамотно в одном языке, как раз через систему контрактов(пред- и пост- условий, а также инвариантов), которая позволит в одних случаях что-то требовать, в других, что-то гарантировать, в остальных же - не препятствовать. На мой взгляд, их не надо сводить вместе. Да и не получится. Статика опять же захочет иметь "пред- и пост- условия" загодя, а динамика "да ну их, потом разберемся" Цитата D_KEY @ А с Ruby что не так? Попробуй определи на нем новый метод в классе, потом его переопредели, а потом удали. У меня не получилось. В расово чистых языках, где все есть объект, это естественные операции, ибо класс - есть тоже объект. В Руби же, даже возможность добавления нового метода объясняется тем, что якобы определение класса просто не закрыто. Цитата D_KEY @ Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный. Попробуй Io/Ioke. Из Smalltalk'а он взял, пожалуй, больше всех, но при этом подмешано функциональное, которое в большей степени "подсластило" синтаксис и он уже не такой зубодробительный. |
Сообщ.
#111
,
|
|
|
Цитата Guderian @ Цитата D_KEY @ На мой взгляд, статическую и динамическую типизацию можно свести грамотно в одном языке, как раз через систему контрактов(пред- и пост- условий, а также инвариантов), которая позволит в одних случаях что-то требовать, в других, что-то гарантировать, в остальных же - не препятствовать. На мой взгляд, их не надо сводить вместе. Да и не получится. Статика опять же захочет иметь "пред- и пост- условия" загодя, а динамика "да ну их, потом разберемся" Думаю, что это возможно разрулить. Цитата Цитата D_KEY @ Мне smalltalk понравился(правда опыта мало), но вот синтаксис просто ужасный. Попробуй Io/Ioke. Из Smalltalk'а он взял, пожалуй, больше всех, но при этом подмешано функциональное, которое в большей степени "подсластило" синтаксис и он уже не такой зубодробительный. Спасибо за совет Вроде не пробовал. |
Сообщ.
#112
,
|
|
|
Ну как, кто-нибудь попробовал kotlin в реальной жизни и может поделиться впечатлениями?
|
Сообщ.
#113
,
|
|
|
Цитата D_KEY @ Ну как, кто-нибудь попробовал kotlin в реальной жизни и может поделиться впечатлениями? А уже вышла реализация? Я бы попробовал, хотя пока не в "продакшене", а то мало ли чего там недопричесали =) |
Сообщ.
#114
,
|
|
|
А между тем, он действительно вышел, хотя и пока не «production-ready» версия.
http://www.youtube.com/watch?v=BhCDeCKdsGU...be_gdata_player |
Сообщ.
#115
,
|
|
|
а котлин for javascript там работает??
|
Сообщ.
#116
,
|
|
|
Цитата jack128 @ а котлин for javascript там работает?? Вот не пробовал, т.к. было уже поздно, да и JS мне не интересен. =) Может сегодня позже гляну. Вообще у них есть Web demo, где можно попробовать компиляцию в JS. |
Сообщ.
#117
,
|
|
|
Цитата korvin @ JS мне не интересен эх-хе-хех... Если бы мне был бы интересен js, я б kotlin for js и не не смотрел :-( |
Сообщ.
#118
,
|
|
|
Цитата jack128 @ Цитата korvin @ JS мне не интересен эх-хе-хех... Если бы мне был бы интересен js, я б kotlin for js и не не смотрел :-( А, ну я имею в виду, что он мне не интересен как целевая платформа в данном контексте. Хотя теперь можно писать веб-сервер и серверное ПО под Node.JS на Kotlin. |
Сообщ.
#120
,
|
|
|
Ещё и Ceylon похоронил
|