Для любителей PHP

[demongloom]

Собственно, что бы вы хотели видеть в 6 (или в последующих) версиях пхп?

Я к примеру хотел бы:
- Типизацию
- параметрах функций
- Изменение структуры -> и :: на .
- Приведение $this, self:: к единому стилю.
- Возможность использования функций или другого нестандартного содержимого для обьявления констант.
- Возможность использовать для extends в классе больше 1 класса.
- Перегрузка.
- Больше возможностей для переопределения работы языка по отношению к классу/обьекту. Для примера возможность переопределить операцию присваивания.

[Brutus]

- Изменение структуры -> и :: на .
- Приведение $this, self:: к единому стилю.

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

[demongloom]

ну это не только на си, но ИМХО, 1 символ удобней чем 2. Да и путаницы с this/self меньше будет. Я понимаю в чем разница между статичными и не статичными методами.

А вообще, хочется си для веба =)

[oav]

А вообще, хочется си для веба =)

↑

ммм...C#? (ASP.NET)

[charlie]

Однозначно, либо C#, либо Java. Но, учитывая опыт demongloom в ASP, то посоветуем C#.
И еще насчет PHP - вот
p.s:Насчет множественного наследования - имхо, через интерфейсы лучше. Что и сделано в C# и Java.

[oav]

Однозначно, либо C#, либо Java. Но, учитывая опыт demongloom в ASP, то посоветуем C#.
И еще насчет PHP - вот
p.s:Насчет множественного наследования - имхо, через интерфейсы лучше. Что и сделано в  C# и Java.

↑

ASP и ASP.NET общего имеют только в первых трех буквах названия.

[elide]

А вообще, хочется си для веба =)

tntnet, ага

[charlie]

ASP и ASP.NET общего имеют только в первых трех буквах названия

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

[demongloom]

Все бы хорошо, но не хочется проприетарщину :devil_2: .

А вот если бы пхп дотянуть до уровня C#.

Интерфейсы конечно хорошо, но это лишь описание требуемых методов, а не сами методы.

к примеру я делаю собственный класс, который должен емулировать переменную. к примеру tInteger и tfloat.

// хотелось бы
class tInteger extends tVariable, tVariableMath {
}
class tFloat extends tVariable, tVariableMath {
}

// а как получается
class tVariable {
// список функций над переменной.
}
class tVariableMath extends tVariable {
// список математический функций
}
class tInteger extends tVariableMath {
}
class tFloat extends tVariableMath {
}

Просто в чем смысл. На вышеприведенном примере можно выкрутиться сделав class tVariableMath extends tVariable, но а если мне нужны несколько классов, не только tVariable, для этого каждый раз дублировать tVariableMath с различными родителями?

Также хотелось бы видеть (нигде такого не видел) alias для функций.
Сделан же "static" для возможности создания namespace. А если я хочу сгруппировать стандартные функции в namespace? к примеру nArray::getKeys($a) равносилен array_get_keys($a), но я должен писать следующее
class nArray {
static public function getKeys($a) {
return array_get_keys($a); }
}
а можно было бы проще.
class nArray {
static public alias getKeys($a) of array_get_keys($a);
}

Также хотелось бы возможность как в си, когда одна и таже функция (имя) но с разными параметрами может быть определена. И вызывается та, к которой обратились с подходящими аргументами.

[snake]

А вообще, хочется си для веба =)

↑

А в чём, собственно, проблема? Берешь C и пишешь на нем CGI приложение...

[charlie]

Также хотелось бы возможность как в си, когда одна и таже функция (имя) но с разными параметрами может быть определена. И вызывается та, к которой обратились с подходящими аргументами.

Это ты про method(function) overloading. Да, как в Java/C#, в ПХП его нет(хотя помню, вроде в overloading уже в Паскале был). Но, вспоминая, что ПХП есть возможность передавать в функцию произвольное число параметров, делаем так(код для PHP 4)

Код: Выделить всё

