LIMB CMS - open source - ищет новых разработчиков

[ONK]

pachanga, куда тебе ещё namespace - ов, итак достаточно. Каждый класс мощнейший namespace, каждая функция, метод опять же namespace.
Таких namespace - ов как в С С++ в ПХП ненужно. В ПХП глобальные переменные не являются автоматически доступными для всех процедур.

 

[pachanga]

ПОЧЕМУ не нужно????

Допустим, я сделал класс File, а разработчики сторонней библиотеки также сделали класс File, что же кому-то из нас надо добавлять префиксы типа Limb_File или Your_Super_Library_File??? Делать так - полнейший бред.

-~{}~ 01.06.05 11:22:

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

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

 

[syfisher]

Да ладно, что спорить про php4 и php5. Понятное дело, что php5 - это более продвинутая штука.

Просто LIMB не может перейти пока на пятерку:
1) SimpleTest не поддерживает полностью пятерку (есть некоторые проблемы с моками).
2) WACT, от которого у нас большие зависимости - чисто php4 проект и переход на пятерку пока не скоро. Конечно можно пользовать WACT и с php5 компиляторов в режиме совместимости, но нахер это нужно?
3) В любом случае нам нужна будет работоспособная версия проекта для четверки.

 

[Screjet]

pachanga
Почему же бред?
По моемому, все так делают. Любой разумный префикс к названию класса = единственный вариант.

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

 

[pachanga]

Автор оригинала: Screjet
pachanga
Почему же бред?
По моемому, все так делают. Любой разумный префикс к названию класса = единственный вариант.

Так делают, потому что просто деваться некуда, не от хорошей жизни народ так извращается

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

PHPUnit2_Tests_Framework_AssertTest - реальное название тестового класса из библиотеки PEAR:HPUnit2, это не нормально!

Самое смешное в этой ситуации, то, что разработчики PHP очень не рекомендуют использовать длинные имена для названия классов(типа тормозит), но деваться-то некуда...

 

[neko]

это не название класса, а pear, вот что и в правду ненормально

pachanga
если ты именно в такой трактовке их хочешь, то разницы вообще никакой. syntactic sugar.

другое дело, что язык, где есть какие-то зачатки reflection может дать namespace'ам больше, чем c++ который тут приводят в пример уже 10тый раз.

 

[Screjet]

это не нормально!

Есть решения лучше? Неймспейсы не решили бы проблему. Это был бы всего лишь "костыль".

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

Не только классов. И переменных и ф-ций(методов).

Вообще это не смешно.. Это грустно. Для любых длинных имен должна быть возможность алиасов.

 

[voituk]

другое дело, что язык, где есть какие-то зачатки reflection может дать namespace'ам больше, чем c++ который тут приводят в пример уже 10тый раз.

А вот тут можно поподробнее? Не улавливаю связи между reflection и namespace.

 

[neko]

voituk
думай о get_extension_funcs

 

[pachanga]

Автор оригинала: Screjet
Есть решения лучше? Неймспейсы не решили бы проблему. Это был бы всего лишь "костыль".

Почему же, за примером далеко ходить не надо, вот небольшой Java код:

import java.util.regex.*; 

Pattern p = Pattern.compile("([a-zA-Z])?_([a-zA-Z])");

А можно и так:

java.util.regex.Pattern p = java.util.regex.Pattern.compile("([a-zA-Z])?_([a-zA-Z])");

Что нравится больше?

-~{}~ 01.06.05 18:07:

Автор оригинала: neko
это не название класса, а pear, вот что и в правду ненормально

Подожди, написано же черным-по-белому

class PHPUnit2_Tests_Framework_AssertTest  extends ...

Как раз PEAR и является одним из показательных примеров, т.к непосредственно поставляется с PHP и по-хорошему должен быть эталоном примера разработки на PHP.

если ты именно в такой трактовке их хочешь, то разницы вообще никакой. syntactic sugar.

Не согласен. Допустим, я использую библиотеку A и B, в каждой из них есть свой класс User. Допустим, исправить я не могу код, по разного рода причинам. При совместном использовании возникает fatal error.

Что делать?

Обращаться к производителям A и B? Не думаю, что они с радостью ринутся исправлять User на соответственно A_User и B_User.

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

namespace - не syntactic sugar, а отличное средство изолировать массу кода, обозначив четкие границы.

 

[fixxxer]

Что я могу сказать. Забери последние исходники 5.1 из CVS, добавь поддержку неймспейсов и отправь разработчикам патчи

 

[pachanga]

....эх, мне бы еще года так два лишних, чтобы разобраться в исходниках PHP

 

[neko]

pachanga

namespace - не syntactic sugar, а отличное средство изолировать массу кода, обозначив четкие границы.

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

то что ты хочешь, можно обозначить путем добавления MyNamespace к названиям.

 

[pachanga]

Автор оригинала: neko
namespace, как я уже говорил. можно реализовывать по разному.

то что ты хочешь, можно обозначить путем добавления MyNamespace к названиям.

Глупости, поддержка namespace должна быть встроена в язык, все остальное - dirty hack. Таким макаром можно и exceptions реализовывать.

P.S. я же ведь четко обозначил проблему, когда префиксом просто не обойтись....

 

[neko]

> P.S. я же ведь четко обозначил проблему, когда префиксом
> просто не обойтись....

значит я тебя не понял. можно еще раз?

 

[pachanga]

Допустим, я использую библиотеку A и B, в каждой из них есть свой класс User. Допустим, исправить я не могу код библиотеки A или B, по разного рода причинам. При совместном использовании возникает fatal error.

 

[neko]

это не аргумент вообще.
плохому разрабочику ничего не мешает игнорировать поддержку namespace, создавать массу глобальных переменных итд.

 

[pachanga]

Автор оригинала: neko
это не аргумент вообще.
плохому разрабочику ничего не мешает игнорировать поддержку namespace, создавать массу глобальных переменных итд.

У-у-у, как все тут запущено Мы с тобой битый день воду в ступе мололи. Если приведенный мною выше довод не является по-твоему аргументом, то я отступаю от дальнейшего спора.

 

[neko]

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

 

[pachanga]

Почему-то у меня возникает стойкое ощущение, что мы с тобой о разных вещах говорим. Вот аналог того в Java, что было бы здорово иметь в PHP http://www.unix.org.ua/orelly/java-ent/jnut/ch02_11.htm.

Если лень читать целиком, то вот, пожалуй, самая соль:

One of the important functions of packages is to partition the Java namespace and prevent name collisions between classes. It is only their package names that keep the java.util.List and java.awt.List classes distinct, for example.

-~{}~ 02.06.05 01:04:

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

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

Для меня неприятие namespace(и мнение о нем, как о syntactic sugar) звучит, как если бы аттрибуты классов также должны были бы быть уникальными для всех классов и к каждому надо было бы преписывать префикс названия класса:

class Foo
{
  var $foo_a;
}

class Bar
{
  var $bar_a;
}

С этим тоже можно было бы жить, но ведь это извращение, согласись?