Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
В моих глазах передачи больших структур, таких как массивы, по значению — довольно плохая идея
А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?
А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?
Что за странная ныныче мода,
на хабре спорить с переводом )
А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?
Небольшая справка: Автор статьи, Никита Попов, является котрибьютором PHP 5.5 фич, таких как генераторы и сопрограммы.
Думаю, что он все-таки знает о чем говорит.
В последнее время какие-то постоянные тёрки между контрибьюторами — я всё жду, когда у кого-то лопнет терпение, они форкнутся и начнут свой проект. Но опубликованный timeline на 7-ую версию вроде всех устраивает: видимо форк откладывается пока :)
HACK + HHVM?
HACK не взлетит по следующим причинам (лично моё мнение):
1) Не исправляет проблемы внутри АПИ
2) Добавляет свои совершенно отвратительные конструкции, вроде "==>"
3) Строгая типизация иногда зло (в мире веб разработки намного лучше чувствуют себя ruby, python, php, js, coffee и прочие, нежели TypeScript, Dart, C++, Haxe, и т.д… Но есть исключения, вроде .NET и Java, которые живут только благодаря тому, что это языки, принятые в основном в корпоративном секторе).
1) Не исправляет проблемы внутри АПИ
2) Добавляет свои совершенно отвратительные конструкции, вроде "==>"
3) Строгая типизация иногда зло (в мире веб разработки намного лучше чувствуют себя ruby, python, php, js, coffee и прочие, нежели TypeScript, Dart, C++, Haxe, и т.д… Но есть исключения, вроде .NET и Java, которые живут только благодаря тому, что это языки, принятые в основном в корпоративном секторе).
В Python, Ruby и Java как раз таки строгая (сильная) типизация в отличии от PHP.
В Dart опциональная типизация. Он себя отлично в вебе чувствует. Просто не сильно популярен.
Под «лучше чувствует» я и подразумевал как раз популярность. Но Dart не плох, не спорю, жаль только не исправляет некоторых недостатков JS (вроде инкапсуляции), и является вполне самостоятельным яп со своим апи, в отличии от TypeScript =(
Вообще моя мечта — это заменить js простым java-style языком со слабой динамической типизацией (т.е. оставить такую же типизацию), как в JS, но убрать всякие undefined, NaN, void(0) и прочие — оставить только null.
Вообще моя мечта — это заменить js простым java-style языком со слабой динамической типизацией (т.е. оставить такую же типизацию), как в JS, но убрать всякие undefined, NaN, void(0) и прочие — оставить только null.
Единственная причина по которой дарту никогда не стать мэйнстримом это то, что остальные разработчики браузеров отказались имплементить или использовать Dart в своих браузерах. С учетом того что ES6 уже не за горами (с учетом компиляции через traceur можно хоть сейчас писать на нем) то будущее Dart может быть светлым только на сервере.
Что до статической типизации — я не вижу в этом никакой проблемы. Проблемы возникают тогда, когда язык имеет статическую типизацию, не умеет сам вычислять тип исходя из контекста и у него нету возможности использовать полиморфизм параметров. Вот тогда все плохо, да. А так возьмите какой D или Go… Да даже тот же c++. это раньше там надо было писать что-то типа MySuperCollection list = some.getList(); Сейчас же можно написать auto list = some.getList() а компилятор сам все типы выведет. Зато у нас есть возможности провести нормальный статический анализ кода и выявить возможные проблемы быстро и просто. Вопрос реализации по сути.
Что до статической типизации — я не вижу в этом никакой проблемы. Проблемы возникают тогда, когда язык имеет статическую типизацию, не умеет сам вычислять тип исходя из контекста и у него нету возможности использовать полиморфизм параметров. Вот тогда все плохо, да. А так возьмите какой D или Go… Да даже тот же c++. это раньше там надо было писать что-то типа MySuperCollection list = some.getList(); Сейчас же можно написать auto list = some.getList() а компилятор сам все типы выведет. Зато у нас есть возможности провести нормальный статический анализ кода и выявить возможные проблемы быстро и просто. Вопрос реализации по сути.
ES6 хоть и добавляет всякие классы, корутины, let'ы и прочее-прочее, но не исправляет самой сути языка, т.е. просто выполняет роль Coffee и подсахаривает тот страх, что находится внутри самого ядра, увы.
К слову, из перечисленного выше — Haxe вполне себе такой язык со статической типизацией, который я бы хотел видеть вместо JS — очень приятный, советую как-нибудь посмотреть. Он даже собираться в JS умет… =)
К слову, из перечисленного выше — Haxe вполне себе такой язык со статической типизацией, который я бы хотел видеть вместо JS — очень приятный, советую как-нибудь посмотреть. Он даже собираться в JS умет… =)
не исправляет некоторых недостатков JS (вроде инкапсуляции)
Исправляет. Не настолько по́лно как в других ЯП, в которых модификаторов доступа как минимум 3 штуки, но всё же. Стоит добавить "_" префиксом к любому идентификатору и он становится приватным для своей библиотеки.
и является вполне самостоятельным яп со своим апи, в отличии от TypeScript =(
Для меня это только плюс. На сервере всё работает шустро без каких-либо конвертаций в другие ЯП, а на клиенте пока что просто конвертируем в JS.
Dart много перенял от Java и других ЯП и он весьма не плохо спроектирован. Чего только стоит запрет на сравнение переменных разных типов, неочевидностью которых «славится» JS.
Между ними, как мне видится, нет тёрок. Товарищи просто рассуждают на заданную тему.
Кстати, по поводу тёрок: blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html
Нормальное именование сделать нельзя из-за потери обратной совместимости, которую очень бояться потерять. Пример с перекидыванием функций в пространства уже было (см. начало статьи, начиная с «Логичный выход — просто добавить в PHP6 огромное количество алиасов для функций») ну и прочее. А «объектизация» — это попытка убить двух зайцев одновременно — переписать std апи и сделать его унифицированным, и добавить очень красивую и любимую «хотелку».
К слову, вполне не обязательно делать все примитивы объектами, можно просто на этапе парсинга сопоставлять $some->length() функции mb_strlen($some), например составив какую-то такую карту алиасов: 'length' => ['mb_strlen' => 1], которая будет обозначать, что для метода length надо использовать функцию mb_strlen, где ссылка на $this (т.е. ссылка на примитив с которым происходят операции) будет передаваться в качестве первого аргумента. Ну или что-то подобное.
К слову, вполне не обязательно делать все примитивы объектами, можно просто на этапе парсинга сопоставлять $some->length() функции mb_strlen($some), например составив какую-то такую карту алиасов: 'length' => ['mb_strlen' => 1], которая будет обозначать, что для метода length надо использовать функцию mb_strlen, где ссылка на $this (т.е. ссылка на примитив с которым происходят операции) будет передаваться в качестве первого аргумента. Ну или что-то подобное.
Без строгой типизации (хотябы в виде типизации параметров, в таком случае можно анализировать и переодически заменять, это можно использовать для оптимизация, пример) не получится сопоставить $some->length() функции mb_strlen($some), так как php не типизированный, никто не знает каких типов будет эта переменна, так что в случае с php примитивами — это утиная типизация, мы просто знает что у переменной должен быть метод и вызываем его
Достаточно того, что php знает какой тип у переменной в тот момент времени, когда мы вызываем у неё length() и сам сопоставляет с оригинальной функцией. Этот пример (и соответственно комментарий) был рассчитан только на то, что бы показать, что реализовать ОО интерфейс у примитивов можно вполне без серьёзных затрат по оперативной памяти и процессорному времени.
Такая фича создает опасность конфликта имен, когда например 2 библиотеки добавляют метод к типу с одним и тем же названием. И еще в добавок к этому, сложно найти в коде весь набор методов типа, если их будет несколько, особенно когда каждая библиотека будет добавлять что-то свое. И есть большая вероятность, что вызовы в таком стиле по производительности будут проигрывать обычным функциям в 2-10 раз.
1) Существует так же опасность, что любая глобальная функция будет конфликтовать.
2) Ничего не мешает просто запретить добавлять методы в примитивы, а предоставлять просто готовый набор.
3) Есть пространства имён: use Some\Any\StringType; для импорта методов из Some\Any\StringType;
4) Про производительность я уже упоминал выше: habrahabr.ru/post/240561/#comment_8069813
2) Ничего не мешает просто запретить добавлять методы в примитивы, а предоставлять просто готовый набор.
3) Есть пространства имён: use Some\Any\StringType; для импорта методов из Some\Any\StringType;
4) Про производительность я уже упоминал выше: habrahabr.ru/post/240561/#comment_8069813
4) Это не решение, т.к. переменная может быть и реальным объектом. Будет осуществляться поиск функции и разруливание типов, когда обычный вызов функции или статичного метода может быть вставлен в код напрямую (уже вместе с адресом функции).
И вообще, какие проблемы решает эта фича? Просто таким образом пытаются решить проблему кривой рантайм библиотеки PHP, при этом расширяя возможности самого языка. Однако, никакие стандартные методы из коробки для примитивов не предоставляются?
А запись типа $a->cos() довольно сомнительна.
И вообще, какие проблемы решает эта фича? Просто таким образом пытаются решить проблему кривой рантайм библиотеки PHP, при этом расширяя возможности самого языка. Однако, никакие стандартные методы из коробки для примитивов не предоставляются?
А запись типа $a->cos() довольно сомнительна.
Ну так и предполагается не трогать мат. функции, а поменять только работу со строками и массивами
4) На этот вопрос я тоже ответил: habrahabr.ru/post/240561/#comment_8070047
Пых внутри знает какого типа эта переменная на тот момент и сам выберет нужную функцию.
А фича решает простую проблему — каждый примитив останется примитивом, просто с наличием сопоставлений метода сабжа с существующей функцией, а не полноценным объектом с методами.
Пых внутри знает какого типа эта переменная на тот момент и сам выберет нужную функцию.
А фича решает простую проблему — каждый примитив останется примитивом, просто с наличием сопоставлений метода сабжа с существующей функцией, а не полноценным объектом с методами.
Честно говоря, я думаю не приживется. PHP программисты любят решать многочисленные проблемы, которые можно было бы исправить уже давным давно. лютое ИМХО в минутку ненависти к PHP
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методы в примитивных типах PHP