<?php
class MethOverClass {
    function MethOverClass() {
        $paramCount = func_num_args();
  if($paramCount == 0) {
            echo "Число параметров:0\n----------------------\n";
        } else {
            echo "Число параметров:$paramCount\nПараметры:(";
            $params = func_get_args();
            echo implode(',', $params).")\n----------------------\n";
        }
    }
}
$first = new MethOverClass;
$second = new MethOverClass(1, 2, 3, 'hi');
?>

Выводит

Код: Выделить всё

Число параметров:0
----------------------
Число параметров:4
Параметры:(1,2,3,hi)
----------------------

Насчет aliasов - такого не видел . Пиши, как в первом случае, оптимизатор скорее всего заменит твою фунцию.

Просто в чем смысл. На вышеприведенном примере можно выкрутиться сделав class tVariableMath extends tVariable, но а если мне нужны несколько классов, не только tVariable, для этого каждый раз дублировать tVariableMath с различными родителями?

Но, имхо, переманная типа tVariableMath - это всегда наследник tVariable. Если представит в виде дерева типы, то

Код: Выделить всё

   tVariable
           |
           |__tVariableString
           |
  tVariableMath
    |
    |____tFloat
    |
    tInteger

[demongloom]

1. Громозко писать в одной фунции различные реализации. Визуально проще было бы несколько разных функций. Плюс дело не только в кол-ве, но и в типе переменных.

2. Ок. Допустим, что в классе tVariableMath описаны функции которые подойдут для типа integer, но не подойдут для tFloat, а также есть сходные функции, которые подойдут к обоим типам. Мне придется делать так что ли?

Код: Выделить всё

tVariable
|
tVariableMath
   |
   |-- tVariableMathFloat -- tFloat
   |
tVariableMathInt -- tInteger

tVariable
| tVariableMath
| | tVariableMathInt
| | |
tInteger

tVariable
| tVariableMath
| | tVariableMathFloat
| | |
tFloat

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

ЗЫ. Допустим что мне надо убрать методы класса tVariable из класса tInteger. В первом варианте мне надо будет дублировать tVariableMath, так что бы не было extends tVariable, а во втором я бы всего лишь убрал tVariable из extends в tInteger.

[charlie]

1. Громозко писать в одной фунции различные реализации. Визуально проще было бы несколько разных функций. Плюс дело не только в кол-ве, но и в типе переменных.

Насчет громоздко - да. Но можно. Тип не играет значения. Это же PHP. На худой конец еще никто не отменял

Код: Выделить всё

function over() {
    if(is_float(func_get_arg(1))) {
         doSomething();
    }elseif(is_integer(func_get_arg(2))) {
        doSomethingInt();
   }
}

2) Насчет твоих типов - имхо, у тебя текст с диаграммой расходится. Вот давай определимся:
tVariable - общие методы для работы с переменными
tVariableMath - методы для работы с математическими переменными. Если у тебя tVariableMath. Здесь мы храним только общие функции для операций над метаматическими переменными. Т.е. по хорошему счету в операции, ну, допустим, сложения я должен проверить - к типу ли tVariable относятся мои параметры. И если нет - то выплываем с ошибкой. По классам же tVariableMathFloat и tVariableMathInt мы должны описать специфичные для их типа операции. Но они должны быть все равно наследниками tVariableMath, ведь, допустим операцию деления не стоит производить над массивами. Получаем как раз иерархию, при нарушении которой все следующие классы не будут иметь смысл. Ну да, при втором типе ты сможешь отцепить спокойно любой класс. Но это будет равносильно тому, что ты вытащишь фундамент из-под дома и будешь уверен, что дом выстоит. А на чем?
В твоем случае, как раз, множественное наследование и не нужно. (Не будем здесь обсуждать плюсы и минусы множ. наследования) Все иерархически связано. Допустим у нас есть дерево обьектов:

Код: Выделить всё

млекопитающие->приматы->люди

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

Допустим что мне надо убрать методы класса tVariable из класса tInteger.

Что значит убрать? tInteger - потомок tVariable, и он обладает всеми свойствами родителя.
p.s: Может давай на ты. Вроде не такое уж большое различие в возрасте!

