How to become an author
Search
Write a publication
Pull to refresh

Comments 59

Т.е. вы предлагаете сделать так, чтобы код выглядел еще более мусорным, чем сейчас? Насколько мне известно, в Perl примерно так всё и работает. И это ужасно
Total votes 6: ↑6 and ↓0+6
Чем? Хотя, может, я просто привык.
В Perl это нужно, поскольку к одной переменной можно обращяться и как к скаляру, и как к массиву, и как к хешу (с разным эффектом). Но никто не мешает вместо префикса использовать функции. Просто с префиксом короче.
Total votes 1: ↑1 and ↓0+1
Это чисто субъективное мнение. Просто все эти доллары в коде слишком нагружают его, на мой взгляд. Из-за этого на код, который на перле написан мне вообще тяжело смотреть: слишком много шума от спец.символов
Total votes 1: ↑1 and ↓0+1
Встречал интересную нотацию, когда переменная содержащая структуру или объект пишется с большой буквы, например:
// данные:
$city = 'spb';

// структура:
$City = [
   'slug' => 'spb',
   'name' => 'Санкт-Петербург'
];

Этого более чем достаточно. А автор перемудрил имхо.
Total votes 3: ↑2 and ↓1+1
В перле переменные-скаляры, массивы и хеши (а через них обычно в перле эмулируются объекты) пишутся с разных символов ( $, @, %).
Total votes 1: ↑1 and ↓0+1
Идея интересная, но, как тут правильно замечают, реализация предложена плохая.

Если и рассматривать подобную дифференциацию переменных, то не через имена, а через синтаксис языка. Например, через разные конструкции инициализации.

В статически типизированных языках оно уже есть: объявление типа переменной как раз и выполняет подобную задачу.
This comment wasn’t rated yet0
Не стоит множить сущности сверх необходимого. В современных IDE нет проблемы быстро посмотреть, что скрывается за переменной.
Total votes 4: ↑4 and ↓0+4
Не «строгую типизацию», а «строгий режим контроля типов»
Total votes 1: ↑1 and ↓0+1
На мой взгляд, в PHP просто надо уже ввести нормальную статическую типизацию и можно обходиться без всего этого.
Total votes 4: ↑3 and ↓1+2

Нет смысла делать все языки абсолютно одинаковыми. Зачем нужны 20 разных, но одинаковых языков? Для статической типизации берется другой язык. Это быстрее и надёжнее, чем переделывать php. Тем более, что type hinting там сделан хорошо, кому надо — пользуются.

Total votes 2: ↑1 and ↓10
Более того, благодаря динамической типизации и методу хранения переменных в PHP неплохо type juggling/casting работают. Да с особенностями, но как и в любом языке — нужно знать тонкости и особенности.
This comment wasn’t rated yet0
не надо, спасибо, PHP прекрасен и без этого, по крайней мере 7-ая версия его. Хотя у меня и на 5.6 все прекрасно работало. P.S. ушел с C# ASP.NET MVC в PHP. Нужна была как раз таки слабая типизация.
This comment wasn’t rated yet0
Но PHP зачем-то движется в направлении статической типизации. Зачем, если всё хорошо?
Честно говоря, я работаю с очень большим проектом на PHP и постоянно приходится генерировать комментарии у переменных для того, чтобы IDE нормально подсказывала. Эдакий костыльный контроль типов. Это очень надоедает.
Total votes 2: ↑2 and ↓0+2
Комментарии с типами к переменным приходится писать из-за магических геттеров без аннотаций, а не из-за типизации

Ну по-крайней мере, так в PHPstorm'е
This comment wasn’t rated yet0
Плохая идея. Аргументация хромает, вернее ее вообще нет.
Total votes 5: ↑5 and ↓0+5
Примитивные типы, объекты, массивы и «иные вещи» — суть данные. Вы примитивы(числа, строки etc) с более сложными структурами хотите разделить? А смысл? Почитайте на досуге.
Total votes 1: ↑1 and ↓0+1
Мне кажется, что вы сами усложнили себе задачу. В вашем же коде — имена переменным даны адекватные, есть и комментарии — тут и так все понятно. Если бы вы в начале комментария добавили бы doc-нотацию — /** var int $foo — описание **/, то ide это пережует и в виде подсказки вам все расскажет. Вводить лишние символы — ни к чему. Без строгой типизации все равно любой переменной (хоть с какого символа называть) можно будет присвоить любое значение/объект (читай — выстрелить себе в ногу). Так что тут нужно не имена менять и компилятор (лексер и пр.), а вырабатывать в себе некие принципы (правила) программирования — для этой области есть 100500 книг и рекомендаций.

