| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Каких возможностей не хватает в PHP? |
| Автор: lukas 7.3.2011, 21:31 | ||||||||||||||||||||||
| Приветствую всех. Меня волнует один вопрос, как видно из названия. Дело в том, что я занимаюсь разработкой интерпретатора php-подобного языка. Я сам программирую на пхп уже более 2х лет и сейчас (правда не так часто). Язык мне полюбился своей гибкостью, конечно он не идеален. В нем не хватает множества вещей, в нем есть множество логических нестыковок. Но т.к. я делаю свой язык с нуля уже пол года и есть довольно хорошие результаты как по скорости выполнения, так и по расширению возможностей языка, я бы хотел узнать мнение именно пхп разработчиков. Возможно, некоторые новые возможности которые я реализовал в рамках языка могут взорвать некоторым мозг, но они вполне логичны и нужны. Язык называется Орион. И так, начнем. 1. Константы - как надоело их объявлять через функцию define, когда констант много, это превращается в лишний копипаст. Ну а как вам такая конструкция:
2. Глобальные переменные и видимость локальных. На мой взгляд в пхп непонятная система видимости переменных, совершенно запутанная, локальная переменная может оказаться глобальной, а может и нет. Также есть SuperGlobals, но нельзя добавлять своих. А как вам такая возможность:
Конечно, теперь символ @ служит не для заглушки сообщений об ошибках, а для обращения к глобальным переменным. И к тому же, есть жесткое ограничение, если вы объявили переменную как $<...>, то она будет всегда локальной. 3. Регистрозависимость отменяется для всего!, для переменных, констант и прочего, где она есть в php
4. Теперь "::" и "->" это бинарные операторы, где слева класс или объект, а справа название метода/свойства и т.д. Чем это светит? Отменяются костыли вроде:
В пхп это костыль, но если у нас эти лексемы будут операторами, тогда это превращается в нормальную конструкцию, и автоматически поддерживается рефлексия:
ООП. 5. Пользовательские свойства с сеттерами и геттерами. Замена костылям __get и __set. Во многих языках (где нормальная поддержка ООП) можно объявлять свойство, у которых есть get функция и set функция, первая возвращает значение свойства, а вторая задает значение свойства. В орионе эти свойства объявляются так:
Пользовательское свойство может не иметь сеттера, тогда оно будет только для чтения и его нельзя будет изменять. 6. Перегрузка операторов для объектов. Для объектов можно перегружать операторы + - / * и т.п., вплоть до присваивания. Как вам? Сразу же представляются классы вроде Matrix, BigInteger или даже искусственный UnicodeString. Конструкцию обращения к объекту как к массиву [ ... ] можно также перегружать вплоть до set и get (как волшебные свойства __get и __set).
7. На закуску, короткое объявление массивов. Сколько раз я писал array, и сколько раз мне это надоедало, то там то тут. Почему в пхп нет возможности коротко объявить массив без этого пресловутого array. В орионе есть такая возможность:
Т.е. поддерживается любой уровень вложенности. В качестве десерта оператор IN вместо функции in_array и в результате получается красивая и понятная конструкция.
И кстати конец кривому strpos(...)!==false, оператор in подходит и для строк:
8. Рефлексия для классов и объектов через общий класс Object, все классы в Орионе неявно унаследованы от класса Object, который имеет методы для рефлексии класса и объекта, что не влияет даже на производительность ООП. Т.е. вы из любого класса или объекта сможете узнать - какие методы у него есть, константы и т.д. 9. Динамически изменяемые методы для классов. В орионе такое возможно. И очень просто. Как это делается? Очень просто, объявляется статическое свойство класса, и этому свойству присваивается анонимная функция. Хочу заметить, что в отличии от php 5.3, в такой метод будет прекрасно передан $this и self, parent.
Прикол в том, что изменения класса повлияют и уже на созданные объекты этого класса. P.S. Все возможности, которые я перечислил уже поддерживаются Орионом на 90%. Движок ориона это компилятор в байт-код и виртуальная машина, это не интерпретатор. Очень хочется почитать мнения людей, которые программируют на пхп профессионально. Также хочу отметить, что это не форк официального php, это разработка с нуля, ссылка доступна в моей подписи. |
| Автор: SneG0K 7.3.2011, 21:57 |
| 1, 6, 7, 8 9 - это альфа-функции Остальное лишее. Регистрозависимость лучше не отменять. |
| Автор: Muerto 7.3.2011, 22:25 |
| 3. Регистрозависимость отменяется для всего не стоит, плюсов в этом не вижу |
| Автор: solenko 7.3.2011, 22:30 |
| Похоже, вы пишете Ruby ) |
| Автор: lukas 7.3.2011, 22:43 | ||
Похоже ruby использовал те парадигмы, которые уже давно придуманы и есть в других более старших языках и вы наверно плохо знакомы с ruby. Ну я раби так иногда посматриваю, и питон, и луа и многие редкие языки. Тем более в раби и питоне все является объектами, а операторы это в неявном виде методы.
Я не вижу плюсов в регистрозависимости. Программист не должен отвлекаться на регистр букв, он должен держать в голове более полезную информацию. |
| Автор: SneG0K 7.3.2011, 22:46 |
| Регистрозависимость - это очень удобная штука, позволяет использовать удобные правила написания кода. Терпеть не могу паскале-подобный синтаксис только из-за отсутствия регистрозависимости. Так я не понял, ваш Орион наследует С-подобный синтаксис или где? |
| Автор: lukas 7.3.2011, 22:53 | ||||
Все как в пхп, а там си-стиль, кроме регистрозависимости. Ну еще по мелочи, отсутствуют волшебные кавычки например. Ну то что регистрозависимость помогает контролировать общий стиль, оно понятно, кто ж вам без него не позволяет соблюдать этот стиль. Тут есть как огромные плюсы, так и минусы. Я например не люблю регистрозависимость, потому-что когда левый разработчик пишет библиотеку, ты должен в добавок еще запомнить регистр названий классов и функций, а каждый разработчик либы использует свой стиль. В итоге бардак и неудобство, отсюда унылые именования функций, вроде my_func_name_this_call, чтобы уж точно никто не ошибался. P.S. Хотел бы добавить, что php 5.2 не способен уничтожать циклические ссылки, в php 5.3 добавили сборщик мусора для циклических ссылок, но вроде он не включен по-умолчанию, а также он может влиять на производительность. Вот скрипт, который приводит к колоссальной утечке памяти в php 5.2
Орион способен обрабатывать циклические ссылки быстро и сразу, без дополнительного сборщика мусора. Чесно говоря я сам иногда забываю как работает сборка мусора у меня и это даже напоминает шаманство. И кстати говоря, самое сложное в реализации языка, это не виртуальная машина, не компилятор, а это сборщик мусора, я столько времени потратил на него. |
| Автор: SneG0K 7.3.2011, 23:06 |
| Для кого ориентирван твой язык? Умеет ли он работать в перемешку с html например? Сколько памяти жрет? Пробовал его сравнивать с PHP по производительности? Сделай его совместимым с PHP, но + твои новые фичи. Кстати, как обстоят дела с ООП? Неймспейсы? |
| Автор: lukas 8.3.2011, 06:41 | ||||
Язык изначально создается для десктоп приложений и как скриптовой движок в играх. По производительности не могу дотянуть до скорости работы массивов в пхп. Операторы, там + - * и т.п. работают немного медленнее, но например вызов функций работает на 40% быстрее, и вызов нативных функций тоже быстрее. Вот тесты: http://code.google.com/p/orionphp/wiki/Orion_Speed_Test и вот http://code.google.com/p/orionphp/source/browse/#svn%2Ftrunk%2Fdemos%2FSpeedTests Жрет памяти столько же как пхп, ну на начальном запуске он жрет только 1 мб памяти, но например большой массив на 1 млн элементов жрет примерно столько же памяти, что и в пхп. ООП поддерживается - наследование, все что я описал выше, protected, private, public, static поддерживается в полной мере, а также конструкторы, деструкторы, некоторые волшебные методы __get, __set. Namespace полноценных нет, ну т.е. есть, просто не до конца сделанные:
Не сделана для namespace'ов зона ограничения видимости. На счет веба, там будет видно, все зависит от того на сколько удастся популяризировать движок, будут ли третьи разработчики писать расширения для языка. Кстати, официальная страница языка будет находится тут: http://orion-lang.org/. Я хотел написать модуль для апачи, но пока рано, язык еще тестится и разрабатывается. Кстати, можно глянуть на юнит-тесты и примерно прикинуть - на сколько язык готов: http://code.google.com/p/orionphp/source/browse/#svn%2Ftrunk%2Ftest Есть еще отличия, echo и print и isset это функции нативные функции. |
| Автор: SamDark 9.3.2011, 00:47 |
| 1. Более-менее, хотя и с define более-менее. 2. Не нужно. С видимостью переменных всё и так нормально. Особенно в 5.3. 3. Плохое предложение. 4. Такое нужно крайне редко. 5. Нормально. Это есть в C# и в компонентах Yii. 6. Слишком магично. Путаницы будет много. 7. Хорошая штука. Десерт про in_array как-то не очень. 8. Рефлексия вроде и сейчас поддерживается. Чем плоха? 9. Интересная возможность, похожая на mixin. Есть в Ruby, реализована для компонент Yii. Вообще не ожидал, что кто-то подобным займётся… |
| Автор: lukas 9.3.2011, 10:12 | ||||
define оставлен как альтернативный вариант, он даже переведен в разряд функции. Просто в вебе возможно столько констант не нужно, но в других областях константы очень нужны и в больших количествах.
Сталкивался я со многими CMS у которых была явная путаница с глобальными переменными, иногда приходилось писать global $var, я понимаю когда модель MVC там этих проблем нет, отсутствует сама причина. Ну я понимаю что редко, но реализация в виде бинарных операторов более органично вписывается в движок, при этом не сказываясь на производительности. Обычно новички не способны понять для чего это нужно, я не имею ввиду вас. Поэтому в эту область будут лезть только профессиональные разработчики ибо нужно хорошее понимание этой возможности, без которого новичкам путь закрыт. Да я знаю что поддерживается, через спец класс. Но мне показалось так будет правильней, если у всех классов будет класс прародитель, обеспечивающий рефлексию и не только.
Вообще она не задумывалась изначально, задумывалась абстрактная возможность изменения поведения класса во время выполнения, которые будут влиять на созданные объекты. Но так получилось, что движок стал универсальным и такая возможность появилась практически автоматически. |
| Автор: ksnk 9.3.2011, 10:42 | ||
а чем не нравится С-шное объявление констант? Через запятую. Вообще - нужно приблизится по синтаксису к какому-нибудь языку- С, Java? но желательно только одному и не мастерить своих примочек. Дело в том, что язык нужен не только разработчику, а новый писатель на этом языке вероятнее всего будет иметь опыт программирования на Java или С |
| Автор: lukas 9.3.2011, 10:59 | ||||||||
Так сделать не проблема.
Одно и тоже. Ну вообще очень спорный вопрос, т.к. константы внутри класса можно объявлять и так:
В этих случаях как то понятнее со скобками, дальше можно продолжать:
Скобки используются и для объявления модулей, я написал выше этот код. Все таки во многих местах используются скобки. |
| Автор: ksnk 9.3.2011, 11:39 | ||
| lukas, скобки "интуитивно" очерчивают область видимости. Или описывают структуры данных. Описывать "внешние" констаны внутри скобок - непривычно, а значит неправильно. Тут нужно думать о людях, которые придут писать на этом языке. Будет ли он им интуитивно понятен? Достаточно написать пару алгоритмов на новом языке и показать любому другому человеку с опытом программироания, чтобы понять какие куски будут непонятны. В принципе - любой язык (за исключением форта, перла местами и лиспа с наследниками
Это-ж почти Бейсик Глобальные переменные - это не зло и не добро. Это просто веревка, которой связываются кусочки кода, и на которой некоторые деятели умудряются повесится. Нужно эту веревку сделать покороче, как в обычных языках программирования, чтобы вешаться было сложнее, а работать это мешало бы не очень сильно. Так что надо не упрощать определение глобальных переменных, а наоборот - ограничить их. вообще - надо решить для себя - что это будет. -- маленький скриптовый язычёк, типа shell, основное назначение которого - скрипты в несколько строк. Тогда нужно максимально открыть глобальные переменные, чтобы писать маленькие вещи было проще и удобнее -- Или большой умный язык, на котором нужно писать большие умные программы, в котором одна прелюдия к программе состоит из несколькоих десятков строк (любая сишная программа |
| Автор: lukas 9.3.2011, 11:54 | ||||
Ну мне казалось это из перла, я слышал когда-то в бейсике по названию переменной определялся ее тип В ruby например @ это переменные объекта, если я не ошибаюсь. Есть идея сделать глобальные переменные вообще без первого символа, так:
Но проблема упирается сразу в контекст, например вызов функций (что в начале - название глобальной переменной или название функции, или это вообще константа). |
| Автор: Ant0ha 9.3.2011, 12:25 |
| Простите, что не совсем в тему. Но зачем вы тратите бесценное время на создание нового языка? Неужели вы считаете, что он сможет конкурировать с тем же php? Хобби? Добавлено через 14 минут и 25 секунд То, чего сейчас в php не хватает, скорее всего, добавят позже. Имхо, это же проще, чем всё с нуля переделывать... Да, и если даже этого и не добавят, я сомневаюсь, что кто-то из-за таких мелочей бросит php... |
| Автор: lukas 9.3.2011, 13:02 | ||
Я видел исходники пхп, любые структурные изменения в них могут обернуться настоящим fail'ом. Они настолько убоги по мне, что их стоило бы переписать с нуля. А они это уже делали. Я просто сравниваю с lua и angel script исходниками. Да отчасти это мое хобби. ПХП не бросят, но с удовольствием будут использовать его в других областях, кроме веб-а (game scripting, десктоп приложения). Я же еще планирую сделать специальное расширение GUI для языка, и интеграцию с 2D движком http://code.google.com/p/zengl/ (для инди игр). (все кроссплатформенное). |
| Автор: lukas 22.4.2011, 13:47 | ||||||||
| Прошу прощения, но появилась интересная идея. Такого я не видел ни в одном языке. Язык Орион (аналог PHP). Во многих языках есть возможность указать тип передаваемого параметра в функцию. В php и орионе такая возможность тоже имеется.
Также можно в качестве типа указывать класс объекта.
В орионе можно будет указывать обобщенные типы для скалярных значений, например: number - можно передавать только int или double значение scalar - можно передавать только скалярные значения, int, double, bool, string, null mixed - можно передавать все, кроме объектов Автоматическое приведение к типу аргументов функции На данный момент, я не знаю, придумал ли я что-то новое или такая возможность имеется в каких-то других языках. Я не знаю ни один язык, где есть похожая возможность. Все понимают, что приведение к типу это рутинная операция, повторяющаеся постоянно. Но это позволяет вылавливать многие ошибки до выполнения. Язык Orion, как и пхп динамический, в котором отсутствует типизация. НО! То что отсутствует типизация, еще не означает что в языке отсутствуют инструменты контроля типов. Итак, перейдем к теме: В Орионе вы можете указать к какому типу приводить передаваемое значение в функцию. Т.е. интерпретатор за вас будет приводить переданное значение к нужному типу. Сейчас все поймете:
Дальше, еще круче, понимаем всю суть извращения... Дело в том, что в приведении значений в скалярные типы нет ничего интересного. А вот если бы значение можно было приводить к объекту определенного класса, вот это было бы очень здорово.
Как мы видим, в функцию MoveTo в конце был передан массив, а функция требует объект класса TPoint. Не беда, мы указали, что нужно привести аргумент $point к объекту класса TPoint автоматически. Т.е. мы передали массив, далее будет создан объект TPoint (т.е. мы передали не того типа), у нового объекта будет вызван метод ->oper:typed( $point ), в котором мы инициализируем объект, где $point аргумент функции, т.е. массив array(200,300). В итоге, в функцию будет все равно передан объект TPoint, даже если мы передадим массив, массив преобразуется в объект TPoint. А если мы передадим не массив, тогда произойдет фатальная ошибка, т.к. в методе ->oper:typed() мы намеренно поставили условие, что только массив можно конвертировать в TPoint, в остальных условиях возвращать false. Заключение. Как разработчики относятся к такой возможности. Данная фишка - автоматическое приведение к типу - позволит легко модифицировать код, сделает код более читабельным, позволит легко отлаживать проекты. Идей где это применить - масса. |