[demongloom]

1. Пример выбранный мною для обоснования множественного наследования не очень удачен, но я бы от нее не отказался бы.

Код: Выделить всё

1.
tVariable
  |
 tVariableMath -- tVariableMathFloat -- tFloat
    |
   tVariableMathInt -- tInteger

tVariableMath2
  |
tVariableMathInt2
  |
tInteger2

2.
 tVariableMath
 | tVariableMathInt
 | |
tInteger2

Фундаментом tVariable особым не является, это всего лишь такой же набор функций который отвечает за преобразование значия cValue обьекта c одного типа в другой. Причем не изменяя оригинал, а возвращая результат.

Код: Выделить всё

$a = new tInteger(10);
$b = $a->asArray(); // array(10)
$c = $a->asString(); // "10"

Так что это не фундамент, но, основные функции. Методы присваивания и получения (get()/set()/__construct()) реализуются в tInteger.
Поэтому если мне вбредет в голову иметь класс tInteger без tVariable функций, то мне придется помучаться с дублированием классов, в то время как при втором варианте все выглядит прозрачней.

ЗЫ. Я не призываю полностью отказаться от иерархической системы, я предлагаю ее дополнить.

[oav]

Все бы хорошо, но не хочется проприетарщину  :devil_2: .

ммм...www.mono-project.com ? GPL. C#,.NET CLR - все стандартизовано и вполне так себе открыто

[Sonic]

[OffTopic]
Уважаемые программисты, никто не сможет помочь в коде форума? Перекроить его на свой лад?
Это я так, может кто и задумается над этим.
[OffTopic]

[charlie]

ммм...www.mono-project.com ? GPL. C#,.NET CLR - все стандартизовано и вполне так себе открыто

//offtop
А вообще говоря кто-нибудь пробовал писать на mono нормальное ASP.NET приложение. Как, реально работает или пока только поиграться можно?!
И если да- то как там с портированием готовых ASP.NET приложений? Т.е. много ли исправлять приходится?
UPD: Посмотрел, вроде по словам разработчиков, проблем много быть не должно. Но это слова, слова...

[elide]

Уважаемые программисты, никто не сможет помочь в коде форума? Перекроить его на свой лад?

заведи отдельную тему и положи туда TODO и желаемые сроки исполнения.

[Brutus]

А как с лицензией? Не уголовнонаказуемо, случайно? И я вроде слышал, что Invision поставляется закодированный...

[Sonic]

Для Brutus: вроде нет. Надо проверить

[Sparky]

Собственно, что бы вы хотели видеть в 6 (или в последующих) версиях пхп?

Я к примеру хотел бы:
- Типизацию
- параметрах функций
- Изменение структуры -> и :: на . 
- Приведение $this, self:: к единому стилю.
- Возможность использования функций или другого нестандартного содержимого для обьявления констант.
- Возможность использовать для extends в классе больше 1 класса.
- Перегрузка.
- Больше возможностей для переопределения работы языка по отношению к классу/обьекту. Для примера возможность переопределить операцию присваивания.

↑

1. В пятерке предусмотрена типизация для объектов в том числе при передаче методу. Просто она не обязательная. ИМХО только это и нужно, что касается присутствия в языке не ссылочных типов (int, byte etc...), так на мой взляд не нужны они абсолютно... Более того их надо бояться как чумы (именно в PHP).
2. Возможно это и было бы плюсом, но-помоему скорее вопрос личных предпочтений Мне например просто было бы немного удобнее писать, хотя по большому счету без разницы.
3. Типа макросов в С? Помоему в PERL еще есть что то похожее... Мне не разу не приходилось задуматься, что это было бы хорошо за 2 года работы. Хотя может кому то и пригодится, не знаю...
4. Интерфейсов достаточно, а множественное наследование ведет к труднообнаружаемым ошибкам, поэтому от него все и отказалсь ( имею ввиду JAVA, .NET).
5. Да было бы полезно.
6. Тоже не помешало бы.

