На счет strpos => pos strstr => str но ведь strlen => length и правильно. Можно допустить некоторые несоответствия оригиналу.
Посмею сделать одно своё предложение: А что если хранить типы и константы в отдельном классе ? Ну вот, например: PHP: <? final class StrTypes { const BOOL = 1024; const UPPER = 2024; const LOWER = 2025; } ?> Вот пример на ваших примерах: PHP: <? var_dump(Str::pos('в', 'какая-то строка', StrTypes::BOOL); var_dump(Str::pos('-', 'какая-то строка', StrTypes::BOOL); Stp::StrCase('string', StrTypes::UPPER); ?>
Да, LGPL это библиотечная, "беззубая" версия GPL. Она такая же строгая, но в отличии от GPL не распространяется та тот код в который был подключён код под этой лицензией. LGPL версии старше первой дружны с прочими лицензиями: коммерческими или нет. И не противоречат оным... почти большенству оных. Пример. Есть библиотека str.php под LGPL и движок "Битрикс". Если программисты "Битрикса" подключают str.php, то никаких проблем нет: str.php имеет свою лицензию, останется открытым, его можно изменять. Если бы str.php была под GPL, то при инклуде str.php в какую-то часть "Битрикса" (мне заплатили за этот пост ) GPL начала бы распространятся по всему движку дальше и дальше - следуя за каждым инклудом "заражённого" файла. В итоге был бы конфликт лицензий и победу бы (не у нас, а ваще в мире) одержала бы GPL. Почему я отметил, что у нас такого не выйдет: разработчики сопрут код и скажут, что так и было. Я имел в виду, что корректое имя твоей EACH_FIRST_UP есть TITLE: str::changeCase('the chronicles of riddick', str::TITLE) - The Chronicles Of Riddick. Согласен, но в данном случае обёртка с красивым именем нужна потому что авторы PHP сволочи и убили Кенни. explode() ужасное название. join() по идеи должен быть частью такого обьекта как массив, а не строки: array(1, 2, 3)->join(', ') - 1, 2, 3. Поэтому лучше обёртку этой функции не делать.
эту либу по идее не будут подвергать обфускации тогда? Я так и хочу. я ваще хочу потом на основе этого класса написать расширение для пыха и подключать его в виде dll-ки или so-файла. И это вот расширение уже в паблик просто так не выпускать (экакой я злодей). Надеюсь, что расширение будет работать быстрее класса. по поводу константы TITLE - если это действительно так - переименую. Проще одно слово написать чем EACH_FIRST_UP, путь даже будет автодополнение. Apple интересное предложение, посмотрим что товарищи скажут по этому поводу. все-таки в strict mode класс наверно работать не сможет. Ну очень не хочется переименовывать его или метод str а еще меня интересует: какие ф-ции добавлять? join не добавляем, а split будем? какие бывают интересные и нужные ф-ции? ну может информацию о словах, входящих в строку, разбить строку на слова и тд. с документацией постараюсь повозиться, дописать ее.
Мне больше нравится то, что сейчас по двум причинам: 1. Не надо запоминать кучу классов. Str для функций, StrTypes для констант. Плюс просто Str - короче. 2. В классе Str нельзя будет использовать self:: для констант. Джоин действительно для класса Array подходит, а не для класса String. Я просто для примера ужасного названия сказал. PHP: <?php return (strrpos($where, $what, $from) === false) ? false : true; // Можн заменить на return is_int(strrpos($where, $what, $from)); PHP: <?php foreach ($what as $w) { $p = self::pos($w, $where, $type, $caseSensitive, $from); if ($p === false) continue; // Я бы добавил эту строку: if ($type == self::BOOL) return true; // нам не надо искать все остальные элементы $a[] = $p; }
1. Стоит все-же переименовать во что-то метод str 2. Стоит реализовать практически все строковые core-методы. Например: . str_replace . str_shuffle . split aka explode . strchr, strrchr(желательно, полноценно) . count_chars . bin2hex, hex2bin, на уровне String, а не Integer . strtr, wordwrap . chr, ord (возможно, стоит реализовать разделение строки на массив чисел и возвращение строки из массива чисел) . ctype_ - функции - тоже сюда хороши бы отнести . levenshtein, strspn, strcspn, hebrev, hebrevc, не знаю, правда, кому они нужны. . метод Escape, включающий в себя: . . # htmlspecialchars - htmlspecialchars_decode . . # html_entity_decode - htmlentities . nl2br, я бы еще добавил необязательный String параметр, позволяющий заменять не на <br /> а на чтото другое. . Семейтво функций printf: sprintf, vprintf, vsprintf, printf . URL Функции 3. C удовольствием бы хотел увидеть классы-обертки для: . 1. Для работы с файловой системой . 2. Для работы с массивами . 3. Для работы с perlRegExp
TheShock о, клевые оптимизации, сегодня сделаю. ого. Сомневаюсь, что у меня получится лучше. сам хочу написать для первых 2-ух пунктов. Третий боюсь не осилю. остальное буду смотреть, пробовать. у меня появилась идея как динамически переключаться между UNICODE & ASCII
они избыточные, имхо: 1. v от обычный отличаются тем, что параметры передаются массивом. это можно проанализировать внутри строки 2. зачем разделение на возвращаемую функцию и выводящую? почему бы не сделать только выводящие, а чтобы напечатать - написать: echo Str::format($str, $array); - 4 функции слились в одну. 3. Да третий - там же только обертка, при том - небольшая - несколько функций - осилишь.
а еще мне не нравится названия методов encode64 и decode64. Алгоритм называется base64, а не 64. Предлагаю сделать еще класс Encryption с двумя константами - DECODE ENCODE В него включить стандартные функции обратимого шифрования (вроде, это только бэйз?) и пару самописных, у которых название метода - название алгоритма и первый параметр - кодировать, или декодировать.
$classname::aStaticMethod(); // Начиная только с PHP 5.3.0 вот блядство. Я на основе этого хотел построить сделать удобное переключение между режимами ASCII и UNICODE
а как на счет того, чтобы сделать обертку над оберткой, или что-то типа того. делаем Str::multibyte(true); , после чего в протектед свойство Str::$mb = true и каждый раз при вызове любого метода проверяется этот параметр if (Str::$mb) . если истина - вызывается мультибайт-метод, если ложь - анси-метод. Аналогично, Str::multibyte(false) - отключает мультибайтовость.
итак, теперь у нас есть один класс Str к которому мы обращаемся. Он подключает классы StrA и StrU. По умолчанию работает юникод-версия. PHP: <?php // вызываем Str::setMode(Str::ASCII); // и мы работаем с аски. // ... что-то делаем Str::setMode(Str::UNICODE); // превед юникод Но тут есть свои накладные расходы - лишний вызов ф-ции. Посмотрим короче, может че-то оптимизирую еще. имхо лучше чем было: 2 версии классов.
TheShock ну вот что-то типа того сейчас сделал. Мне не нравится то, что каждый раз в заголовке ф-ции я указываю значения по умолчанию. В интерфейсе, в базовом классе, в аски версии и в юникод-версии. покажи на куске кода, как будет после перегрузки этой?
Mr.M.I.T. думаю, что это намного медленнее, чем проверка условия. + может я в последствии захочу передавать параметры по ссылке.
Koc, лишний вызов функции, тем более такой легкой, тем более не так часто - это нестрашно, имхо. Более того, если человек работал с ASCII версией, а потом переключился на UNICODE - ему легче перепрофилироваться. Это не очень хорошо, но не страшно Я так понимаю, два класса вообще не будет, но: 1. Не у всех есть возможность выполнить перегрузку 2. Нет возможности пользоваться и мультибайтовыми функциями и анси
та не, некоторые ф-ции самописные, в теле которых че-то типа PHP: <? return preg_replace( '/(?<=^|[\x0c\x09\x0b\x0a\x0d\x20])[^\x0c\x09\x0b\x0a\x0d\x20]/ue', 'mb_strtoupper(\'$0\')', $string); наверно нужно оставить. PHP: <? // в чем отличие return mb_convert_case($string, MB_CASE_UPPER); // от return mb_strtoupper($string); // тут есть тема про извращенцев, может они протестируют быстродействие? а так же StrU, строка 140 и далее - это альтернативный вариант трима. Но если я указываю что нужно тримать '#' - все рушится. Это из-за того, что # - это разделитель паттерна регулярки. Удалить этот кусок? Чувак на php.net писал, что эта ф-ция предоставляет какие-то бонусы
StrU::changeCase возвращает ошибку: Undefined class constant 'EACH_FIRST_UP' Предлагаю заменить константу FIRST_UP в changeCase на FIRST