CAB>>Реализаций ООП много и все они разные. Я считаю, наиболее Ъ ООП в ЯП Scala, потому сравниваю с ним. _>Концепция типа "всё есть объект" — это как бы не фича, а наоборот ограничение возможностей.
Внезапно, почему?
_>А я спрашиваю как раз про фичи. Ну такие как наследование (множественное или нет или с интерфейсами), полиморфизм, абстрактные классы, уровни инкапсуляции, статические методы, перегрузка операторов, обобщённые классы и т.п.
Не копал Rust глубоко, потому про фичи не могу ничего сказать. Я заметил только концептуальную проблему.
_>С удовольствием увидел бы табличку сравнения ООП фич между Scala, Rust'ом и скажем C++ (т.к. Rust пытается стать заменой именно ему, хотя пока я не вижу чтобы тянул на это). И я бы тоже (на заметку kaa.python ).
CAB>>По моему скромному мнению, если уж вы решили добавить ООП в язык, вам не стоит туда добавлять ещё и отдельные функции, примитивные типы, структуры etc. Это оверкил. _>А чем оно мешает то?
Увеличивает сложность и риск прострелить себе ногу.
CAB>>И наоборот, если вы решили что у вас будет язык низкого уровня, и там будут функции и п. типы, не стоит туда прикручивать ООП, структур вполне достаточно. _>Да, всё правильно. Но зачем нам в 21-ом веке ещё один язык низкого уровня? Нам наоборот нужен язык очень высокого уровня, но при этом с сохранением полноценного доступа к системе/железу.
Я бы предпочёл два языка с хорошей интеграцией, как например C и Python.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, alex_public, Вы писали:
_>Безусловно можно. Я видел реализацию модели акторов в разных языках. Если мы возьмём C++ (здесь это у нас в виде сторонних библиотек), то здесь действительно надо самим следить что куда мы посылаем. Т.е. есть возможность нечаянно нарушить правила библиотеки и получить баг. Если возьмём реализацию в D (там она входит в базовую библиотеку), то фичи D (разделение памяти по потокам, immutable и т.п.) позволяют полностью предотвратить подобные ошибки. Но при этом остаётся возможность специально обойти систему через самый низкий уровень. В Rust'е как я понимаю сложно уже даже специально обойти. Но на мой взгляд это уже сильный перебор, типа защиты от сознательного вредительства. Т.е. естественно никто не был бы против такого, если оно бесплатно. Но тут мы получаем заметное усложнение системы памяти. В то время как например D спокойно обошёлся без этого.
Rust благодаря такому жесткому разделению может позволить себе thread-local сборку мусора, как в Эрланге. А когда систему типов можно обойти простым cast'ом (что в D и приходится делать с shared частенько), то фиг, приходится страдать с общей кучей и глобальным GC.
Здравствуйте, C.A.B, Вы писали:
C>>Скала — это такой недоязычок с freestanding-методами? CAB>Nope. Там нету freestanding-методов (что это?), насколько мне известно.
object Hi {
def main(args: Array[String]) = println("Hello, world!")
}
Так вот тут println() — это не объект! :закатывание глаз и падение в обморок:
Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Вообще, какая либо ассоциация ООП и безопасности языка — это кретинический бред. Лисп является безопасным, точно так же как и ML. На обоих можно написать вполне себе процедурный код, но для Лиспа есть CLOS, который куда как более мощный, чем ООП в той же Java/Scala.
object Test {
val refToPL:(String)=>Unit = println //> refToPL : String => Unit = <function1>
refToPL.apply("Hi") //> Hi
}
C>:закатывание глаз и падение в обморок:
C>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д.
Scala это такой Smalltalk с функциональщиной и Java библиотеками.
C>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно.
C>[parsing failure]...но для Лиспа есть CLOS, который куда как более мощный, чем ООП в той же Java/Scala.
Спасибо, на досуге посмотрю.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
C>>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. CAB>Scala это такой Smalltalk с функциональщиной и Java библиотеками.
Scala похожа на Smalltalk чуть менее, чем никак.
C>>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет. CAB>Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно.
Я писал на Скале ещё до того, как она стала популярной
И мультиметодов там нет — они точно так же могут эмулироваться с помощью визиторов, как и в Java или с помощью других подобных средств.
C>>>Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет. CAB>>Их есть там, и ещё много чего. Рекомендую наконец приобщится и посмотреть самостоятельно. C>И мультиметодов там нет — они точно так же могут эмулироваться с помощью визиторов, как и в Java или с помощью других подобных средств.
Или с помощью ПМ:
def collide(x:Thing, y:Thing) = (x,y) match{
case (x:Asteroid,y:Asteroid) => {
//астероид сталкивается с астероидом
}
case (x:Asteroid,y:Spaceship) => {
//стероид сталкивается с космическим кораблем
}
case (x:Spaceship,y:Asteroid) => {
//космический корабль сталкивается с астероидом
}
case (x:Spaceship,y:Spaceship) => {
//космический корабль сталкивается с космическим кораблем
}
}
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>(пример от сюда)
Ну так можно и вообще дойти до того, что классический Бэйсик — это полный ООП, так как там можно с помощью if-else эмулировать виртуальные методы.
Вопрос чисто практический. У меня плагин к эклипсу rusty cage не работает Кто нибудь им пользуется?
Все делал по инструкции http://reidarsollid.com/2012/03/27/rustycage-a-rust-lang-ide-plugin-for-eclipse/
(за исключением того что Винда, но пути к компилятору в настройках пробовал самые разные начиная с очевидного c:/Rust/bin)
Не компилируется, похоже компилятор даже не запускается. Выводится сообщение
Здравствуйте, x-code, Вы писали:
XC>Вопрос чисто практический. У меня плагин к эклипсу rusty cage не работает Кто нибудь им пользуется?
Судя по активности в БагТрекере, кто-то все же пользуется. Я нет, но я и C++ код в Vim пишу
XC>Само по себе это "L" очень странное, у меня проект лежит в D:/MyProjects/_Eclipse/rust_project, похоже баг в плагине?
"L" очень похожа на "широкую строку"
P.S. глянь на Sublime Text 2, это почти как как Vim по возможностям, только с привычными клавишами и без режима "бибкать и все портить"
XC>и все.
У меня была та же ерунда. Это скорей всего баг. Для его обхода я просто написал небольшой 'run.bat' и, с помощью External tools повесил его на F9 (которая 'Run' у меня во всех проектах).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Cyberax, Вы писали:
C>Вот в православном Smalltalk любое действие — это посылка сообщения, которое можно перехватить, изменить, отменить и т.д. Не говоря уж про мультиметоды. Не то что в этом убогом недоязычке, где даже мультиметодов нет.
Возможно, я не так понял фразу, но в Smalltalk нет мультиметодов, насколько мне известно.
Здравствуйте, C.A.B, Вы писали:
CAB>У меня была та же ерунда. Это скорей всего баг. Для его обхода я просто написал небольшой 'run.bat' и, с помощью External tools повесил его на F9 (которая 'Run' у меня во всех проектах).
Посмотрел — баг висит, но он закрыт по причине того что у автора плагина нет винды
очень маленькая и компактная ide для Go (в отличие от монструозного эклипса, в который нужно еще и Скалу ставить... Скала конечно сам по себе интересный язык, но столько зависимостей ради простой подсветки синтаксиса и компиляции с запуском ИМХО перебор).
Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
XC>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
Почему бы и нет, если есть желание и время. Хотя я бы дождался "устаканивания" Rust'а.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
XC>>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust? CAB>Почему бы и нет, если есть желание и время. Хотя я бы дождался "устаканивания" Rust'а.
Нашел весьма неплохой способ работать с Rust из под винды. Ничего не нужно компилировать (а значит и нарываться на ошибки, связанные с тем что линуксовые программы под виндой как правило сходу не собираются)
Требуется виндовые сборки mingw, gtk2, geany, ну и собственно сам rust.
2. mingw/bin, gtk/bin и rust/bin должны быть прописаны в path.
3. для geany нужен собранный exe и также исходники с гитхаба, из которых нужно взять папку data и целиком скопировать вместо папки data которая была при exe. Там куча настроек для разных языков, на самом деле чего там только нет, так что вероятно этот редактор можно использовать и для других интересных целей.
После этого создаем проект, в нем файл с расширением .rs, сохраняем (возможно еще нужно выбрать document->set filetype->programming languages->rust) — становятся активными кнопки compile и build, код подсвечивается, дерево символов, вывод ошибок во встроенный лог, щелчок по ошибке открывает ее в коде, кнопка "выполнить" запускает откомпилированное приложение. А для экспериментов что еще надо?
Есть ещё что-то по Rust кроме tutorial и Reference Manual?
А то вот только по косвенному тексту нашёл, что возвращаемое значение в функции без return должно быть и без ";", а так не мог понять, что за ошибка "not all control paths return a value"
Здравствуйте, x-code, Вы писали:
XC>Эта LiteIDE написана на Qt, кода мало так что разобраться реально, может быть попробовать в нее добавить поддержку Rust?
Надо лучше начать добавлять поддержку в IDEA
Это не так сложно. Но очень хотелось бы, чтобы сначала устоялась грамматика.
Здравствуйте, cl-user, Вы писали:
CU>Есть ещё что-то по Rust кроме tutorial и Reference Manual?
Есть разбросанные заметки по блогам, но в них все быстро устаревает. Сами же Tutorial и Reference Manual, пока еще, очень сырые. Лично я, когда мне нужна какая-либо информация, открываю исходники и смотрю в src/test. Если там ничего подходящего не нашлось, то смотрю тесты в соответствующих компонентах из src/libstd, src/libextra и src/librustuv. Позволяет найти ответы на большинство вопросов, понятно что не очень удобно, но с учетом очень простого и читабельного кода работает хорошо.
P.S. если хочется быть в курсе последних событий, но ломает следить за рассылкой и коммитами, то очень рекомендую подписаться на This Week in Rust.
Здравствуйте, Cyberax, Вы писали:
C>Надо лучше начать добавлять поддержку в IDEA
О даа! Очень бы хотелось иметь такую поддержку! Vim + Sublime – это, безусловно, прекрасно, но для популяризации языка среди не юниксоидов IDE жизненно необходима.
И я бы тоже (на заметку kaa.python 
).
