Есть мысль написать класс (возможно статический) для максимально удобной работы со строками. А стОит ли? что в нем должно быть? Значительно ли он снизит производительность? Надоело просто что аргументы перемешиваются и так и сяк. Прототип такой обертки
Между прочим легковесная обёртка над строковыми функциями с упорядоченной последовательностью параметров ой как поможет. Я очень заколебался постоянно лазить в мануал и смотреть какой же там порядок, потому что функций слишком много что бы запомнить, а используются они не настолько часто.
Psih а в IDE нет подсветки разве с кратким мануалом? Типа такого: а наверно клево было б на Сях в виде расширения че-нить такое написать.
ну нафиг Шевчука, по теме, считаю так: если тебе будет так удобнее, делай, у меня как-то не возникало пока проблем...
Koc Подсветка то есть, но если честно - она бывает глючит и не показывается когда пишешь параметры, или когда пишешь вызов в вызове другой функции. Бывает она тупо не успевает за тем, как я пишу код. Да и разная очерёдность параметров просто сбивает с толку. Нужно остановится, вспомнить и потом тока делать, т.е. отвлекаться от задачи. Мне лично это мешает и постоянно пишу не так параметры у строковых функций. Это наверно единственная часть PHP, где у меня постоянные глюки и без дебага никак
Я не знаю как кому, но мне не нравится, что обычно указатель идет перед действием. file_put_contents('имя файла', 'содержимое') — почему имя файла идет ДО, а не после? Так и c fwrite, ... ИМХО мне удобнее было бы наоборот.
PHP: <?php class UFunc { public static function file_put_contents($content, $filename) { file_put_contents($filename, $content); } } UFunc::file_put_contents('Hello, World', 'abc.txt');
c файлом все равно, а вот со строками - наболело. да, что-то типа такого и планирую делать, расширив своими ф-циями, типа той, что в 1 сообщении.
Дак а для чего иначе пишут оболочки? Вот, например: PHP: <?php $file = new FileHandler('file.txt'); $link = new FileHandler('links.txt'); if($link->Exists) { $link->Copy($file->ReadString(3)); } ?> Это пример того, как я когда-то реализовывал оболочку. Причем мне было важно не просто переписать внутренние функции и перенастроить их, но и дополнить нужным мне функционалом и УДОБСТВОМ. Так что, если не удобно пользоваться чем-то или недостает функционала - you're welcome =) Когда-то по аналогу C#: PHP: <? if(File::Exists('file')) { File::Delete('file'); } try { File::Create('abc.txt'); // А вот тут удобно, когда имя файла вначале File::WriteLine('abc.txt', 'Hello, World', WriteMode::Append); } catch(FIOException $e) { echo $e->GetMessage(); } ?>
Kreker Проще иметь обёртку + как говорили выше - можно сделать дополнительный функционал. К примеру рекурсивный обход массивов. Я вот htmlspecialchars напрямую уже не юзаю - у меня есть htlmesc, которая рекурсивно это делает
пока есть вот такое: http://code.google.com/p/strclass/downloads/list Документацию пока не писал, так как ф-ции может будут меняться. Отписывайтесь, какой функционал добавить, что можно сделать лучше. http://strclass.googlecode.com/files/print-example.png - принтскрин того, что должен вывести example.php
http://code.google.com/p/strclass/source/browse/#hg/ Добавлена поддержка UTF-8 (папка юникод) Заюзал интерфейс, но пока не могу понять в чем профит. Какое преимущество этого интерфейса?
Потому, что в мануле должна быть одна строка: сделать удобным. Более ты ничего еще не хотел вроде. Так что как таковой проблемы нету для целого манула, на сколько я понимаю.
нужно писать так, что бы и другие могли понять мой мануал. + мне еще предстоит документировать API магазинных фич. Еще я думаю, что у меня много параметров в ф-циях. Это плохо? Тут как бы идет балансировка между кол-вом ф-ций и кол-вом аргументов.
Я бы еще провел опрос кому как удобней. И сделал бы средне статистически хотябы. А то этот мануал кроме тебя может и некому читать будет. (ps: я не в обиду ж, просто меня не сильно поперло)
Было бы очень круто, если бы ты сделал такое. Хотя я не совсем согласен с твоим подходом, но с удовольствием форкнул бы.
ну а на счет мана - ты ведь не для нубов пишешь. вполне будет достаточно обычного коммента перед методом, абы быстрее разрабатывал.