Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[54.166.141.52] |
|
Страницы: (33) 1 [2] 3 4 ... 32 33 ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Жаль, в том смысле, что можно было бы попытаться обсудить те или иные решение, которые приняли разработчики языка. Как по мне, так всё там более-менее нормально. Да, местами код выглядит более громоздко из-за лайфтаймов, но это логично: добавили новую сущность - надо её как-то выражать. Опять же, раньше некоторые вещи были, на мой взгляд, более "с++"-подобными, например, юзинги. От этого ушли в пользу ключевых слов. Поначалу это мне не нравилось, потом стало пофиг. |
Сообщ.
#17
,
|
|
|
Сообщ.
#18
,
|
|
|
Цитата D_KEY @ Это мнение, кстати говоря, довольно часто встречается.. Осталось найти язык, который не ругают (за синтаксис). |
Сообщ.
#19
,
|
|
|
Ассемблер?
|
Сообщ.
#20
,
|
|
|
Языков ассемблера больше одного
Добавлено Цитата DarkEld3r @ Цитата D_KEY @ Это мнение, кстати говоря, довольно часто встречается.. Осталось найти язык, который не ругают (за синтаксис). Степень неприязни разная. |
Сообщ.
#21
,
|
|
|
Цитата D_KEY @ Степень неприязни разная. Возможно, только она не особо и коррелирует с популярностью языка, имхо. Опять же, очень часто это "синдром утёнка". Да и мне кажется, что многие ругающие предмет неприязни видели только "на картинках", не уверен, что это о чём-то говорит. Скажем, С++ не ругал только ленивый и не сказать, что так уж зря. Тем не менее, язык довольно популярен, ну и лично мне ощутимых неудобств синтаксис не доставляет. Немало найдётся и тех, кто будет его защищать. Или лисп вспомнить можно - большинство сразу начнёт кричать про обилие скобок, но если хоть немного писать что-то, то как-то и не мешает вовсе. |
Сообщ.
#22
,
|
|
|
Хм, а чем так сильно отличается поле с функцией первого класса в качестве значения поля от обычного метода, что их так надо разделять? Какой-то бред придумали в Rust по-моему с этим.
|
Сообщ.
#23
,
|
|
|
Цитата Serafim @ Хм, а чем так сильно отличается поле с функцией первого класса в качестве значения поля от обычного метода, что их так надо разделять? В расте методы (ссылка на таблицу) хранятся не в объекте, а в трейте. Собственно, в С++ тоже есть разница между методом и полем содержащим функцию. Цитата Serafim @ Какой-то бред придумали в Rust по-моему с этим. Выше я приводил своё понимание того почему сделали именно так. Предложи вариант получше, с учётом особенностей языка. |
Сообщ.
#24
,
|
|
|
Цитата Serafim @ Хм, а чем так сильно отличается поле с функцией первого класса в качестве значения поля от обычного метода, что их так надо разделять? В классовом ООП нет никакой надобности хранить методы в экземпляре. Грубо говоря. |
Сообщ.
#25
,
|
|
|
Я не про частности, я про общую теорию. Имхо, вообще разделения на метод\поле не должно быть на уровне языка никакого, лишь может быть на уровне визуального представления. Тоже и касается трейтов (если не вдаваться в тонкости раста) - это сокращение для абстрактного класса. Короче всё это в целом - просто попытка реализовать уже существующее, превратив привычные `class extends` в `impl for`.
Добавлено Короче я за классы и трейты (но не те трейты, которые в расте, а нормальные). Добавлено те же структуры (struct) вообще ничем не отличаются от обычных ассоциативных массивов (ака хешей)... |
Сообщ.
#26
,
|
|
|
Цитата Serafim @ Имхо, вообще разделения на метод\поле не должно быть на уровне языка никакого, лишь может быть на уровне визуального представления Но D_KEY всё правильно сказал - что в С++, что в расте "просто методы" не хранятся в объекте. Какой смысл хранить их в каждом объекте? Даже если говорить про "виртуальные функции", то всё равно есть разница - один указатель против одного указателя на каждый метод. Цитата Serafim @ (если не вдаваться в тонкости раста) - это сокращение для абстрактного класса Ну а если вдаваться, то нет. Трейты нужны, в первую очередь, для дженериков, которые разворачиваются на этапе компиляции, как и плюсовые шаблоны, но накладывают более явные ограничения на типы. Цитата Serafim @ те же структуры (struct) вообще ничем не отличаются от обычных ассоциативных массивов (ака хешей)... Видимо, я чего-то не понимаю. О каком языке речь? |
Сообщ.
#27
,
|
|
|
Цитата DarkEld3r @ Но D_KEY всё правильно сказал - что в С++, что в расте "просто методы" не хранятся в объекте. Какой смысл хранить их в каждом объекте? Как оно хранится на уровне рантайма - это уже не важно и частности. Можно хранить в прототипе (см JS, etc...), никто не мешает. Цитата DarkEld3r @ Ну а если вдаваться, то нет. Трейты нужны, в первую очередь, для дженериков, которые разворачиваются на этапе компиляции, как и плюсовые шаблоны, но накладывают более явные ограничения на типы. Эм. А чем "T implements SomeInterface" не угодил? Я хз, есть ли такое в сях. Цитата DarkEld3r @ Видимо, я чего-то не понимаю. О каком языке речь? Ну о любом наверное, где есть хеши или мапы. Во внутреннем представлении - это всё же адрес с именем и массив из произвольных кей-велью значений. Ничего не мешает написать точно такой же генератор таких структур на любом классовом языке с достаточным уровнем мета-магии, чтоб перехватывать `method_missing`. Я всё это веду к тому, что модель Rust по-моему - это шаг назад. От абстракции к реализации. Вон, сколько пытались в Objective-C от этих разделений избавиться? Избавились - сделали Swift. А тут какой-то Objective-C, только в профиль =) Добавлено Цитата Serafim @ Эм. А чем "T implements SomeInterface" не угодил? Я хз, есть ли такое в сях. Ну что-то как-то так имеется ввиду: interface Some<T implements IAny> { public function test(T asdasd); } Добавлено Если именно это подразумевалось под "строгостью" дженериков |
Сообщ.
#28
,
|
|
|
Цитата Serafim @ Как оно хранится на уровне рантайма - это уже не важно и частности. Во первых, для низкоуровневых языков (а раст претендует именно на эту нишу) оно очень даже важно оказывается. Во вторых, изначально вопрос был "чем отличается" - так вот вполне отличается. Цитата Serafim @ Эм. А чем "T implements SomeInterface" не угодил? Я хз, есть ли такое в сях. В сях нет, тем и не угодил. Но тогда я не понимаю претензию к трейтам. Значит интерфейсы, как отдельная сущность не смущают, а трейты уже не нравятся? А разница-то в чём? Цитата Serafim @ Ну о любом наверное, где есть хеши или мапы. Но это не так. Ещё раз - методы статически вызываются и нигде не хранятся. "Абстрагирование" от этого мне нафиг не нужно, если оно потянет за собой необходимость каждый метод в рантайме искать в хеш-таблицах. Конечно, "method_missing" можно сделать и для "нормальных методов" и в D так и сделано, но в расте такого нет. Цитата Serafim @ Ну что-то как-то так имеется ввиду: Наверное, хотя тут я вижу только новый интерфейс. В расте "быть дженериками" (иметь ограничение по типу) могут функции, структуры, енумы и трейты. Цитата Serafim @ А тут какой-то Objective-C, только в профиль =) Objective-C знаю не очень хорошо, но похожего вижу крайне мало, ну кроме (немного) "С-подобного синтаксиса". Тут всё не вертится вокруг "посылки сообщений", отсутствующий метод обработать нельзя и т.д. С удовольствием послушаю какие тут можно увидеть сходства. И почему именно с Objective-C, а не С или С++. |
Сообщ.
#29
,
|
|
|
Цитата Serafim @ Я не про частности, я про общую теорию Это про какую такую теорию? По ООП у нас какая теория-то? Буч? Мейер? Так там тоже классовое ООП и метод относится не к экземпляру, а к классу. Т.е. какой метод у объекта однозначно определяется классом, а какое значение будет у полей - экземпляром. Это считай и есть состояние объекта. Методы к этому состоянию никакого отношения не имеют. Цитата Имхо, вообще разделения на метод\поле не должно быть на уровне языка никакого Смотря что ты имеешь в виду. Для клиента класса - да, желательно, чтобы при изменении стратегии хранения(храним поле или же вычисляем значение в методе) клиент не нужно было менять. Есть "принцип универсального доступа" и пр. такое. Но это скорее о синтаксисе. В "классических" языках решается или тем, что все публичное оформляется в виде методов(в простейшем случае get/set), или пропертями всяческими. Цитата но не те трейты, которые в расте, а нормальные В чем отличие? Цитата те же структуры (struct) вообще ничем не отличаются от обычных ассоциативных массивов (ака хешей)... |
Сообщ.
#30
,
|
|
|
Цитата Serafim @ От абстракции к реализации. Ну и этого понять не могу. Что тут подразумевает? Где абстракция/реализация? Как методы определять/хранить? По моему, это фигня, а не "абстракция". Ну и я всё-таки повторюсь: в расте методы типу могут добавляться извне. Можно реализовывать трейты объявленные в сторонней библиотеке для своих типов и наоборот. Именно поэтому оно и выносится отдельно. Как можно иначе, если мы хотим сохранить эту особенность я плохо представляю. |