«Если человек г… н, то как его не называй (прим.: имеется ввиду по имени) — он все равно им останется» (с) — поэтому неважно, как вы называете переменные (с какого символа начинаются, имеется ввиду), главное уметь с ними правильно работать. А есть еще передача параметров в функции, передача по ссылке, динамические параметры/вызов функции ($class->$$property) и пр.

Не совсем понял вообще смысл статьи. Также вы говорите о RFC для PHP...?! Чтобы такой подход утвердить? Спрос не ударит в нос, как говорится, но зачем?
Total votes 1: ↑1 and ↓0+1
Я нем обдумал то, что мои сущности должны изменяться если надо(динамическая типизация). Как выше уже сказали нужно менять, например, инициализацию переменных для разных сущностей(как в языках со статической типизацией )
Total votes 7: ↑0 and ↓7-7
UFO just landed and posted this here
А с чего это структура и объект — не данные?

Это данные, структурированные определенным образом — как и массив или строка. Да даже целое число имеет свою структуру хранения в памяти (порядок байт) — хотя это обычно от программиста на ЯВУ скрыто.
Total votes 2: ↑2 and ↓0+2

Идея вполне ничего но что делать с этим


Осторожно - это не для слабонервных!
class ComboBreaker implements Iterator, ArrayAccess, Countable, Serializable{

    protected $position = 0;

    protected $items = [];

    public function __construct($array = null)
    {
        $this->position = 0;
        if (!is_null($array)) {
            $this->items = $array;
        }
    }

    public function rewind()
    {
        $this->position = 0;
    }

    public function current()
    {
        return $this->items[$this->position];
    }

    public function key()
    {
        return $this->position;
    }

    public function next()
    {
        ++$this->position;
    }

    public function valid()
    {
        return isset($this->items[$this->position]);
    }

    public function offsetExists($offset)
    {
        return isset($this->items[$offset]);
    }

    public function offsetGet($offset)
    {
        return $this->offsetExists($offset) ? $this->items[$offset] : null;
    }

    public function offsetSet($offset, $value)
    {
        if (is_null($offset)) {
            $this->items[] = $value;
        } else {
            $this->items[$offset] = $value;
        }
    }

    public function count()
    {
        return count($this->items);
    }

    public function offsetUnset($offset)
    {
        unset($this->items[$offset]);
    }

    public function __toString()
    {
        return 'combo breaker';
    }

    public function __invoke(){
        echo $this->position;
    }

    public function serialize()
    {
        return serialize($this->items);
    }

    public function unserialize($data)
    {
        $this->items = unserialize($data);
    }
}
This comment wasn’t rated yet0
UFO just landed and posted this here
Если бы эти понятия были одинаковыми(структуры, данные, объекты), они бы считались одним и тем же(и назывались бы одним словом, если это одно и тоже). Поскольку между ними есть различия, я предложил сделать это более явным, разделив их. Для многих просто дико, что в языке программирования не будет переменных(а будет что-то новое им не понятное). Пока структуры, данные и объекты (в PHP по-крайней мере) объединяет лишь то, что они являются именованными областями памяти.
Total votes 7: ↑0 and ↓7-7
UFO just landed and posted this here
UFO just landed and posted this here
Ну я их тоже «сущностями» называл, если нужно было обобщить. От этого эти вещи не становятся одной и той же вещью. Структуры не становятся данными, для программиста это разные вещи. Я призываю их разделить.
Я ещё о том, что например объект это не тип данных, потому что это не данные, это отдельная сущность, которая уже в свою очередь может содержать данные. Со структурами также.
Total votes 6: ↑0 and ↓6-6
Вы так и не объяснили, что дает разработчику явное разделение с помощью какой-то штуки спереди?

Допустим, есть метод 
function someMethod(int $first, array $second) {
    ....
}