Делаю вывод - для меня действительно были бы полезны 2 пункта из вышеперечисленных и два добавлю от себя:
1. Перегрузка.
2. Перегрузка операторов.
3. Пространства имен (слышал что эту фичу выкинули в самый последний момент).
4. Возможности для метапрограммирования (что то на подобие атрибутов в C#) - очень порой удобно для автогенерации кода например.

[demongloom]

Namespacecы есть. Просто они несколько необычно выглядят.
Вот пример

Код: Выделить всё

abstract class nVariable {
...
static public function asInteger($a) {
    return self::asType(&$a,"integer");
}    # Function
...
} # Class: nVarible

function get_c($a,$b) {
    nVariable::asInteger(&$a);
    nVariable::asInteger(&$b);
    return $a+$b;
}

echo get_c("1","12c"); // 13

Расширенная перегрузка нужна как воздух, но и пока добился интересных вещей в своем frameworkе.

Код: Выделить всё

DPHP::Import("tInteger"); // ленивая загрузка модуля.

$a = new tInteger(7); // 7
$b = new tInteger(20); // 20
$c = new tInteger(2,1,10,true);
/*
    Часть логики засунута в переменную.
    Можно указать макс/мин значения как вместе так и по отдельности и можно переопределить эти значения,
    а также типа реакции на пороговое значение - это когда после 10 идет 0+Остаток или устанавливаются
    макс и мин значения. Для примера первый вариант 2+12 = 4, а при втором значение будет 2+12 = 10.
*/

/*
    Вот она самая типизация.
    Хотя можно менее жестко, используя nVariable::asInteger;
*/
function a(tInteger $a, tInteger $b) {
      return $a->Plus($b);
}    # function

/*
    Итераторы.
    Очень удобно т.к. часто конструкция for($i = 0; $i <= $a; $i++)
    не совсем удобна, когда проще в foreach засунуть если нужен простой цикл
    без излишеств.
*/
// 7 раз
foreach($a as $key => $val) {
    print_r(a($a,$b)); // 27
}

Вот еще пример.

Код: Выделить всё

    DPHP::Import("tInteger","tByte");

    $a = new tInteger(255);
    $b = new tByte;

    foreach($a as $vKey => $vChar) {

  $b->Set($vKey);
  echo "#$vKey: {$b->GetChr()} <br>";

    }    # foreach

[KiWi]

Для demongloom:
скажи честно, тебе phpclub'а не хватило?
http://phpclub.ru/talk/showthread.php?threadid=67367

[demongloom]

неа :devil_2: .

[KiWi]

неа  :devil_2: .

↑

а что же тогда смылся с phpclub'а, не договорив?
я думал ты понял свои ошибки и ушёл лечиться (:

[demongloom]

это не ошибки, а недостатки языка. впрочем кому недостатки, а кому преимущества.

[Sparky]

Namespacecы есть. Просто они несколько необычно выглядят.
Вот пример

Код: Выделить всё

abstract class nVariable {
...
static public function asInteger($a) {
    return self::asType(&$a,"integer");
}    # Function
...
} # Class: nVarible

function get_c($a,$b) {
    nVariable::asInteger(&$a);
    nVariable::asInteger(&$b);
    return $a+$b;
}

echo get_c("1","12c"); // 13

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

[KiWi]

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

↑

это "неймспейсы"

[demongloom]

1. Смотря кто как считает. Да я несколько ошибся насчет нэймспейсов. Т.К. считал что это лишь только для функций, а не классов и прочего.

2. Мой фрейморк требует жесткой оптимизации. Я глянул по трейсам. К функции для преобразования типа переменной обращение более 19000 раз на участке

Код: Выделить всё

$a = new tInteger(255);
$b = new tByte;

foreach($a as $vKey => $vChar) {

 $b->Set($vKey);
 echo "#$vKey: {$b->GetChr()} <br>";

} # foreach

в следствии чего выполнение такой простой задачи занимает от 1 до 7 секунд :devil_2: .

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

4. Дайте линк на нормальный profiler для пхп!!! xdebug половина функций не пашет, apd тоже самое. Неужели нет ничего нормального?