Чушь

Simpliest
да сижу тут, на досуге, разрабатываю новый язык программирования

... ну или старый, если скрестить C++ и PHP

UPD> фантазирую в общем

 

Работа, ну успел заметить как, в большинстве своём превратилась в повторении одних и тех конструкций для одних и тех же задач.

Например Get/Set для полей объекта. Пару раз методы инстанирования полей объекта меня выручали ( нужно было переопределить поведение одного из потомков, переопределять основной рабочий метод нежелательно ).

Но писать Get / Set каждый раз - накладно. Поэтому используем шаблоны в своём любимом редакторе, прописываем getset и получаем

PHP:

1. <?
2.     public function set{FieldName}(${FieldName}){
3.         $this->${FieldName} = ${FieldName};
4.     }
5.     public function get{FieldName}(){
6.         return $this->${FieldName};
7.     }
8.  

Прописываем FieldName:

PHP:

1. <?php
2.     public function setName($name){
3.         $this->name = $name;
4.     }
5.     public function getName(){
6.         return $this->name;
7.     }
8.  

Что на мой взгляд является той же чушью. Чушью господа обрастает код, чушью.

Код (Text):

1.  
2. <?neophp
3.      class GetSetExample
4.      {
5.          public getset $name;
6.      }
7.      // Что будет равносильно
8.      class GetSetExample
9.      {
10.           private $name;
11.  
12.           public function getName(){
13.                return $this->name
14.           }
15.  
16.           public function setName($name){
17.                $this->name = $name;
18.           }
19.      }

Соответственно методы можно переопределить в наследниках в обоих вариантах

 

ты сказал то, что я пытался сформулировать на протяжении всего поста.

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

Спасибо за доверие, но на данном этапе это к сожалению шутка

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

public getset $name - это getName() и setName()

ну а если кому это не нравится, то он сможет написать "чушь":

PHP:

1. <?php
2.  
3. class ConcreteExample extends Example
4. {
5.  
6.     public function getName(){
7.          return getMyName();
8.     }
9.  
10.     private function getMyName(){
11.          $name = parent::getName();
12.          // ...
13.          return $name;
14.     }
15. }
16.  

 

вот и есть мечта, получить кодогенератор встроенный в ядро zend.

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

 

я примерно раз в пол-года сталкиваюсь с полезностью get / set.

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

Так что +1

 

На первой странице я постарался акцентировать внимание на том, что мне не важно, плоха или хороша данная конструкция.

Меня больше интересует вопрос: почему стандартные конструкции приходится делать через кодогенераторы либо прописывать заново руками. Ведь можно упростить задачу несколько расширив язык

 

http://www.php.ru/forum/viewtopic.php?p=201067#201067
http://www.php.ru/forum/viewtopic.php?p=201113#201113
http://www.php.ru/forum/viewtopic.php?p=201117#201117

Могу сформулировать причины появления "чуши"
1. Недостаточность конструкций. В результате то что можно описать одним-двумя словами растягивается на пять шесть и более слов.
2. Нет множественного наследования. В результате появление в коде делегирования, не всегда оправданного

 

C++, хороший пример

C++ не такой высокоуровневый как php. Мне не нужна работа с памятью, процессором и прочее.

 

Simpliest
Компиляция php-кода? нет это отдельная тема. В кратце: я против

 

сомневаюсь что без правки ядра можно добиться добавления новый конструкций расширением.

 

внимательнее, мне не нужна работа с памятью

UPD> Извините, это я невнимателен
UPD>> две опечатки в одном и том же месте, может быть мне действительно нужна эта работа? Где мой Ктулхку

 

Костян
Речь про чушь, которую приходится писать либо кодогенерировать. Что по сути одно и то же, так как влияет на восприятие кода в целом.

 

"Если не можешь решить проблему, то измени отношение к ней"

Но тут уже вопрос в другом.
С юридической стороны: возможно ли сделать fork
С технической стороны: а хватит ли силенок.