Приветствую всех.

Меня волнует один вопрос, как видно из названия. Дело в том, что я занимаюсь разработкой интерпретатора 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, это разработка с нуля, ссылка доступна в моей подписи.


Это сообщение отредактировал(а) lukas - 7.3.2011, 21:45

1, 6, 7, 8
9 - это альфа-функции

Остальное лишее.
Регистрозависимость лучше не отменять.

Проблема в том, что если есть регистрозависимость, то она должна быть везде и в метода, в пхп же двояко. Я остановился на том, чтобы совсем отменить регистрозависимость, а не наоборот - сделать названия функций и классов тоже регистрозависимыми. 


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


И я бы не сказал, что сеттеры и геттеры лишние. А про 4 пункт, просто мне легче было реализовать эти лексемы как бинарные операторы, что добавило гибкости. 

Это сообщение отредактировал(а) lukas - 7.3.2011, 22:03

3. Регистрозависимость отменяется для всего не стоит, плюсов в этом не вижу

Похоже, вы пишете Ruby )

Похоже ruby использовал те парадигмы, которые уже давно придуманы и есть в других более старших языках и вы наверно плохо знакомы с ruby. Ну я раби так иногда посматриваю, и питон, и луа и многие редкие языки. Тем более в раби и питоне все является объектами, а операторы это в неявном виде методы.




Я не вижу плюсов в регистрозависимости. Программист не должен отвлекаться на регистр букв, он должен держать в голове более полезную информацию.


Это сообщение отредактировал(а) lukas - 7.3.2011, 22:46

Регистрозависимость - это очень удобная штука, позволяет использовать удобные правила написания кода.
Терпеть не могу паскале-подобный синтаксис только из-за отсутствия регистрозависимости.

Так я не понял, ваш Орион наследует С-подобный синтаксис или где?

Все как в пхп, а там си-стиль, кроме регистрозависимости. Ну еще по мелочи, отсутствуют волшебные кавычки например. 

Ну то что регистрозависимость помогает контролировать общий стиль, оно понятно, кто ж вам без него не позволяет соблюдать этот стиль. Тут есть как огромные плюсы, так и минусы. Я например не люблю регистрозависимость, потому-что когда левый разработчик пишет библиотеку, ты должен в добавок еще запомнить регистр названий классов и функций, а каждый разработчик либы использует свой стиль. В итоге бардак и неудобство, отсюда унылые именования функций, вроде my_func_name_this_call, чтобы уж точно никто не ошибался.


P.S. Хотел бы добавить, что php 5.2 не способен уничтожать циклические ссылки, в php 5.3 добавили сборщик мусора для циклических ссылок, но вроде он не включен по-умолчанию, а также он может влиять на производительность.
Вот скрипт, который приводит к колоссальной утечке памяти в php 5.2



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

Это сообщение отредактировал(а) lukas - 7.3.2011, 23:01

Для кого ориентирван твой язык? Умеет ли он работать в перемешку с html например?
Сколько памяти жрет?
Пробовал его сравнивать с PHP по производительности?
Сделай его совместимым с PHP, но + твои новые фичи.
Кстати, как обстоят дела с ООП? Неймспейсы?

Язык изначально создается для десктоп приложений и как скриптовой движок в играх. По производительности не могу дотянуть до скорости работы массивов в пхп. Операторы, там + - * и т.п. работают немного медленнее, но например вызов функций работает на 40% быстрее, и вызов нативных функций тоже быстрее. Вот тесты: http://code.google.com/p/orionphp/wiki/Orion_Speed_Test и вот http://code.google.com/p/orionphp/source/b...os%2FSpeedTests

Жрет памяти столько же как пхп, ну на начальном запуске он жрет только 1 мб памяти, но например большой массив на 1 млн элементов жрет примерно столько же памяти, что и в пхп.