У обоих аргументов явно указаны типы данных. Для чего еще необходимо менять $second на *second? Чтобы понять, что это массив? Это уже известно
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
18 февраля 2020. Ответа все еще нет:)
This comment wasn’t rated yet0
Вообще все сущности так или иначе являются областями памяти. Ты вот предложил что-то, но зачем ты это предлагаешь сделать так и не сказал. Предложение ради предложения никому не требуется. Если ты решаешь какую-то свою задачу по проталкиванию RFC, лучше найди что-то очень понятное простое и нужное. Ты предложил фундаменталььные изменения в три строчки ни о чем.
This comment wasn’t rated yet0
А почему бы не мыслить в стиле «всё есть объект типа ...»? Например, объект типа класса SomeClass, объект массива такого-то типа такой-то длины, объект строкового/числового/… типа
Хм… кажется я где-то уже видел…
Total votes 3: ↑3 and ↓0+3
Я тоже пишу на динамически типизированном языке и для этого в имя переменной или ожидаемого параметра подставляю префикс bool_, int_ и.т.п. Чистая «договоренность». Менять для этого синтаксис языка — это перебор.
Total votes 1: ↑1 and ↓0+1
Только имхо лучше суффиксами такие вещи писать, дабы тип не становился важнее её назначения.
This comment wasn’t rated yet0
Давным-давно в WinAPI были приняты префиксы (не в курсе как сейчас), типа «lp» — Long Pointer, думаю префиксы лучше так как сразу понятен тип, а собственно название переменной раскрывает точное назначение. Но я такое использую разве что в id-селекторах, т.е. атрибут name, например, «email», а id — «txtEmail».
This comment wasn’t rated yet0
Из PHP понемногу делают Java (и это хорошо, только пусть он остается лаконичней), а Вы из него Perl хотите сделать? :D Не, спасибо.
Total votes 3: ↑2 and ↓1+1
Если мне склероз не изменяет, то первый PHP — это был DSL для Web, написанный на Perl-е с целью его упросить.
This comment wasn’t rated yet0
Не в курсе, но ~10 лет назад переводил ~1Mb кода с Perl на PHP (это был пакет Spreadsheet::WriteExcel кажется), было довольно непросто, так что уже тогда PHP был от Perl довольно далек (ну и при том я Perl совсем не знал). С Java на PHP переводить было значительно проще, и таких проектов было немало. И с C/C++ на Java тоже. Короче, не нравится мне Perl :)
This comment wasn’t rated yet0
Бро, бросай эту идею, гарантированно не проходная.
This comment wasn’t rated yet0
у автора это вторая статья. первая была 2 года назад. за два года он даже базовых вещей не понял.
честно говоря, я думаю, что это попытка троллинга. :)
Total votes 2: ↑2 and ↓0+2
Тема интересная для того чтобы подумать перед камином в кресле. Т.е. вот память и в ней инфа, можно обращаться к ней и по ссылке и через имя и как-то ещё. А сама инфа может интерпретироваться как угодно (всё зависит от предварительного определения — например та же типизация). В PHP, насколько я понимаю, переменная это по сути структура, с разными служебными полями. Т.е. просто реализация работы с памятью, представленная для веб-программиста как «переменная» (или ссылка).
Что касается использования дополнительных символов (крышки и прочее)… В том же PHP все привыкли использовать $<имя> и при необходимости определяют тип того, что за этой переменной(ссылкой) закреплено. И лучше не менять вот так вот, сразу. Можно упоминать тип данных в имени переменной, но это как правило временное решение (избавляются при возможности).
This comment wasn’t rated yet0
А что если в переменно и объект, и массив и скаляр одновременно? Ну т.е. объект + jsonSerializable + ArrayAccess + IteratorAggregate + __toString?
This comment wasn’t rated yet0
Ужас! Не надо ещё больше мусора вводить! Пожалуйста! Хватит! И так глаза вытекают после этих $, после долгой разработки в Swift'e или питоне. А тут ещё какие то ребусы навыдумывали. Разве не логично идти к упрощению?
Скоро завезут, что можно будет в переменную указывать тип нормальными словами, мол array / boolean. А не это вот всё.
This comment wasn’t rated yet0

В целом, всё так, но за доллар обидно.


Эти самые "$" — одно из мощнейшёих средств метапрограммирования в языке и на несколько порядков повышает его читаемость.


Заголовок спойлера

Ну и вообще сам дизайн языка, почти полностью, реализован так, что он довольно простой, но при этом по любой одной строчке можно понять куда идёт обращений, в каком контексте, какие данные содержит и проч. Я не могу припомнить ни одного языка, который содержал бы похожий уровень читаемости.


Простой пример:


$some->method($a + $b);

// Сразу понятно:
// 1) $some - объект
// 2) method - метод объекта
// 3) В качестве аргумента int или float

Ну и для сравнения аналог на JS:


some.method(a + b);

// 1) some может быть функцией, классом, константой, переменной... Да вообще чем угодно, хоть символом.
// 2) method - это метод, вызываемый у этой функции или прототипа (или ещё у чего угодно).
// 3) a + b - это может быть как строка (потому что конкатентация), так и число (сложение) или вообще NaN.

Так что на доллар не надо "бочку гнать", это очень крутая фича =)

This comment wasn’t rated yet0
если выбирать наименьшее зло, то пусть остаётся только доллар, а не ^%* и прочее.
This comment wasn’t rated yet0

