Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 254
Я уже слышу гневные крики про кривость трансляции из dart в js.
Фатальный недостаток dart найден :)
Если серьёзно, то removeLast лучше тем что вернее отражает суть:
Pop: удалить элемент из однонаправленного контейнера (такого как стэк)
RemoveLast: название говорит за себя.
Если серьёзно, то removeLast лучше тем что вернее отражает суть:
Pop: удалить элемент из однонаправленного контейнера (такого как стэк)
RemoveLast: название говорит за себя.
Методы имеет смысл делать компактными как это возможно если смысл их очевиден.
Казнить нельзя помиловать
Да, имеет смысл:
во первых по тому что компактные исходники быстрее за грузятся,
Во вторых потому что в JavaScript нет статической типизации и написать IDE которая будет делать автоподстановку как минимум затруднительно.
Но, смысл метода pop() не очевиден, а привычен, вы так же могли заучить что воображаемый метод delete() удаляет первый элемент. Во вторых в Дарте есть статическая типизация.
во первых по тому что компактные исходники быстрее за грузятся,
Во вторых потому что в JavaScript нет статической типизации и написать IDE которая будет делать автоподстановку как минимум затруднительно.
Но, смысл метода pop() не очевиден, а привычен, вы так же могли заучить что воображаемый метод delete() удаляет первый элемент. Во вторых в Дарте есть статическая типизация.
во первых по тому что компактные исходники быстрее за грузятся
Про Closure compiler и прочие инструменты для минимизации продакшн кода Вы не слышали?
Во вторых потому что в JavaScript нет статической типизации и написать IDE которая будет делать автоподстановку как минимум затруднительно
Такие IDE существуют. Например, Jet brains
А ничего, что pop() именно выталкивает элемент. Т.е. убирает его и возвращает. А RemoveLast, судя по говорящему названию, только удаляет его.
Я вообще за popBack() если что.
Хотя если выбирать между двумя костяными названиями, то дартовский мне нравится больше, тем, что хотя бы понятно что произойдёт с исходным массивом. Что вернёт метод не очевидно ни в том ни в другом случае.
Хотя если выбирать между двумя костяными названиями, то дартовский мне нравится больше, тем, что хотя бы понятно что произойдёт с исходным массивом. Что вернёт метод не очевидно ни в том ни в другом случае.
А я всегда думал что pop должен только удалять. Я в javascript не силён, но в плюсах принято возвращать void.
Почему — www.sgi.com/tech/stl/stack.html (последняя заметка под номером 3)
Почему — www.sgi.com/tech/stl/stack.html (последняя заметка под номером 3)
Pop переводится как «выдавить», так что метод с таким именем вполне может возвращать удалённый элемент. Понятно что в плюсах, из соображений производительности метод pop() ничего не возвращает.
Вы читали что написано в доках SGI? Из каких таких соображений производительности?
Поясню, допустим вызываем pop (казалось почему бы ему не вернуть top) — он создает копию top'а — для этого вызывается конструктор нашего объекта, а он допустим выделяет гигибайт памяти и устанавливает соединение с базой данных… могу ещё пример придумать.
Поясню, допустим вызываем pop (казалось почему бы ему не вернуть top) — он создает копию top'а — для этого вызывается конструктор нашего объекта, а он допустим выделяет гигибайт памяти и устанавливает соединение с базой данных… могу ещё пример придумать.
One might wonder why pop() returns void, instead of value_type. That is, why must one use top() and pop() to examine and remove the top element, instead of combining the two in a single member function? In fact, there is a good reason for this design. If pop() returned the top element, it would have to return by value rather than by reference: return by reference would create a dangling pointer. Return by value, however, is inefficient: it involves at least one redundant copy constructor call. Since it is impossible for pop() to return a value in such a way as to be both efficient and correct, it is more sensible for it to return no value at all and to require clients to use top() to inspect the value at the top of the stack.
И вашей цитаты: «Return by value, however, is inefficient: it involves at least one redundant copy constructor call.»
Или мы с вами разные вещи называем производительностью?
Или мы с вами разные вещи называем производительностью?
А что в яваскрипте производительность не нужна?
И ещё пример — в конструкторе происходит ошибка, бросается исключение.
И ещё пример — в конструкторе происходит ошибка, бросается исключение.
И ещё пример — в деструкторе удаляемого объекта просходит ошибка, что тогда? Тогда контейнер будет в «подвешенном» состоянии.
В яваскрпте все объекты передаются по ссылке, деструкторов нет. Соответственно можно отцепить элемент от контейнера и вернуть ссылку на него.
Мизерная проблема потери производительности из за того что возвращается ссылка, даже если она не нужна, в скриптовых языках традиционно игнорируется.
Если в конструкторе бросилось исключение, то копия не создается, контейнер не меняется, дальше обычная раскрутка стека. Что страшного?
Мизерная проблема потери производительности из за того что возвращается ссылка, даже если она не нужна, в скриптовых языках традиционно игнорируется.
Если в конструкторе бросилось исключение, то копия не создается, контейнер не меняется, дальше обычная раскрутка стека. Что страшного?
Объясните смысл этих строк?
> it would have to return by value rather than by reference:
> return by reference would create a dangling pointer.
Возвратить по ссылке нельзя, потому что получится оборванный указатель. Что бы это значило?
> it would have to return by value rather than by reference:
> return by reference would create a dangling pointer.
Возвратить по ссылке нельзя, потому что получится оборванный указатель. Что бы это значило?
На момент возврата значения элемент будет уничтожен и память будет освобождена, возвращать указатель/ссылку неначто.
а чем мотивирована необходимость уничтожения объекта?
лично мне конструкция delete stack.pop() для случая когда объект не нужен кажеся более логичной, чем конструкция stack.top(); stack.pop(); для случая канонического использования стэка.
лично мне конструкция delete stack.pop() для случая когда объект не нужен кажеся более логичной, чем конструкция stack.top(); stack.pop(); для случая канонического использования стэка.
Дизайн языка такой.
Смотри,
1) Сборщика мусора нет.
2) Все значения С/С++ value_type.
Большинство контейнеров это именно контейнеры значений, — такой подход более универсален, требует меньше накладных расходов и заметно более производителен (выделение в куче достаточно дорогая операция).
Контейнеры массива или стека обычно выделяют большой кусок памяти и в нём последовательно размещают объекты. т.е. delete stack.pop() бессмысленная запись, т.к. память под удалённый элемент никогда не выделялась, он находился в заранее выделенном большом куске.
Можно написать такой стек как вы хотите, на основе стека указателей:
class deque_witch_bj_and_hookers
{
void push( int v ) { m_impl.push( new int(v) ); }
int* pop( int v ) { int* r = m_impl.top(); m_impl.pop(); return r; }
std::deque<int *> m_impl;
};
— Но, если для него вызвать stack.pop() будет утечка памяти, никто за вас delete не вызовет. Тут на помощь приходят умные указатели, но это другая длинная история. Главное что такие красивые ништяки не даются бесплатно.
Смотри,
1) Сборщика мусора нет.
2) Все значения С/С++ value_type.
Большинство контейнеров это именно контейнеры значений, — такой подход более универсален, требует меньше накладных расходов и заметно более производителен (выделение в куче достаточно дорогая операция).
Контейнеры массива или стека обычно выделяют большой кусок памяти и в нём последовательно размещают объекты. т.е. delete stack.pop() бессмысленная запись, т.к. память под удалённый элемент никогда не выделялась, он находился в заранее выделенном большом куске.
Можно написать такой стек как вы хотите, на основе стека указателей:
class deque_witch_bj_and_hookers
{
void push( int v ) { m_impl.push( new int(v) ); }
int* pop( int v ) { int* r = m_impl.top(); m_impl.pop(); return r; }
std::deque<int *> m_impl;
};
— Но, если для него вызвать stack.pop() будет утечка памяти, никто за вас delete не вызовет. Тут на помощь приходят умные указатели, но это другая длинная история. Главное что такие красивые ништяки не даются бесплатно.
> он создает копию top'а
А он не может не создавать никакую копию, а просто вернуть её?
А он не может не создавать никакую копию, а просто вернуть её?
ClassGeneric.Collection.List.Callable.RemoveAndReturnLast(array).
Типа так?
pop лучше.
Типа так?
pop лучше.
Скажите, только мне кажется что гугл набрал кучу молодых студентов которые решили изменить весь мир и с заядлой периодичностью предлагают что-то новое, вместо текущего, аргументируя что это стильно, модно современно.
Мы сделаем самый велосипедный велосипед в мире!
Кстати в правом коде подсветка var не работает.
Кстати в правом коде подсветка var не работает.
Гугл еще иногда покупает модные стартапы пачками а потом закрывает их как «непрофильные».
А что стильного, модного и современного в Dart?
Над Дартом работает например Джошуа Блох groups.google.com/forum/#!topic/javaposse/VG20Bn4Lxuk
Я бы его «молодым студентом» не назвал.
Я бы его «молодым студентом» не назвал.
Хорошо, в следующий раз буду выделять цветом иронию.
Я хотел сказать о проблеме, что людям нужна внятная аргументация для перехода на это новое и модное.
Пример, кстати тоже от google — SPDY. Протокол, замена http. Дает ускорение на 10% случаев. На некоторых кейсах больше чем 10%, окей. Анонс был в 2009 году. Сейчас 2011 год. Кроме google.com и google chrome его не умеет никто. При этом существует три разных драфта этого протокола, не совместимые между собой.
Спросите почему? Отвечаю. Разработать поддержку это протокола стоит (вилами по воде, да) ~6 человеко-месяцев. Т.е. $50K. Зачем кому-то вкладываться в это? Гугл мог бы начать разрабатывать поддержку этого протокола для браузеров-серверов сам, но почему-то тормозит. Парадокс, однако.
Тоже самое и с dart. Если вам будет нужен сайт который будет показываться не только в google chrome и будет худо-бедно работать на всяких старых телефонах, где браузер не обновляется, то выбор будет js. Не вижу я предпосылок что dart займет какую-то ощутимую долю.
Интересно, а статистику по используемым языкам в app engine гугл не показывает? Мне бы хотелось увидеть какой процент от программ написан на их Go и какой процент траффика приходиться на программы написанные на Go.
Я хотел сказать о проблеме, что людям нужна внятная аргументация для перехода на это новое и модное.
Пример, кстати тоже от google — SPDY. Протокол, замена http. Дает ускорение на 10% случаев. На некоторых кейсах больше чем 10%, окей. Анонс был в 2009 году. Сейчас 2011 год. Кроме google.com и google chrome его не умеет никто. При этом существует три разных драфта этого протокола, не совместимые между собой.
Спросите почему? Отвечаю. Разработать поддержку это протокола стоит (вилами по воде, да) ~6 человеко-месяцев. Т.е. $50K. Зачем кому-то вкладываться в это? Гугл мог бы начать разрабатывать поддержку этого протокола для браузеров-серверов сам, но почему-то тормозит. Парадокс, однако.
Тоже самое и с dart. Если вам будет нужен сайт который будет показываться не только в google chrome и будет худо-бедно работать на всяких старых телефонах, где браузер не обновляется, то выбор будет js. Не вижу я предпосылок что dart займет какую-то ощутимую долю.
Интересно, а статистику по используемым языкам в app engine гугл не показывает? Мне бы хотелось увидеть какой процент от программ написан на их Go и какой процент траффика приходиться на программы написанные на Go.
Время загрузки страниц за счет мультиплекса — это крайне странное решение наименее существенной проблемы способом. Плюс ко всему приведены результаты синтетических тестов. Фразы «в отдельных случаях Х лучше Y» — ни о чем.
У меня на http очень много нареканий, например хочется нормальной реализации comet, но то, что нужно ускорять его работу, мне бы и в голову не пришло.
У меня на http очень много нареканий, например хочется нормальной реализации comet, но то, что нужно ускорять его работу, мне бы и в голову не пришло.
Вообще-то SPDY умеет Firefox 11 и Kindle Fire.
SPDY как раз очень успешен, скоро все на нем будем. Mozilla, NGINX, Apache — все хотят запрыгнуть на этот поезд. Остальные подтянутся со временем.
Монопольное подожение приносит им кучу денег, которые некуда девать, они не знают, чего хотят (ну, кроме мирового господства), вот и выходит у них такая стратегия — сделаем сто разных прикольных и не очень, готовых или совсем недоработанных, оригинальных или откровенно скопированных штук — из них 90 сдохнут сами, 9 будут так себе, и, может быть одна, да выживет, и покорит мир. Dart, GWT, Wave, G+ — так себе. Android — один из немногих выстреливших проектов, хотя в начале и он и был э… так себе.
Да-да, прощупывают слабое место
пока что видно что Dart круче JS ввиду следующих факторов
— подсветка для лохов.
— add на 1 символ короче чем push
— подсветка для лохов.
— add на 1 символ короче чем push
removeLast анулирует преимущество с add
А как же классы, дефолтные и необязательные параметры функций, интерполяция переменной в строку, ненужность замыканий в циклах, человеческое наследование, перегрузка операторов, удаление/добавление CSS-классов без регулярок?
Как будто вы дальше массивов не прочитали…
Как будто вы дальше массивов не прочитали…
> с заядлой периодичностью предлагают что-то новое, вместо текущего, аргументируя что это стильно, модно современно
К сожалению, никакой другой аргументации, кроме «стильно, модно, современно» у них нет. Смысл в Dart'е отсутсвует, как класс
К сожалению, никакой другой аргументации, кроме «стильно, модно, современно» у них нет. Смысл в Dart'е отсутсвует, как класс
> Смысл в Dart'е отсутсвует, как класс
class, как раз-таки. Того, что там есть классы, уже достаточно чтобы заменить яваскрипт.
class, как раз-таки. Того, что там есть классы, уже достаточно чтобы заменить яваскрипт.
Ну да, начинается. Раз мы неосилили прототипное наследование, то — бегом, меняем шило на мыло только потому, что в мыле есть классы, ура!!!
Писать большие проекты на прототипах — имхо, уродство.
ну да, начинается. раз я осилил прототипное наследование, значит все кто считают его неудобным — просто не осилили
Именно. Обычно никаких аргументов кроме «ах, мне неудобно» против прототипов не приводится.
Мне на ассемблере веб-приложения писать неудобно — не осилил ассемблер? :)
Против ассемблера можно привести множество объективных аргументов кроме «мне неудобно». В случае с прототипным ОО 99% противников прототипов в качестве аргументов приводят только «мне неудобно».
Можно, да. Например писать дольше одну и ту же функциональность. С прототипным наследованием я тоже буду писать дольше одну и ту же функциональность.
> С прототипным наследованием я тоже буду писать дольше одну и ту же функциональность.
Голословное утверждение
Голословное утверждение
Никак нет. Я буду писать дольше, поскольку с прототипным наследованием практически не знаком и надо тратить время на то, чтобы сообразить как перенести «паттерны» наследования классов на него. А то и вообще другой стиль мышления развивать, как, например, при переходе с процедурного программирования на функциональное.
см. реализацию CoffeeScript. никто не жалуется.
Как это не жалуется? Там были те ещё споры по поводу опускания ключевого слова var и невозможности догадаться автоматически где программист хотел бы его объявить.
OMG
var MyNan = 0/0;
Убивать:
Убивать (почему не возвратить полученный массив? Опять обвязки вокруг делать?):
Убивать (нет смысла иметь это встроенным в язык, а не в виде библиотеки):
Убивать:
Убивать(читать комментарий для понимания глубины)
Убивать (при том, что все остальное работает почти как в Питоне)
Есть еще много концептуальных убивать: blogs.perl.org/users/rafael_garcia-suarez/2011/10/why-dart-is-not-the-language-of-the-future.html
// Keys in Dart must be string literals
var periodic = {
'gold' : 'AU',
'silver' : 'AG'
};
Убивать (почему не возвратить полученный массив? Опять обвязки вокруг делать?):
var a = ['apple', 'banana', 'cherry'];
// returns null
a.add('donut');
// == null
Убивать (нет смысла иметь это встроенным в язык, а не в виде библиотеки):
// Queues are optimized for removing items from the head
Убивать:
// calculations can be performed in string interpolation
element.style.top = '${top + 20}px';
Убивать(читать комментарий для понимания глубины)
// Dart ignores the first new-line (if it is directly after // the quotes), but not the last. var string = ''' This is a string that spans many lines. ''';
Убивать (при том, что все остальное работает почти как в Питоне)
// Dart specifies optional parameters with square braces fn(a, [b, c]) => c;
Есть еще много концептуальных убивать: blogs.perl.org/users/rafael_garcia-suarez/2011/10/why-dart-is-not-the-language-of-the-future.html
Терпимей надо быть, терпимей :)
По первому пункту не очень понял — dart требует, чтобы ключи были именно строками, или допускает, например, числа?
Если первое — то да, убивать.
Если второе — то всё правильно. Смешение словарей и объектов в JS мне очень не нравится.
Если первое — то да, убивать.
Если второе — то всё правильно. Смешение словарей и объектов в JS мне очень не нравится.
В спецификации JSON четко сказано — ключами могут быть только строки.
Дарт требует, чтобы ключи были только строками. Что им мешало взять Питоновский подход — неизвестно никому. Да Javascript'овый подход, который разрешает {klyuch_bez_kavychek: 'value'} почему не взяли — тоже неизвестно
таких убивать в джавскрипте… да тысячи их. но — исторически сложилось
Замечательная позиция у вас:
Найден недостаток в Дарт:
-Убиваать, это не язык, убожество, убивать!!111oneone
Найден недостаток в JS:
— Да не, это легко обойти, там надо пару трюков и вообще это фича а вы все просто ниасилили бе-бе-бе.
Найден недостаток в Дарт:
-Убиваать, это не язык, убожество, убивать!!111oneone
Найден недостаток в JS:
— Да не, это легко обойти, там надо пару трюков и вообще это фича а вы все просто ниасилили бе-бе-бе.
На мой взгляд вполне естественный процесс. Несмотря на многолетнюю работу Гугла на пользу обществу, язык не поворачивается назвать его старой, солидной конторой. Гугл до сих пор производит впечатление молодого, бодрого идеалиста, пышущего румянцем на все лицо, с блеском в глазах и неуемной жаждой деятельности. А молодости свойственно изобретать что-то новое (не факт кому-то кроме него нужное), отбрасывать старые догмы (не факт, что правильно), видеть мир сквозь призму розовых очков. В целом, меня радует, что они продолжают быть живчиками, постоянно раздражающими более солидные конторы своими действиями. Чем-то они мне напоминают Apple (только не запинайте меня за эти слова). И я рад, что они существуют, что они что-то подобное делают. И мне неважно — найдут свое будущее инициативы Гугла или нет, главное — разнообразие. С другой стороны, возможно было бы больше пользы, если бы Гугл навалился всеми силами на существующие проверенные технологии и улучшил их… Но, наверно, это просто невозможно. Молодости интереснее изобретать новое, чем ковырять старое, набившее оскомину :-)
В интернете много проблем с которыми все тупо смирились.
Браузеры продолжают не дружить. До сих пор без флеша далеко не уедешь — видео не проиграешь, ни одного нормального загрузчика файлов без него нет.
Протоколы авторизации и аутентификации муторные и часто используются неправильно.
Очень не хватает интерпретируемого языка вроде js, ruby, python но с жесткой типизацией, чтобы с привычной легкостью писать на нем что-то надежное.
Мне это скорее некоторых коллег напоминает, которые не в состоянии понять, почему имя переменной должно отражать ее назначение или что такое инкапсуляция, зато на каждую задачу первая реакция — о, ща мы придумаем для нее свой ЯП. На этом, обычно, решение задачи и заканчивается. В случае с Dart подобное творчество хоть и более успешно, но в плане применения направлено в воздух.
Браузеры продолжают не дружить. До сих пор без флеша далеко не уедешь — видео не проиграешь, ни одного нормального загрузчика файлов без него нет.
Протоколы авторизации и аутентификации муторные и часто используются неправильно.
Очень не хватает интерпретируемого языка вроде js, ruby, python но с жесткой типизацией, чтобы с привычной легкостью писать на нем что-то надежное.
Мне это скорее некоторых коллег напоминает, которые не в состоянии понять, почему имя переменной должно отражать ее назначение или что такое инкапсуляция, зато на каждую задачу первая реакция — о, ща мы придумаем для нее свой ЯП. На этом, обычно, решение задачи и заканчивается. В случае с Dart подобное творчество хоть и более успешно, но в плане применения направлено в воздух.
Очень не хватает интерпретируемого языка вроде js, ruby, python но с жесткой типизацией, чтобы с привычной легкостью писать на нем что-то надежное.Они Вам дали Dart, нет?
В Dart'е нет статической типизации (если она имеется в виду под «жесткой типизацией»).
С другой стороны стат. типизация имеет весьма малое отношение к написанию «чего-либо надежного»
С другой стороны стат. типизация имеет весьма малое отношение к написанию «чего-либо надежного»
На мой взгляд ее жесткость недостаточна.
Что такое жесткая типизация? Потому что есть строгая типизация и статическая типизация, а о жесткой природе неизвестно.
Ок, переформулируем, сильнотипизированный язык, где автоматические преобразования типов будут очевидно-минималистичным, максимум float > int. Без сюрпризов, особенно связанных с приведением скаляра или комплексного типа к булевой форме представления.
очевидно-минималистичным, максимум float > int. Без сюрпризовВо что преобразуется 1.1, 1.5, 1.9, -1.1, -1.5, -1.9?
Имхо, очевидными и без сюрпризов можно назвать только те преобразования, которые не приводят к потери данных, типа short int > long int, а вот long int -> short int уже не очевидно.
Ох, сорри, я перепутал, конечно же int > float
При динамической типизации самая большая беда обычно связана даже не с преобразованиями числовых скаляров а с внезапным преобразованием или не-преобразованием к строке или boolean значениям. При этом поведение
При динамической типизации самая большая беда обычно связана даже не с преобразованиями числовых скаляров а с внезапным преобразованием или не-преобразованием к строке или boolean значениям. При этом поведение
сорри, ctrl+enter случайно нажал.
При этом поведение в разных языках абсолютно разное. Если я научился укрощать типизацию python и js, то навыки окажутся бесполезными в ruby или groovy.
При этом поведение в разных языках абсолютно разное. Если я научился укрощать типизацию python и js, то навыки окажутся бесполезными в ruby или groovy.
То, что вы сильной типизации противопоставляете динамическую, боюсь, говорит о том, что у вас теоретическая каша по этой теме в голове.
Угу, python язык с сильной динамической типизацией :)
Я думаю несколько преждевременно говорить о каше.
Где я употребил слово «динамическая»? Не спорьте сами с собой.
Это действительно из другой оперы и определяет, что проверка типов и запуск кода их преобразования при необходимости будет осуществляться приемущественно во время выполнения программы.
А характер этой проверки может быть строгим(сильным) или нет.
Вообще, учитывая некоторую размытость терминологии касающейся strong typing (сильной, жесткой и как только не переводится), мы можем очень долго говорить ни о чем, хотя, на мой взгляд, все уже друг-друга прекрасно поняли.
Где я употребил слово «динамическая»? Не спорьте сами с собой.
Это действительно из другой оперы и определяет, что проверка типов и запуск кода их преобразования при необходимости будет осуществляться приемущественно во время выполнения программы.
А характер этой проверки может быть строгим(сильным) или нет.
Вообще, учитывая некоторую размытость терминологии касающейся strong typing (сильной, жесткой и как только не переводится), мы можем очень долго говорить ни о чем, хотя, на мой взгляд, все уже друг-друга прекрасно поняли.
> сильнотипизированный язык
Что такое сильная типизация? Есть строгая и статическая
> где автоматические преобразования типов будут очевидно-минималистичным, максимум float > int.
То, что очевидно одному, неочевидно другому ;)
> Без сюрпризов, особенно связанных с приведением скаляра или комплексного типа к булевой форме представления.
Для этого нужна строгая типизация. И в этом я с вами согласен :)
Что такое сильная типизация? Есть строгая и статическая
> где автоматические преобразования типов будут очевидно-минималистичным, максимум float > int.
То, что очевидно одному, неочевидно другому ;)
> Без сюрпризов, особенно связанных с приведением скаляра или комплексного типа к булевой форме представления.
Для этого нужна строгая типизация. И в этом я с вами согласен :)
>Что такое сильная типизация? Есть строгая и статическая
strong typing, дословный перевод именно сильная, а вообще мы говорим об одном и том же :)
strong typing, дословный перевод именно сильная, а вообще мы говорим об одном и том же :)
>Что такое сильная типизация? Есть строгая и статическая
Есть строгая (вообще нет никаких неявных приведений типов), есть сильная (допускаются неявные, но только не приводящие к потери данных преобразованиях), есть слабая (допустимы приводящие к потери), а есть нетипизированные вообще.
А статическая/динамическая вообще к строгой/сильной/слабой ортогональны.
Есть строгая (вообще нет никаких неявных приведений типов), есть сильная (допускаются неявные, но только не приводящие к потери данных преобразованиях), есть слабая (допустимы приводящие к потери), а есть нетипизированные вообще.
А статическая/динамическая вообще к строгой/сильной/слабой ортогональны.
Намерения Google вполне могут напомнить всем известные Microsoftовские извращения.
Но все же своя интересность в языке имеется.
Все это конечно напоминает изыски PHP. Но не могло не порадовать вот это:
// Dart does not have a concept of undefined
Интересен и этот кусок кода:
Любители ООП для себя найдут тоже немало интересного.
Судя по коду ниже, они ввели аналог JQuery. Хотя аналогия лишь усиливает желание отфейспалмиться.
Радует, что к числовым переменным теперь тоже можно применять методы. Вместо Math.ceil() -> 123.ceil()
Хотелось бы еще получить данные о скорости выполнения скриптов. Особенно ООП части.
Но все же своя интересность в языке имеется.
// calculations can be performed in string interpolation
element.style.top = '${top + 20}px';// Dart ignores the first new-line (if it is directly after
// the quotes), but not the last.
var string = '''
This is a string that spans
many lines.
''';Все это конечно напоминает изыски PHP. Но не могло не порадовать вот это:
// Dart does not have a concept of undefined
Интересен и этот кусок кода:
var loudify = (msg) => msg.toUpperCase();
loudify('not gonna take it anymore'); // NOT GONNA TAKE IT ANYMOREЛюбители ООП для себя найдут тоже немало интересного.
class Person {
var name;
Person(this.name);
greet() => 'Hello, $name';
}Судя по коду ниже, они ввели аналог JQuery. Хотя аналогия лишь усиливает желание отфейспалмиться.
Радует, что к числовым переменным теперь тоже можно применять методы. Вместо Math.ceil() -> 123.ceil()
Хотелось бы еще получить данные о скорости выполнения скриптов. Особенно ООП части.
Не красиво, конечно, но более ECMAScript5-направленное решение:
Object
.getOwnPropertyNames(Math)
.forEach(function(method) {
var descriptor = Object.getOwnPropertyDescriptor(Math, method),
value = descriptor.value;
if (typeof value !== 'function') return;
// var func = method.bind(Math); // это не нужно Math - своеобразный namespace
descriptor.value = function () {return value(this)};
Object.defineProperty(Number.prototype, method, descriptor);
});
[(-1).abs(), 144..sqrt()]
Все это конечно напоминает изыски PHPЧем это вам напоминает изыски PHP? Мне это Perl напоминает куда больше.
К числовым переменным и сейчас методы можно применять, просто математика отдельным модулем.
Неужели проще написать совершенной новый язык чем внедрить пару фичь в существующий?
Имхо основная разница в полсднем абзаце
А что нибудь в более клиентскую сторону планируется?
Для js это довольно узкое место, (работа с DOM, селекторы) и более готовое к новым решениям, чем консервативные глобальные конструкции и базовый синтаксис.
Для js это довольно узкое место, (работа с DOM, селекторы) и более готовое к новым решениям, чем консервативные глобальные конструкции и базовый синтаксис.
А у меня простой вопрос. Почему они пишут в «Test whether a string starts with a substring» для Dart:
, а для javascript:
Хотя вполне логично сравнение:
// Dart string objects have a built-in startsWith method
'racecar'.startsWith('race'); // == true
'racecar'.startsWith('pace'); // == false
, а для javascript:
// JavaScript has no built-in startsWith function
// и своё расширение прототипа
Хотя вполне логично сравнение:
// Javascript
'racecar'.indexOf('race') === 0 ; // == true
'racecar'.indexOf('pace') === 0; // == false
Я вам отвечу. Потому что… потому что Дарт это модно и современно.
Строго говоря это не одно и тоже. Версия dart'а будет работать быстрее (хотя, на практике и не значительно)
Во-первых, в сравнении гугла, как я понял, важен смысл действия, а не скорость реализации, если посмотреть на другие их примеры.
Во вторых, согласен, что indexOf при неудовлетворительном условии прочтёт строку до конца. Но что мешает тому же V8 оптимизировать такой код?
Во вторых, согласен, что indexOf при неудовлетворительном условии прочтёт строку до конца. Но что мешает тому же V8 оптимизировать такой код?
Тогда я хочу вставки на си, указатели и доступ к памяти для получения максима производительности при сравнении строк.
> Synonim
Synonym
Synonym
var element = document.createElement('p');
element.innerHTML = 'A quick brown fox.';vs
var element = new Element.html('A quick brown fox.');/code>
или что-то существенней имели в виду?
о Dart слышал ранее, но не смотрел примеры. Сейчас, когда можно наглядно сравнить JS и Dart, в некоторых местах Dart достаточно «симпатичен», но какой смысл плодить одинаковые технологии? Не лучше же дальше развивать JS? К примеру, распространении его применения на серверах, улучшению HTML5 JS api и так далее.
Проблем с кроссбраузерностью думаю будет ооочень много, а что будет с ИЕ даже сложно представить :)
Проблем с кроссбраузерностью думаю будет ооочень много, а что будет с ИЕ даже сложно представить :)
Для IE будет плагин который заменяет IE на Хром )
JS уж очень медленно развивается… Dart и JS это не совсем одинаковые технологии. Например, в Dart есть ООП, а в JS каждая либа делает свой ООП. Давно уже хочется нативный ООП, а не очередные костыли.
И еще, плюс в том, что можно указывать типы явно, что позволяет быстрее обнаруживать ошибки (с помощью IDE конечно), во время написания кода.
И конечно куча мелочей, типа неймспейсов, причесанного АПИ и т.д.
Так что я только за разнообразие, в разумных количествах конечно. Может и JS будет шустрее развиваться, потеряв монополию.
И еще, плюс в том, что можно указывать типы явно, что позволяет быстрее обнаруживать ошибки (с помощью IDE конечно), во время написания кода.
И конечно куча мелочей, типа неймспейсов, причесанного АПИ и т.д.
Так что я только за разнообразие, в разумных количествах конечно. Может и JS будет шустрее развиваться, потеряв монополию.
В JavaScript есть ООП. См. Прототипное программирование.
а в JS каждая либа делает свой ООП. Давно уже хочется нативный ООП, а не очередные костыли.O_o Простите, вы ООП представляете только как «C с классами»? Только в C++ и его «наследниках» типа PHP и Java «нативный» ООП реализовано?
Либы не делают ООП, а предоставляют удобный сахар для его использования.
А вообще Дарт выглядит более строгим чем джаваскрипт. И это радует
Только выглядит ;)
В частности, сам факт того, что типизация там опциональна и только на этапе компиляции, получаем тот же JS, вид сбоку
В частности, сам факт того, что типизация там опциональна и только на этапе компиляции, получаем тот же JS, вид сбоку
Я скорее про то что после создания объекта нельзя добавлять удалять ему методы. Считаю что эта возможность вообще верх тупизма в любом языке
Это, вообще-то, очень полезная возможность, если ее применять с умом.
Я не спорю. Просто однажды я столкнулся с одним багом очень неприятным. Копался очень долго. Начал поочередно отключать все библиотеки. Как оказалось одна из библиотек добавляла во все объекты какое-то там свойство, которое потом приводило к ошибке совсем в другой библиотеке. А с умом да, конечно полезная
((){})() // == returns null
Даже страшно представить, что на нём cмогут написать искушённые умельцы.
Уф, лучше бы сделали нормальное IDE для Go.
В случае трансляции в js, Dart со своей замкнутой и почти осутствующей экосредой выглядит бледно на фоне coffeescript, который, помимо отличного синтаксиса, имеет совместимость с js во все стороны.
В случае трансляции в js, Dart со своей замкнутой и почти осутствующей экосредой выглядит бледно на фоне coffeescript, который, помимо отличного синтаксиса, имеет совместимость с js во все стороны.
имхо всем было бы лучше, если бы гугл на CoffeeScript внимание обратили
Как-то по-моему даже хуже стало, судя по сравнениям. Dart <= JavaScript я бы сказал. А можно мне неискушенному сказать чем же он лучше?
возможность строгой типизации и синтаксис местами короче. С другой стороны первый пункт возможно когда-нибудь покроется JS 2.0, не знаю правда когда он в конце концов появится на свет. А второй мне не видится сколько нибудь большим преимуществом.
Одна из офигеннейших фишек JS это возможность в любой момент расширить прототип любого объекта. Поэтому когда появляются новые плюшки типа forEach в браузерах мы сразу делаем вот это: www.tutorialspoint.com/javascript/array_foreach.htm и не думаем в IE мы или нет. А в dart нужно будет танцевать с бубном. Нет то что Javascript легкорасширяемый ему явно на руку. Dart в печь.
По моему скромному мнению, это скорее зло потому как сторона использующая объект ни имеет на него никаких гарантий (пока кучу if'ов не исполнит конечно). Что касается приведённого вами примера, то задача намного лучше решается наследованием.
> сторона использующая объект ни имеет на него никаких гарантий
В общем случае сторона, использующая объект, не имеет на него гарантий ни в одном языке программирования вообще.
Не будет прототипов, будут, анпример, mixin-ы и trait-ы, которые являются теми же яйцами, только в профиль. Но прототипы — зло, а вот миксины и трейты для каждого языка требуют толпы программистов. Логика от меня ускользает
В общем случае сторона, использующая объект, не имеет на него гарантий ни в одном языке программирования вообще.
Не будет прототипов, будут, анпример, mixin-ы и trait-ы, которые являются теми же яйцами, только в профиль. Но прототипы — зло, а вот миксины и трейты для каждого языка требуют толпы программистов. Логика от меня ускользает
> В общем случае сторона, использующая объект, не имеет на него гарантий ни в одном языке программирования вообще.
Да ладно! например написав на C такое:
я уверен что param это целое число, и оно передано. Не надо проверять его на defined и прочее.
Иногда дело доходит до mixin'ов, шаблонов и прочего, но если им передать что-то не то, компилятор укажет на их неверное использование в конкретном месте.
Например:
Да ладно! например написав на C такое:
int foo( int param ) {}
я уверен что param это целое число, и оно передано. Не надо проверять его на defined и прочее.
Иногда дело доходит до mixin'ов, шаблонов и прочего, но если им передать что-то не то, компилятор укажет на их неверное использование в конкретном месте.
Например:
trmplate T square( T v ) { return v * v; }
double v1 = square( 5 ); // 25
const char* v2 = square( "five" ); // compile error
Т.е. метод возвращает что-то разумное или программа не запускается. Разница очень есть.Код на С++ нет смысла приводить, потому что int — встроеный тип, а не объект, а шаблоны — не mix-in'ы
Если, вместо int, передать структуру/класс ничего не изменится.
Использование mixin'ов тоже выдаст ошибку компиляции при некорректных параметрах/окружении.
Вы странные утверждения здесь приводите.
Использование mixin'ов тоже выдаст ошибку компиляции при некорректных параметрах/окружении.
Вы странные утверждения здесь приводите.
> Если, вместо int, передать структуру/класс ничего не изменится.
Изменяется сразу. Потому что, цитирую сам себя: «в JS сторона точно так же имеет гарантию на объект. То, что в String добавили какой-нибудь метод, не делает String менее String'ом»
> Использование mixin'ов тоже выдаст ошибку компиляции при некорректных параметрах/окружении.
А причем тут компиляция. Мы же в контексте, цитирую контекст: «Одна из офигеннейших фишек JS это возможность в любой момент расширить прототип любого объекта.» ЧТо делают миксины? ВНЕЗАПНО они делают тоже самое
Изменяется сразу. Потому что, цитирую сам себя: «в JS сторона точно так же имеет гарантию на объект. То, что в String добавили какой-нибудь метод, не делает String менее String'ом»
> Использование mixin'ов тоже выдаст ошибку компиляции при некорректных параметрах/окружении.
А причем тут компиляция. Мы же в контексте, цитирую контекст: «Одна из офигеннейших фишек JS это возможность в любой момент расширить прототип любого объекта.» ЧТо делают миксины? ВНЕЗАПНО они делают тоже самое
> Изменяется сразу. Потому что, цитирую сам себя: «в JS сторона точно так же имеет гарантию на объект. То, что в String добавили какой-нибудь метод, не делает String менее String'ом»
Я не очень знаю javaScript, но разве нельзя сделать так:
Array.prototype.pop = null;
или
Array.prototype.pop = function() {}
И, потом, я правда не понимаю как это «Изменяется сразу»?
Какие гарантии по вашему исчезают, если всместо int передавать Point например?
Миксины меняют класс/метод на этапе компиляции, а не исполнения. Т.е. мы можем коротко создать определение нового класса или подмешать в определение нужные нам методы.
Может мы говорим о каких-то разных миксинах? Я имею ввиду те, которые есть, например в «D»:
d.digitalmars.com/2.0/mixin.html
Я не очень знаю javaScript, но разве нельзя сделать так:
Array.prototype.pop = null;
или
Array.prototype.pop = function() {}
И, потом, я правда не понимаю как это «Изменяется сразу»?
Какие гарантии по вашему исчезают, если всместо int передавать Point например?
Миксины меняют класс/метод на этапе компиляции, а не исполнения. Т.е. мы можем коротко создать определение нового класса или подмешать в определение нужные нам методы.
Может мы говорим о каких-то разных миксинах? Я имею ввиду те, которые есть, например в «D»:
d.digitalmars.com/2.0/mixin.html
> Я не очень знаю javaScript, но разве нельзя сделать так:
Можно
> Какие гарантии по вашему исчезают, если всместо int передавать Point например?
Исчезает гарантия, что объект будет себя вести так, как мы ожидаем.
Можно
> Какие гарантии по вашему исчезают, если всместо int передавать Point например?
Исчезает гарантия, что объект будет себя вести так, как мы ожидаем.
>> Я не очень знаю javaScript, но разве нельзя сделать так:…
>Можно
Ага! Т.е. массив стал чуточку менее массивом. Согласны?
>> Какие гарантии по вашему исчезают, если всместо int передавать Point например?
>Исчезает гарантия, что объект будет себя вести так, как мы ожидаем.
Я не знаю чего вы ожидаете, конечно, но, если, мы говорим о C/C++, то все невиртуальные методы будут вести себя так-же как определены в классе Point.
Если мы говорим о Java, где все методы виртуальные (если не ошибаюсь), мы всё равно получаем известный интерфейс, который должен быть подвидом Point.
Т.е., когда я пишу код на Java, я могу быть уверен что правильно использую объект, потому что у меня есть формально описанный интерфейс к нему.
Если кто-то другой создал наследника Point, то я могу быть уверенным что он пытался сделать подвид точки а не класс считающий количество «X» и «Y» хромосом.
Почему? Да потому что он прямо так и написал:
class ColorPoint extends Point {},
— Круто да? Человек ясно написал что создал подвид точки, но знаю об этом не только я но и компилятор, который ругнётся если реализация совсем уж косячная.
По-моему намного круче чем:
function ColorPoint()… // мамой клянусь, это подвид класса Point
{
x: 0, // x,y должны быть целыми числами, если
y: 0, // какой-то му--ла запишет сюда что-то ещё
// я не поленюсь, найду где ты живёшь
// и засуну глобус в место которым ты думаешь
clr: "" // строка вида "#ffffff". Честно.
}
PS: я знаю что JS можно сделать приватные переменные и написать интерфейсные методы, но в этом случае ошибка будет выявлена только при исполнении (т.е. не понятно когда).
>Можно
Ага! Т.е. массив стал чуточку менее массивом. Согласны?
>> Какие гарантии по вашему исчезают, если всместо int передавать Point например?
>Исчезает гарантия, что объект будет себя вести так, как мы ожидаем.
Я не знаю чего вы ожидаете, конечно, но, если, мы говорим о C/C++, то все невиртуальные методы будут вести себя так-же как определены в классе Point.
Если мы говорим о Java, где все методы виртуальные (если не ошибаюсь), мы всё равно получаем известный интерфейс, который должен быть подвидом Point.
Т.е., когда я пишу код на Java, я могу быть уверен что правильно использую объект, потому что у меня есть формально описанный интерфейс к нему.
Если кто-то другой создал наследника Point, то я могу быть уверенным что он пытался сделать подвид точки а не класс считающий количество «X» и «Y» хромосом.
Почему? Да потому что он прямо так и написал:
class ColorPoint extends Point {},
— Круто да? Человек ясно написал что создал подвид точки, но знаю об этом не только я но и компилятор, который ругнётся если реализация совсем уж косячная.
По-моему намного круче чем:
function ColorPoint()… // мамой клянусь, это подвид класса Point
{
x: 0, // x,y должны быть целыми числами, если
y: 0, // какой-то му--ла запишет сюда что-то ещё
// я не поленюсь, найду где ты живёшь
// и засуну глобус в место которым ты думаешь
clr: "" // строка вида "#ffffff". Честно.
}
PS: я знаю что JS можно сделать приватные переменные и написать интерфейсные методы, но в этом случае ошибка будет выявлена только при исполнении (т.е. не понятно когда).
Опять вы начали приплетать к разговору неотносящиеся к нему вопросы строгой типизации. Возвращаюсь к контексту:
Так вот. Из всего потока сознания, относящегося непосредственно к прототипам, пока единственным минусом является то, что можно сделать
Любые другие манипуляции с прототипом объекта не меняют контракт на этот объект, ожидаемый в функциях.
На пальцах ив псевдокоде типа Java/C#/C++:
Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
То есть надо уметь отделять мух от котлет, а не лепить в одну кучу коней, людей…
«Одна из офигеннейших фишек JS это возможность в любой момент расширить прототип любого объекта.»
Так вот. Из всего потока сознания, относящегося непосредственно к прототипам, пока единственным минусом является то, что можно сделать
Array.prototype.pop = null;Любые другие манипуляции с прототипом объекта не меняют контракт на этот объект, ожидаемый в функциях.
На пальцах ив псевдокоде типа Java/C#/C++:
class Point {
int getX() { return this.x; }
};
class OtherPoint : Point {
int getX() { return null; }
};
....
void fun(Point p) { print p.getX(); }
fun(new OtherPoint(10)); // оппа
Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
То есть надо уметь отделять мух от котлет, а не лепить в одну кучу коней, людей…
Ну нет, мы говорили о гарантиях. Ну да ладно, соглашусь с вами что: «Любые другие манипуляции с прототипом объекта не меняют контракт на этот объект, ожидаемый в функциях».
Это так, потому что никакого контракта нет, и любые манипуляции с прототипом не приведут к его появлению.
Проверка на наличие методов во время исполнения это не контракт, а ещё один способ ветвления кода, и ещё один способ создавать трудно находимые ошибки.
Контракт не позволяет использовать ваш код неправильным образом, указывая на ошибки до того как программа будет запущена. Этого в JS нет, в Java есть.
Ну и ваш пример:
fun(new OtherPoint(10)); // оппа
Какая оппа? Если не ошибаюсь то «int» это value_type и не может быть null. Если ошибаюсь, то создатель интерфейса ясно дал понять что это значение может быть не актуальным и его надо проверять перед использованием, значит накосячили вы в функции fun() не проверив значение или не поймав исключение.
Это так, потому что никакого контракта нет, и любые манипуляции с прототипом не приведут к его появлению.
Проверка на наличие методов во время исполнения это не контракт, а ещё один способ ветвления кода, и ещё один способ создавать трудно находимые ошибки.
Контракт не позволяет использовать ваш код неправильным образом, указывая на ошибки до того как программа будет запущена. Этого в JS нет, в Java есть.
Ну и ваш пример:
fun(new OtherPoint(10)); // оппа
Какая оппа? Если не ошибаюсь то «int» это value_type и не может быть null. Если ошибаюсь, то создатель интерфейса ясно дал понять что это значение может быть не актуальным и его надо проверять перед использованием, значит накосячили вы в функции fun() не проверив значение или не поймав исключение.
Ладно, будет не null, а будет постоянно 0. Контракт якобы соблюден, но нифига не работает.
Самое веселое, когда возвращаемым значением будет не встроеный тип, а какой-нибудь MyClass*, а программист из OherPoint будет возвращать reinterpret_cast<MyClass*> какая_то фигня ;)
Самое веселое, когда возвращаемым значением будет не встроеный тип, а какой-нибудь MyClass*, а программист из OherPoint будет возвращать reinterpret_cast<MyClass*> какая_то фигня ;)
Это перл конечно:
Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
Как вы представляете себе язык со статической типизацией и возможностью динамически менять прототип? Такое можно сделать конечно, даже на с++, только тогда статическая типизация никак не поможет работать с таким объектом.
Единственный минус в случае с JS — это слабая типизация. Которая к прототипам не имеет отношения вообще.
Как вы представляете себе язык со статической типизацией и возможностью динамически менять прототип? Такое можно сделать конечно, даже на с++, только тогда статическая типизация никак не поможет работать с таким объектом.
слабая типизация != динамическая типизация
строгая типизация != статическая типизация
строгая типизация != статическая типизация
Допустим, поясните на примере.
А что пояснять? :)
Статическая = проверяется на этапе компиляции
Динамическая = проверяется в рантайме
Слабая = грубо говоря, разрешены неявные преобраования типов (да и явные тоже)
Строгая = явные и неявные преобразования типов запрещены, да и вообще запрещены манипуляции с типами, кроме явных функций конвертации (типа toString с сигнатурой int -> string).
Примеры:
С/C++ — статически типизированные, слабо типизированные
PHP/Javascript — динамически типизированные, слабо типизированные (худший вариант)
Haskell — статически типизированный, строго типизированный
Python/Erlang — динамически типизированные, строго типизированные
Обычно абсолютно строгой типизации нет ни в одном языке, потому что это банально неудобно (хотя нсчет Хаскеля я не уверен :) )
Статическая = проверяется на этапе компиляции
Динамическая = проверяется в рантайме
Слабая = грубо говоря, разрешены неявные преобраования типов (да и явные тоже)
Строгая = явные и неявные преобразования типов запрещены, да и вообще запрещены манипуляции с типами, кроме явных функций конвертации (типа toString с сигнатурой int -> string).
Примеры:
С/C++ — статически типизированные, слабо типизированные
PHP/Javascript — динамически типизированные, слабо типизированные (худший вариант)
Haskell — статически типизированный, строго типизированный
Python/Erlang — динамически типизированные, строго типизированные
Обычно абсолютно строгой типизации нет ни в одном языке, потому что это банально неудобно (хотя нсчет Хаскеля я не уверен :) )
Вроде различают сильную (strong) и строгую (strict). В сильной разрешены неявные преобразования не приводящие к потери данных ни при каких условиях (short -> long). В строгой только явные. Вики говорит, что строго типизированный язык из более менее популярных Ada. Классический Си (видимо K&R) та же вики считает вообще нетипизированным.
"(худший вариант)" — спорно, слабая типизация даёт большую свободу и гибкость. Но как любая свобода налагает и большую ответственность, в случае ЯП — на программиста.
"(худший вариант)" — спорно, слабая типизация даёт большую свободу и гибкость. Но как любая свобода налагает и большую ответственность, в случае ЯП — на программиста.
В наследовании на классах сторона ИМЕЕТ гарантию на объект, так как существует такое понятие как полиморфизм и интерфейсы
Ну тогда и в JS сторона точно так же имеет гарантию на объект. То, что в String добавили какой-нибудь метод, не делает String менее String'ом
При использовании интерфейса я знаю что у объекта есть такой-то метод, который принимает такие-то параметры и возвращает такое-то значение. Всегда. В JS это не так. И точка
Да ладно! например написав на C такое:
int foo( int param ) {}
я уверен что param это целое число, и оно передано. Не надо проверять его на defined и прочее.
afaik, например в Java такой код:
public void method (MyObject object) {
object.doSomething();
}
тоже ничего не гарантирует. Я вот уверен, что там — MyObject, а тут бац и мне null передали.
Как это ничего?
В примере «object» это ссылка на объет типа MyObject либо null.
Анологичная сигнатура в JS значит: «object» или не передан, либо null, либо что угодно.
В примере «object» это ссылка на объет типа MyObject либо null.
Анологичная сигнатура в JS значит: «object» или не передан, либо null, либо что угодно.
А какая разница, на что проверять, если всё-равно проверять?
Java:
JavaScript
Можно даже функцию сделать:
Но обычно соглашений достаточно.
Java:
public void method (MyObject object) {
if (object == null) {
throw new MyObjectExceptions('cannot be null');
}
object.doSomething();
}
JavaScript
method: function (object) {
if (!object || typeof object.doSomething == 'function') {
throw new Error('Duck typing is failed');
}
object.doSomething();
}
Можно даже функцию сделать:
method: function (object) {
ensureMethod( object, 'doSomething' );
object.doSomething();
}
Но обычно соглашений достаточно.
И что выполнит ваша doSomething() из javascript? В Java я могу сказать посмотрев в объявление класса, в javascript мне нужно исследовать всю программу.
А откуда вы знаете, что в вашу функцию передали сам класс, а не его наследника с совершенно другим кодом?
Да и вы сейчас нарушаете принцип инкапсуляции?
<trololo-mode>Java менее ООП, чем JS из-за нарушения принципа инкапсуляции</trololo-mode>
Да и вы сейчас нарушаете принцип инкапсуляции?
<trololo-mode>Java менее ООП, чем JS из-за нарушения принципа инкапсуляции</trololo-mode>
Наследник, по определению, является разновидностью базового класса. Если это не так, то это явная ошибка проектирования. Т.е. если для класса А верно что использовать его можно так:
A a;
a.init();
a.do_something();
a.deinit();
То это верно и для наследника «B».
Например здесь функция foo() гарантировано отработает правильно:
Java:
В JavaScript нет, т.к. объект имеющий все нужные методы, может подразумевать совсем другие соглашения по работе с ним, например, необходимо вызвать метод init_external() до init().
> Да и вы сейчас нарушаете принцип инкапсуляции?
Не понял о чём вы.
A a;
a.init();
a.do_something();
a.deinit();
То это верно и для наследника «B».
Например здесь функция foo() гарантировано отработает правильно:
Java:
void utilize_object( A o ) { o.init(); i.do_something(); o.deinit(); }
utilize_object( new A );
utilize_object( new B ); // B extends AВ JavaScript нет, т.к. объект имеющий все нужные методы, может подразумевать совсем другие соглашения по работе с ним, например, необходимо вызвать метод init_external() до init().
> Да и вы сейчас нарушаете принцип инкапсуляции?
Не понял о чём вы.
В JavaScript нет, т.к. объект имеющий все нужные методы, может подразумевать совсем другие соглашения по работе с ним, например, необходимо вызвать метод init_external() до init().
А в Java разве не так? метод есть — а что внутри него напишут вы понятия не имеете. Аналогично — JavaScript — есть метод, вы не знаете, что внутри.
В JavaScript нет, т.к. объект имеющий все нужные методы, может подразумевать совсем другие соглашения по работе с ним
Так всё дело в том, что JS-программисты, с которыми вы работали соглашений не имели, а Java — имели? Ну так это проблема не языка.
В java не так, там есть не просто набор методов, а интерфейс. Все производные это реализации интерфейса. Т.е. мы всегда знаем минимальный набор методов элемента, их возвращаемые и принимаемые параметры. С параметрами в JS вообще туго кстати.
К примеру, Java
interface Car
{
int x();
int y();
…
}
interface Plane
{
int x();
int y();
int z();
…
}
// есть такая функция
int distance( Car c1, Car c2 ) { return… }
MyCar car1, car2;
MyPlane plane1, plane2;
int dst1 = distance( car1, car2 ); // ok
int dst1 = distance( car1, plane1 ); // compile error
int dst1 = distance( plane1, plane1 ); // compile error
Допустим в JS есть функция аналогичная distance(), когда вы её писали даже не подозревали что существует класс Plane, тогда:
int dst1 = distance( car1, car2 ); // ok
var dst2 = distance( car1, plane1 ); // неверное значение
var dst3 = distance( plane1, plane1 ); // неверное значение
К примеру, Java
interface Car
{
int x();
int y();
…
}
interface Plane
{
int x();
int y();
int z();
…
}
// есть такая функция
int distance( Car c1, Car c2 ) { return… }
MyCar car1, car2;
MyPlane plane1, plane2;
int dst1 = distance( car1, car2 ); // ok
int dst1 = distance( car1, plane1 ); // compile error
int dst1 = distance( plane1, plane1 ); // compile error
Допустим в JS есть функция аналогичная distance(), когда вы её писали даже не подозревали что существует класс Plane, тогда:
int dst1 = distance( car1, car2 ); // ok
var dst2 = distance( car1, plane1 ); // неверное значение
var dst3 = distance( plane1, plane1 ); // неверное значение
>А в Java разве не так? метод есть — а что внутри него напишут вы понятия не имеете. Аналогично — JavaScript — есть метод, вы не знаете, что внутри.
вообще знать и не надо. Java — это язык с статической строгой типизацией.
все входные/выходные параметры и их тип заранее известны.
вообще знать и не надо. Java — это язык с статической строгой типизацией.
все входные/выходные параметры и их тип заранее известны.
>А откуда вы знаете, что в вашу функцию передали сам класс, а не его наследника с совершенно другим кодом?
в данном случае можно будет оперировать только с методами и полями класса, которые известны у объекта объекта типа MyObject. Наследник, даже с переопределением методов, все равно будет иметь ту же структуру + свои новые методы и т.п., при этом нарушения архитектуры не будет, а также можно точно знать возвращаемый тип метода.
в данном случае можно будет оперировать только с методами и полями класса, которые известны у объекта объекта типа MyObject. Наследник, даже с переопределением методов, все равно будет иметь ту же структуру + свои новые методы и т.п., при этом нарушения архитектуры не будет, а также можно точно знать возвращаемый тип метода.
явное приведение — всегда проблема самого программиста. он сам подписывается на runtime exception. вообще ее лучше использовать только как в internal классах, либо в уже самом приложении, но не в библиотеке общего назначения, например.
однако хочу заметить, что в примере
>MyMethod((SomeType)123)
будет compile-time error, если SomeType не является наследником int, например. именно статическая типизация избавляет нас от тонн проблем такого типа.
однако хочу заметить, что в примере
>MyMethod((SomeType)123)
будет compile-time error, если SomeType не является наследником int, например. именно статическая типизация избавляет нас от тонн проблем такого типа.
Но тело метода может быть другим. Вы почитайте ветку внимательно
Что в JS, что в Java мы точно знаем, что метод есть.
Что в JS, что в Java мы точно не знаем, что внутри.
Даже в Java, что бы не было написано в объявлении — метод всегда может вернуть null и.
Что в JS, что в Java мы точно знаем, что метод есть.
Что в JS, что в Java мы точно не знаем, что внутри.
Даже в Java, что бы не было написано в объявлении — метод всегда может вернуть null и.
>>Что в JS, что в Java мы точно знаем, что метод есть.
Тогда обоснуйте пожалуйста этот код
var a = [];
iAmSureIworkWithArray(a);
// код в файле __somelib.js line 90009
Array.prototype.push = null;
// код в файле __somelib.js line 90009
iAmSureIworkWithArray(a);
function iAmSureIworkWithArray(array){
if(array instanceof Array){
array.push(«asd»); // array.push is not a function
}
}
Тогда обоснуйте пожалуйста этот код
var a = [];
iAmSureIworkWithArray(a);
// код в файле __somelib.js line 90009
Array.prototype.push = null;
// код в файле __somelib.js line 90009
iAmSureIworkWithArray(a);
function iAmSureIworkWithArray(array){
if(array instanceof Array){
array.push(«asd»); // array.push is not a function
}
}
function iAmSureObjectHasPushMethod(array){
if(array && typeof array.push == 'function'){
array.push(«asd»);
}
}
посмотрите такой код на Java:
public void iAmSureIworkWithArray (Array array){
array.push('asd'); //NullPointerException
}
Вы придумываете проблемы, которых в JS нету и не видите, что точно такой же подход в других языках, например в Java. Будьте объективными — вам JS не нравится потому что он не такой как Java. Вот и всё.
И что? И там и там вы оперируете с чёрным ящиком.
Только в Java есть иллюзия безопасности.
Только в Java есть иллюзия безопасности.
Иногда иллюзия безопасности хуже, чем явная опасность.
Для кого вы пишете приложение? Если вас послушать, то работать с JS кодом будут какие-то уроды, которые удаляют из прототипов массива объекты, стараются всячески обмануть ваш код, передавать что-то безумно похожее на массив и так далее, в то же время с Java-кодом работают какие-то идеальные программисты, которые не знают ни про рефлексию ни про null, ни о чём другом.
«JavaScript такой плохой потому что он не такой как Java»
Во-первых, категоричность это плохо
Во-вторых, будьте объективными
В-третьих, в любом коде рулят соглашения
Для кого вы пишете приложение? Если вас послушать, то работать с JS кодом будут какие-то уроды, которые удаляют из прототипов массива объекты, стараются всячески обмануть ваш код, передавать что-то безумно похожее на массив и так далее, в то же время с Java-кодом работают какие-то идеальные программисты, которые не знают ни про рефлексию ни про null, ни о чём другом.
«JavaScript такой плохой потому что он не такой как Java»
Во-первых, категоричность это плохо
Во-вторых, будьте объективными
В-третьих, в любом коде рулят соглашения
я не могу понять зачем вам знать, что внутри самого метода. это же и есть инкапсуляция, не так ли?
в JS, нельзя знать что вернет метод. нельзя знать «правильные» ли параметры переданы, более того в JS, при подключении какой-либо библиотеки может вдруг оказаться, что метод-то исчез.
и проверка на null — есть правильный тон.
а вот постоянная проверка на наличие даже самого метода — , я думаю, дикость самого языка.
в JS, нельзя знать что вернет метод. нельзя знать «правильные» ли параметры переданы, более того в JS, при подключении какой-либо библиотеки может вдруг оказаться, что метод-то исчез.
и проверка на null — есть правильный тон.
а вот постоянная проверка на наличие даже самого метода — , я думаю, дикость самого языка.
Если язык допускает переопределение сигнатуры метода при наследовании, то сторона имеет гарантию только на то, что метод существует. Что он сможет отработать с ожидаемым набором параметров и типов далеко не факт. Например в родителе метод имел один параметр, а наследник заменил его на метод с двумя. Проверку типа наследник пройдёт, а вот обращение к нему как к родителю вызовет ошибку.
Что это за чушь? На чем вы вообще программируете? Он ничего на заменил. Он его перегрузил
При использовании интерфейса я всегда имею гарантию что метод указанный в интерфейсе существует с сигнатурой указанной в нем
ideone.com/QnApl
При использовании интерфейса я всегда имею гарантию что метод указанный в интерфейсе существует с сигнатурой указанной в нем
ideone.com/QnApl
Точнее даже так ideone.com/q0HvX
Вы лукавите. В Java вы точно не знаете, в каком коде вы исполняетесь, какой версии, что стоит у пользователя. И если у пользователя нету какого-то метода вам никак не получится его использовать, в то время, как в JS этот метод можно динамически подмешать.
Я аж подавился. Потом подумал — ну, если брать во внимание крайние случаи, то да, не знаю.
Но уж добавить метод динамически через reflections я могу всегда.
P.S. уже лет пять как программирую на Java от случая к случаю, так что квалификацию подрастерял. Может, где и ошибаюсь.
Но уж добавить метод динамически через reflections я могу всегда.
P.S. уже лет пять как программирую на Java от случая к случаю, так что квалификацию подрастерял. Может, где и ошибаюсь.
В Java вы точно не знаете, в каком коде вы исполняетесь, какой версии, что стоит у пользователя. И если у пользователя нету какого-то метода вам никак не получится его использовать, в то время, как в JS этот метод можно динамически подмешать.
не понял данного выражения. зачем что либо подмешивать? как такое возможно в Java? подходы, применимые в JS, абсолютно не применимы к здесь.
В новой версии появился Array.prototype.forEach, который я могу прозрачно добавить для старых браузеров
как в Java — так и в C#, вы точно знаете что за либа подключена, и при компиляции используются классы и интерфейсы оттуда. если не будет метода forEach у объекта, то я добавлю либо как extension method, либо унаследую класс и уже с ним буду работать. и более того, я должен ориентироваться на определенный JDK, либо .NET
Я вообще в шоке с того что тут люди пишут
Про интерфейсы я ничего не говорил, только про
Само их существование ничего не гарантирует, их нужно использовать чтобы гарантировать.
В наследовании на классах сторона ИМЕЕТ гарантию на объект. Так вот не во всех языках наследование от базового класса гарантирует, что сигнатура его публичных методов не изменится. Классической перегрузки (несколько методов с одним именем, но разным набором параметров, доступных клиентам) там нет, объявляем метод с другой сигнатурой (то же имя, но другой набор параметров) и новый метод замещает старый для клиентов, к старому можно обратится только внутри наследника через конструкцию типа parent::method. Явно привести наследника к родителю тоже нельзя.так как существует такое понятие как ... интерфейсыСамо их существование ничего не гарантирует, их нужно использовать чтобы гарантировать.
Для новых плюшек лучше сразу ставить Underscore.js — ааффигенно полезную библиотеку.
Одна из офигеннейших фишек JS это возможность в любой момент расширить прототип любого объектаНе фиксированные объекты — это одна из причин тормозов. Фича, на самом деле сомнительная, но так истоически сложилось, что ее используют для Polyfill'ов и она эффективна.
А в dart нужно будет танцевать с бубном.Сейчас есть одна реализация Dart так что не будем.
Ни что не раздражает разработчика больше, чем новый язык программирования (с)
Прошло 10 минут.
Не понимаю, 1) почему они назвали эту статическую табличку app (приложение), и 2) почему эта статическая табличка нормально открывается только в Chrome.
Так, а с Native Client что? Вот это действительно полезная технология. Давно о нем не было слышно.
Очень жаль, что нет конвертации онлайн :( Было бы куда полезней
«Final variables: no support». Хм, вообще-то в JS есть const (правда не везде).
Эмм, по-моему, сравнение ЯП «дарт» и «яваскрипт» вообще есть только в пункте с классами, типизированными функциями и изменением кода в рантайме, а все остальное больше тянет на сравнение стандартной библиотеки и DOM API.
TypeError at rosetta_stone.dart.js:5958 *фейспалм*
Скрипач не нужен.
Скрипач не нужен.
Еще бы на JVM портанули и был бы ништяк :) Можно будет шарить код между сервером и клиентом.
Дык на дарте же можно писать свой сервер. Есть standalone vm, которую можно запускать вне браузера.
Больше того, в нете уже можно найти примеры веб приложения, где и серверная часть, и клиентская на нем же реализована.
Больше того, в нете уже можно найти примеры веб приложения, где и серверная часть, и клиентская на нем же реализована.
Мне нужна совместимость с java…
>на дарте же можно писать свой сервер
а вебсокетный сервер можно сделать, есть готовые либы?
а вебсокетный сервер можно сделать, есть готовые либы?
Не видел, да и не искал — я в курсе постольку-поскольку, просто подписан на рассылку из их форума.
В любом случае, пока что рано про это говорить.
Когда я говорил, что есть примеры приложений — это именно что примеры.
Сам язык находится в состоянии «technology preview», т.е. это даже не альфа.
Новые фичи и багфиксы выкатываются каждый день.
Недавно, помню, был баг найден в чтении файлов с ФС :)
Так что, даже если сейчас вы найдете такую либу, завязывать на ней боевой сервер лично я бы не стал.
Экспериментальные проекты — пожалуйста.
В любом случае, пока что рано про это говорить.
Когда я говорил, что есть примеры приложений — это именно что примеры.
Сам язык находится в состоянии «technology preview», т.е. это даже не альфа.
Новые фичи и багфиксы выкатываются каждый день.
Недавно, помню, был баг найден в чтении файлов с ФС :)
Так что, даже если сейчас вы найдете такую либу, завязывать на ней боевой сервер лично я бы не стал.
Экспериментальные проекты — пожалуйста.
// Dart does not support variable numbers of arguments
А рефлекшн будет какой-нибудь?
А рефлекшн будет какой-нибудь?
eval('alert(«hello from eval»)');
// Dart doesn't support eval(). This is not a bug.
Хм… а как тогда?
// Dart doesn't support eval(). This is not a bug.
Хм… а как тогда?
Синтаксис и сахар это одно, а вот фундаментальное различие — совсем другое.
1. Dart имеет декларативные классы, что сводит на нет Startup Latency (это для JS невозможно)
2. Dart имеет нормальную систему инклюдов, а не костыль сбоку как в JavaScript(AMD) (это возможно будет в JS)
3. из кода Dart можно делать образы (Дамп памяти, Image) и на основе их форкать воркеры без тормозов (это для JS невозможно, точнее очень ограничено возможно)
4. В Dart нет Манкипатчинга, эвалов — значит это простая и быстрая VM — новый код можно будет породить только в воркере. (в JS с точностью наоборот)
5. В Dart нормальные классы и интерфейсы, поэтому на него проще переходить с других языков.
1. Dart имеет декларативные классы, что сводит на нет Startup Latency (это для JS невозможно)
2. Dart имеет нормальную систему инклюдов, а не костыль сбоку как в JavaScript(AMD) (это возможно будет в JS)
3. из кода Dart можно делать образы (Дамп памяти, Image) и на основе их форкать воркеры без тормозов (это для JS невозможно, точнее очень ограничено возможно)
4. В Dart нет Манкипатчинга, эвалов — значит это простая и быстрая VM — новый код можно будет породить только в воркере. (в JS с точностью наоборот)
5. В Dart нормальные классы и интерфейсы, поэтому на него проще переходить с других языков.
Только вот зачем переходить, если в нормальных языках и так всё это есть?
Нормальных языков нет в браузерах, по крайней мере по умолчанию. А Dart возможно будет.
А что мешает существующий нормальный язык в браузер не встроить, а не выдумывать очередной лисапет?
Излишество ЯПОН (языков программирования общего назначения :) ) для браузерных задач? Встроить-то можно, и плагины для некоторых языков (и браузеров) есть такие, но как-то популярностью не пользуются. Возможно потому что JS как-то ближе вестральщикам, чем, например, python.
JS ближе верстальщикам потому, что альтернатив на клиенте не было.
Что мешает сделать так? habrahabr.ru/blogs/webdev/95212/
Что мешает сделать так? habrahabr.ru/blogs/webdev/95212/
я что-то не понял: Array и List типа синонимы? 0_о
«И тут Google поняла, что у JavaScript есть один серьезный недостаток — его придумали не они» :-)
Google превращается в Microsoft?
Google превращается в Microsoft?
Лучше бы они баги в своих продуктах исправляли, а не изобретали велосипеды. Или кинули бы этих «гениев» на саппорт, стыдно ведь — такая крупная компания, а саппорт вообще никакой.
Вот расстарался на сравненеие JS, Dart и мой TIScript/Sciter.
По мне так TIScript как-то по-гуманнее выглядит.
Для тех кому интересно то вот еще одна статья про TIScript vs JS
По мне так TIScript как-то по-гуманнее выглядит.
Для тех кому интересно то вот еще одна статья про TIScript vs JS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google запустила сайт для разработчиков: JavaScript vs. Dart