ООП поддерживается - наследование, все что я описал выше, protected, private, public, static поддерживается в полной мере, а также конструкторы, деструкторы, некоторые волшебные методы __get, __set. Namespace полноценных нет, ну т.е. есть, просто не до конца сделанные:



Не сделана для namespace'ов зона ограничения видимости.

На счет веба, там будет видно, все зависит от того на сколько удастся популяризировать движок, будут ли третьи разработчики писать расширения для языка. Кстати, официальная страница языка будет находится тут: http://orion-lang.org/. Я хотел написать модуль для апачи, но пока рано, язык еще тестится и разрабатывается. Кстати, можно глянуть на юнит-тесты и примерно прикинуть - на сколько язык готов: http://code.google.com/p/orionphp/source/b...%2Ftrunk%2Ftest

Есть еще отличия, echo и print и isset это функции нативные функции.

Это сообщение отредактировал(а) lukas - 8.3.2011, 07:01

1. Более-менее, хотя и с define более-менее.
2. Не нужно. С видимостью переменных всё и так нормально. Особенно в 5.3.
3. Плохое предложение.
4. Такое нужно крайне редко.
5. Нормально. Это есть в C# и в компонентах Yii.
6. Слишком магично. Путаницы будет много.
7. Хорошая штука.
Десерт про in_array как-то не очень.
8. Рефлексия вроде и сейчас поддерживается. Чем плоха?
9. Интересная возможность, похожая на mixin. Есть в Ruby, реализована для компонент Yii.

Вообще не ожидал, что кто-то подобным займётся…

define оставлен как альтернативный вариант, он даже переведен в разряд функции. Просто в вебе возможно столько констант не нужно, но в других областях константы очень нужны и в больших количествах.




Сталкивался я со многими CMS у которых была явная путаница с глобальными переменными, иногда приходилось писать global $var, я понимаю когда модель MVC там этих проблем нет, отсутствует сама причина. 




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




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




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




Вообще она не задумывалась изначально, задумывалась абстрактная возможность изменения поведения класса во время выполнения, которые будут влиять на созданные объекты. Но так получилось, что движок стал универсальным и такая возможность появилась практически автоматически.

а чем не нравится С-шное объявление констант? Через запятую. 
Вообще - нужно приблизится по синтаксису к какому-нибудь языку- С, Java? но желательно только одному и не мастерить своих примочек. Дело в том, что язык нужен не только разработчику, а новый писатель на этом языке вероятнее всего будет иметь опыт программирования на Java или С

Так сделать не проблема.


Одно и тоже. Ну вообще очень спорный вопрос, т.к. константы внутри класса можно объявлять и так:

В этих случаях как то понятнее со скобками, дальше можно продолжать:



Скобки используются и для объявления модулей, я написал выше этот код. Все таки во многих местах используются скобки. 

Это сообщение отредактировал(а) lukas - 9.3.2011, 10:59

lukas, скобки "интуитивно" очерчивают область видимости. Или описывают структуры данных. Описывать "внешние" констаны внутри скобок - непривычно, а значит неправильно.

Тут нужно думать о людях, которые придут писать на этом языке. Будет ли он им интуитивно понятен?
Достаточно написать пару алгоритмов на новом языке и показать любому другому человеку с опытом программироания, чтобы понять какие куски будут непонятны.
В принципе - любой язык (за исключением форта, перла местами и лиспа с наследниками   ) интуитивно понятен (на уровне - читаю, пишу со словарем) любому, имеющему паскальное-сишное программистское образование. Язык, который базируется на синтаксисе PHP должен обладать этим свойством. 


Это-ж почти Бейсик  . У него тоже тип переменной определяется по первой букве идентификатора.
Глобальные переменные - это не зло и не добро. Это просто веревка, которой связываются кусочки кода, и на которой некоторые деятели умудряются повесится. Нужно эту веревку сделать покороче, как в обычных языках программирования, чтобы вешаться было сложнее, а работать это мешало бы не очень сильно. Так что надо не упрощать определение глобальных переменных, а наоборот - ограничить их.


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