А их нельзя — они зарезервированы давно и используются. По-этому подобная идея из поста физически невозможна (если уж исключать из аргументации то, что это не только визуальный мусор, который ничего не улучшает, но и наоборот, ухудшает и урезает возможности языка).


^ — оператор бинарной исключающей дизъюнкции (если я ничего не перепутал, не пользовался никогда).
% — оператор деления по модулю.
* — оператор умножения.

This comment wasn’t rated yet0
Но ни один из них не может использоваться как префиксный.
Например, символ — может быть бинарным оператором вычитания либо унарным минусом, в зависимости от контекста.
(не критика, просто заметка на полях)
This comment wasn’t rated yet0

А переменные используются только в унарных выражениях?


Ну, мол, что должно быть в таком коде?


const A = [1];
*A = [3];

var_dump([2]**A);
This comment wasn’t rated yet0
Совершенно не понял, что Вы пытались вложить в код выше.
В C++ к слову есть унарные операторы * и & наравне с бинарными.
This comment wasn’t rated yet0
Совершенно не понял, что Вы пытались вложить в код выше.

Пример того почему зарезервированные операторы не могут быть переиспользованы. На второй строчке объявление массива с предложенным синтаксисом от автора поста, а на третьей — конфликт: Либо умножение второй строчки на значение, либо возведение в степень константы из первой строки.


Так что ваше замечание про "префиксность" какое-то совсем непонятное.

This comment wasn’t rated yet0
Что имел в виду автор, я тоже не понял. Как и то, что Вы написали выше.

В C++ выражение a**b совершенно корректно: a * (*b), вторая звёздочка — разыменование указателя b.
This comment wasn’t rated yet0
Причём тут вообще C++? Вы топик не перепутали?
"*" — это умножение.
"**" — это возведение в степень.
«A**B» — это A в степени B и одновременно перемножение на массив, если бы что-то такое было в языке, что предлагает топикастер.
This comment wasn’t rated yet0
То, что автор поста предлагает — это дичь, не спорю.
Я же говорю совсем о другом: на «повторное» использование операторов в разных грамматических контекстах ничему не противоречит и не может быть основанием для утверждений такого рода, как
А их нельзя — они зарезервированы давно и используются.

Нельзя не потому, что они уже используются другого (то есть технически невозможно), а потому, что внесённое в статье предложение — дичь по своей сути.
Приведённый пример на С++ нужен только для иллюстрации вариантов использования одного и того же символа в разных операторах (для минуса таких форм вообще 4: унарный минус, бинарный минус, в составе преинкремента и постинкремента).
Кстати, в PHP нет оператора возведения в степень (**)
This comment wasn’t rated yet0
Кстати, в PHP нет оператора возведения в степень

Предлагаю ознакомиться основами языка: http://php.net/manual/ru/language.operators.arithmetic.php


Нельзя не потому, что они уже используются другого (то есть технически невозможно), а потому, что внесённое в статье предложение — дичь по своей сути.

Как раз таки почти что технически невозможно. Вывод опкодов производится во время раннего статического связывания. Более того — оптимизация этих самых опкодов, частичный DCE и редьюсинг операций (приведение N опкодов в один) — тоже производится до выполнения программы. А выполняется непосредственно уже опкод. Так что операции должны явно указывать на то, что происходит в программе. Отсюда и невозможность определить во время обхода AST является ли это степенью существующей константы или просто переменной. Ну и плюс не стоит забывать о том, что в пыхе линковка полностью ленивая и динамическая, что требует опять же исполнения кода для того, что бы понять окружение в котором оно работает.


Так что техническое решение данной проблемы — это хардкод без вывода типов и реализуется на уровне приоритетов в лексере, что в свою очередь полностью ломает обратную совместимость за счёт того, что данный оператор уже используется и зарезервирован. И добавление ещё какой-то другой логики полностью ломает существующий код.


Надеюсь так понятнее?


Приведённый пример на С++ нужен только для иллюстрации вариантов использования одного и того же символа в разных операторах (для минуса таких форм вообще 4: унарный минус, бинарный минус, в составе преинкремента и постинкремента).

А в PHP минус в двух вариантах. Унарный и бинарный, который однозначно определяется на уровне грамматики. А декремент — это уже другой оператор, т.к. обозначает совершенно иное.

This comment wasn’t rated yet0
Отдельное спасибо за ссылку: пишу на PHP от случая к случаю, это изменение пропустил (вернее не особо следил).
При наличии оператора ** всё сказанное совершенно верно.
Про обратную совместимость — тоже полностью согласен.

Но говорил выше я про несколько иное, в контексте абстрактного языка, а не о конкретно PHP с его грамматикой и идеологией.

В любом случае, дискуссию на этом можно завершить.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr