Как стать автором
Обновить

Комментарии 35

В моих глазах передачи больших структур, таких как массивы, по значению — довольно плохая идея


А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?
А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?


Что за странная ныныче мода,
на хабре спорить с переводом )
А как же copy on write? Не холивара ради, просто вы предлагаете некий проект по улучшению языка, при этом не особо разбираясь в его работе?

Небольшая справка: Автор статьи, Никита Попов, является котрибьютором PHP 5.5 фич, таких как генераторы и сопрограммы.

Думаю, что он все-таки знает о чем говорит.
…а также таких фич как variadic functions и много чего ещё
НЛО прилетело и опубликовало эту надпись здесь
Это зависит от языка, на самом деле.
В последнее время какие-то постоянные тёрки между контрибьюторами — я всё жду, когда у кого-то лопнет терпение, они форкнутся и начнут свой проект. Но опубликованный timeline на 7-ую версию вроде всех устраивает: видимо форк откладывается пока :)
HACK не взлетит по следующим причинам (лично моё мнение):
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.
Единственная причина по которой дарту никогда не стать мэйнстримом это то, что остальные разработчики браузеров отказались имплементить или использовать Dart в своих браузерах. С учетом того что ES6 уже не за горами (с учетом компиляции через traceur можно хоть сейчас писать на нем) то будущее Dart может быть светлым только на сервере.

Что до статической типизации — я не вижу в этом никакой проблемы. Проблемы возникают тогда, когда язык имеет статическую типизацию, не умеет сам вычислять тип исходя из контекста и у него нету возможности использовать полиморфизм параметров. Вот тогда все плохо, да. А так возьмите какой D или Go… Да даже тот же c++. это раньше там надо было писать что-то типа MySuperCollection list = some.getList(); Сейчас же можно написать auto list = some.getList() а компилятор сам все типы выведет. Зато у нас есть возможности провести нормальный статический анализ кода и выявить возможные проблемы быстро и просто. Вопрос реализации по сути.
ES6 хоть и добавляет всякие классы, корутины, let'ы и прочее-прочее, но не исправляет самой сути языка, т.е. просто выполняет роль Coffee и подсахаривает тот страх, что находится внутри самого ядра, увы.

К слову, из перечисленного выше — Haxe вполне себе такой язык со статической типизацией, который я бы хотел видеть вместо JS — очень приятный, советую как-нибудь посмотреть. Он даже собираться в JS умет… =)
не исправляет некоторых недостатков JS (вроде инкапсуляции)

Исправляет. Не настолько по́лно как в других ЯП, в которых модификаторов доступа как минимум 3 штуки, но всё же. Стоит добавить "_" префиксом к любому идентификатору и он становится приватным для своей библиотеки.

и является вполне самостоятельным яп со своим апи, в отличии от TypeScript =(

Для меня это только плюс. На сервере всё работает шустро без каких-либо конвертаций в другие ЯП, а на клиенте пока что просто конвертируем в JS.

Dart много перенял от Java и других ЯП и он весьма не плохо спроектирован. Чего только стоит запрет на сравнение переменных разных типов, неочевидностью которых «славится» JS.
Между ними, как мне видится, нет тёрок. Товарищи просто рассуждают на заданную тему.
Вы про какую-то конкретную тему сейчас говорите?
Летом были достаточно серьезные трения по дальнейшему развитию: тогда как раз обсуждались следующая мажорная версия, phpng. Были громкие «уходы» (Anthony, Sara). Моё субъективное мнение, что обстановка накалялась достаточно серьезно
Я только про эту статью и про этих людей.
НЛО прилетело и опубликовало эту надпись здесь
Нормальное именование сделать нельзя из-за потери обратной совместимости, которую очень бояться потерять. Пример с перекидыванием функций в пространства уже было (см. начало статьи, начиная с «Логичный выход — просто добавить в PHP6 огромное количество алиасов для функций») ну и прочее. А «объектизация» — это попытка убить двух зайцев одновременно — переписать std апи и сделать его унифицированным, и добавить очень красивую и любимую «хотелку».

К слову, вполне не обязательно делать все примитивы объектами, можно просто на этапе парсинга сопоставлять $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
4) Это не решение, т.к. переменная может быть и реальным объектом. Будет осуществляться поиск функции и разруливание типов, когда обычный вызов функции или статичного метода может быть вставлен в код напрямую (уже вместе с адресом функции).

И вообще, какие проблемы решает эта фича? Просто таким образом пытаются решить проблему кривой рантайм библиотеки PHP, при этом расширяя возможности самого языка. Однако, никакие стандартные методы из коробки для примитивов не предоставляются?

А запись типа $a->cos() довольно сомнительна.
Ну так и предполагается не трогать мат. функции, а поменять только работу со строками и массивами
4) На этот вопрос я тоже ответил: habrahabr.ru/post/240561/#comment_8070047
Пых внутри знает какого типа эта переменная на тот момент и сам выберет нужную функцию.

А фича решает простую проблему — каждый примитив останется примитивом, просто с наличием сопоставлений метода сабжа с существующей функцией, а не полноценным объектом с методами.
Дело в том, что он знает о типе в момент выполнения, а в байткод можно вставить прямой адрес вызываемой функции в момент компиляции и JIT'ить его или вызывать более оптимально, чем через поиск по хеш таблице.
А можно вставить один из вариантов, либо метод объекта (если есть), либо алиас примитива при нахождении соответсвий — это может и помедленнее прямого адреса, но значительно быстрее поиска по всему хешу ;)
Честно говоря, я думаю не приживется. PHP программисты любят решать многочисленные проблемы, которые можно было бы исправить уже давным давно. лютое ИМХО в минутку ненависти к PHP
Так долго ненавидеть php можно только с условием что где то глубоко внутри. где то там… вы подавляете в себе желание вернуться к php)
Латентный php-шник? Новый термин в психиатрии?
У меня была идея свести программистов с психотерапевтом. Однако.)) Как-то не так много желающих побеседовать о не привычно забытом: хороших интересных беседах о смыслах жизни)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории