а как это реализовать? не делать же для каждой строки проверку isUTF8? upd: добавил trim и мануал к ней
мне больше нравится идея Шевчука сделать объекты, а не статические функции. но статические - тоже хорошо. Хотя сразу скажу одно замечание-предложение. Идея заменить огромное количество функций меньшим количеством но с константами - хороша. Чем дальше - тем больше она мне нравится. Но раз уже делаешь статичный класс, то делай уже все связанно, а именно: PHP: <?php class Str { const AFTER = 1; const BEFORE = 2; const AFTER_WITH = 3; const BEFORE_WITH = 4; const UP = 5; const DOWN = 6; const FIRST_UP 7; const EACH_FIRST_UP = 8; и обращатся к константе как: PHP: <?php // Сообственно в классе Str public static function str($what, $where, $type = SELF::AFTER // Снаружи класса Str Str::str('s', 'asd, Str::BEFORE); Причин и удобств этого - огромное количество: 1. Ты не загромождаеш глобальное пространство имен (идеологически верно) 2. У каждого человека есть возможность !одним движением руки! полностью переименовать класс 3. Ты не попадешь случайно в новую введенную константу PHP 4. Твоя константа не совпадет с константой пользователя 5. Выглядит красивее. И да, я подумал, может статичный класс даже лучше.
TheShock, спасибо. Именно это я и планировал ему предложить. Обьекты был бы смысл, если бы стринги были обьектны по сути, т.к. они такого все равно не умеют, просто аккуратная функциональная обертка выглядит несколько логичней.
Вот такое еще предложение, чтобы не дублировать код: PHP: <? public static function decode64($string, $urlSafe = false) { if ($urlSafe or self::pos(array('-', '_', ','), $string) !== false) { return base64_decode(strtr($string, '-_,', '+/=')); } else { return base64_decode($string); } } Хотя, если я не ошибаюсь, то тут параметр $urlSafe вообще убрать можно - если в тексте есть символы '-', '_', ',' - strtr и так сработает, если нету - то strtr сработает впустую. На счет функции pos - может добавить еще параметр $returnBool, который бы просто возвращал - есть один из символов, или нету. Ибо self:os чаще всего именно для этого и используется.
и просто предложение по стилю кодирования. понимаю, что это субъективно, но все-же PHP: <?php // Подобное if ($p === false) continue; // Заменить на if ($p === false) { continue; } Сам раньше по сокращенному стилю писал, но потом перешел на длинный: 1. Уменьшается вероятность случайной ошибки 2. Четко видны границы if-else 3. Легко добавить еще одну строку в любой из блоков.
и да PHP: <?php if (str::pos(array( // Такое лучше тоже заменить на if (self::pos(array( Опять же, чтобы легче было переименовать весь класс одним махом
я ща на работе, особо времени нет писать. По поводу констант: их же нельзя вроде в интерфейсе размещать? тогда нужно будет мне в каждом класе писать эти самые константы. Или делать класс-родитель остальное учту, было б время
Тоже отмечусь. Хотца, да. P.S. И пожелание, не переверать имена функций. Не менять trim(), например, на strip(). Живой пример - caseLetters(). Просто case(). И так ведь очевидно, что letters. Можно назвать changecase. P.P.S. TheShock, имя EACH_FIRST_UP это TITLE обычно. В английском по правилам в заголовке или названии следует писать каждое слово с большой буквы. И то и то - не что иное как "title".
GNU General Public License v3 - плохая лицензия, всепоглощающая (как Пакман, да ). Надо LGPL > 1 - чтобы распространялась в пределах класса, но не лезла на файлы, куда класс будет подключён.
lexa, не понял обращения ко мне, извини. имя EACH_FIRST_UP - это константа, именованная по всем правилам именования констант Мое предложение забрать константы из глобальной убласти видимости и убрать префикс STR_ С другой стороны я бы некоторые поменял. Например ужасные explode и implode на split и join соответственно (хотя Джоин есть, но он - алиас, а split - это вообще часть устаревшего ерег)
а мне так нравятся название implode-explode. case вроде низя, интерпретатор ругается что тут не может быть никакого case. Поэтому caseLetters LGPL это для библиотек типа? просвятите. Эх, столько всего хочу поизменять а мне на завтра в бурсе много чего сдавать нужно.
Koc Логично сделать PHP: <?php /** * Change string case * * @param int $case Defines to what case to change * @param string $what String to change * @return string Returns string changed to specified case * */ static function caseTo(int $case, string $what) {} Логично и удобно. И соответственно 2 константы - self::UPPER, self::LOWER
кстати, при error_reporting (E_ALL | E_STRICT); Код (Text): Strict Standards: Redefining already defined constructor for class Str in /home/shock/Web/www.phpwr.lh/Engine/Classes/Str.php on line 17 Строка содержит: Код (Text): public static function str($what, $where, $type = STR_AFTER, $caseSensitive = true, $abortIfNothing = false)
Apple да знаю я, знаю) Тем более switch использую в этом классе over 9000. TheShock оно и понятно. До 5 версии пыха конструктор - эта метод, у которого имя такое же как и у класса. Я поставил заглушку PHP: <? private function __construct() {} , у которой якобы приоритет выше и теперь str не считается конструктором. А вот в стркт моде, о котором в пыхе я впервые сейчас узнал всплыло такое... (я сталкивался со стрикт моде в мускле, но не в пыхе). так вот. Тут дело в том, что Str::str - это проапгрейдженная strstr, а Str:os - strpos. Закономерность я думаю видна. Как быть - я х3. Переименовывать класс или метод не хочется как-то. у меня 4 режима. И они имхо меняются реже, чем строка, регистр которой приводим. Поэтому строку на 1 место, режимы потом такой бок я один раз допустил в каждом классе. Исправил имхо сомнительно. тут дело в том, что как бы если указан true параметр urlsafe то ф-ция отработает быстрее, так как не будет тратить ресурсы на поиск символов. Хотя это паранойя наверно у меня. по поводу констант - согласен, переделал это место, сейчас буду коммитить.
http://code.google.com/p/strclass/sourc ... 200355901# коммит готов. Кстати, есть такая тема на google-code как code review. Прямо в коде, в конкретной ревизии можно писать комменты, что типа этот ваш кусок - гавно. Так в чем же все-таки преимущество интерфейсов? И как сделать ожин класс и для юникода и для аскии?
Koc Фигурные скобки надо ставить, иначе форматирование кода не происходит. К тому же когда у тебя идёт сплошной код, очень плохо видно условия и циклы. Я вот щас отучаю от этой привычки некоторых, потому что местами код превращается в макароны, пока не расставишь фигурные скобки. По поводу следования параметров - можно и так, но я не предусматриваю дефолтного значения для case параметра - указывать надо всегда, т.к. это не тот метод, который может что-то преобразовать по дефолту.
Их не из-за красоты надо ставить. Пример из одного проекта (не php) Код (Text): ... is_authed = getAuth(a); if (a == BBB) DEBUG("a == BBB"); is_authed = getAuth(b); ... А код ушел заказчику. Поэтому сейчас ставлю скобки на каждый блок)
выполнено, но не тестировалось. http://code.google.com/p/strclass/sourc ... b0837744bd PHP: <? var_dump(Str::pos('в', 'какая-то строка', Str::BOOL); var_dump(Str::pos('-', 'какая-то строка', Str::BOOL); еще провел рефакторинг констант, AFTER теперь объеденина с RIGHT, так как это по сути одно и то же. Хочу еще объеденить некоторые. Мануал отстает от версии что в репозитории.