クラスの実装をどうするかは、ここでは問題ではない。文字列をオブジェクト型にする事にどういう意味があるか？が問題。

>>900
>いずれにせよエスケープ状態を表すフラグを持たせた方が良い。

は解るが、isEscapedの判定をescapeメソッド内で行うべきでは無いかな、

if (!$string->isEscaped) $string->escape();

と明示的にエスケープする方が美しい。

２重エスケープはほんの一例だよ。
lengthとかmatchとかconvertEncodingとか、文字列をオブジェクト的に扱うメソッドを実装する時に、
エスケープされてるか否かでメソッドの挙動が変わるのはデメリットの方が多い気がするな

>>901
●メリット
・流れるようなインターフェースが実装出来る
・PDT等のコード補完と相性が良い
・引数タイプヒンティングが行える

●デメリット
・文字列を引数とする標準関数との親和性が下がる
・実装＆実行コストの増加

ってところかね

透過的にするならこんな感じかな。うーんクセ強いな
class HtmlString {
　public $org = "";
　public function __construct($str) { $this->org = ($str instanceof HtmlString) ? $str->org : $str; }
　public function __toString() { return htmlspecialchars($this->org); }
}
function h($str) {
　return new HtmlString($str);
}

$str1 = h("<a>");
$str2 = h($str1);
echo $str1, $str2;

>>904
クラス名が紛らわしいな･･･文字列操作で無く、エスケープを主体にしたクラスだよね。
HtmlStringじゃなくてEscapedHtmlという感じの方がしっくりくるな。

てか大抵のシステムではエスケープはビューの出力時に一度行えば良いはずなので、
わざわざ文字列をクラス化するメリットは薄い気がするわ。

まあ、実装はケースバイケースで適切にすればいいんだ。拡張性を考えるなら、処理を別メソッドに分割した方が良いし、速度を考えるなら、出来るだけメソッド呼出しは減らした方が良い。

こういう流れ好きだわｗ

->
こんなのわけわかんないんだよね・３・
難しいよ・３・　ちね

うるせえ！だまってやれ

一概に言っても

・基底フレームワーク
・アプリケーションフレームワーク

とあるからなぁ、一般的にはオープンソースのフレームワークを基底に、独自のフレームワーク（っぽい実装）を作るよね？
その独自部分のノウハウとかテクニックを聞きたいです先輩！

Cakeみたいなフルスタックをベースにすると、ビジネスロジック以外の独自な実装をする余地がほぼ無いです。
むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。

ただし、これは多分、SymfonyやCIも同様。 (・∀・)ｲｲ!!　は知らん。

ちいたんとかは、よく知らんが基本設計がよければ俺色に染め甲斐がありそうだ。

Zend FWに関しては、みんなどんな風に使ってるのかよくわからん。
Zend_ToolをベースにしてオレオレFWを作ってるのか、
オレオレFW用ライブラリ集として活用してるのか、
Zend_Toolをベースに完全にZend謹製のものをつかってZend準拠なやりかたでZend Wayしてるのか。

>>914
独自色というか、FWの仕様と微妙に合わない実装を強いられた時に、
独自クラスでラップする事はよくあると思うんよ。

すると
＞むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。
となるわけで･･･ここらへんのうまい落としどころとかテクニックが合ったらいいなぁと思ったのさ。

View周り以外で、既存のものとすりあわないものっていうと、どういうのがあるだろう

CakePHPの可読性の悪さにビックリしたよ。

PEARやZend Frameworkのコードに慣れているからかもしれないが、
CakePHPを使って、まともなコードのWebアプリは作れない。

よくあんなのが人気あるのか不思議だ。
CakePHPには、ソースコードの良し悪しが分からないド素人しか食いつかないんじゃないかなぁ。

てわけで、俺はZFに一票。

>>917
俺はCake厨のド素人なんですが、
ソースが醜い＆設計も微妙な部分があるというのには同意で、
でもZend Frameworkをどんな風に使ってるのか（使う事が推奨されてるのか）
>>914でも書いたように全然分からんのです。
ActiveRecordあるんかなとか、そういうのも含めて・・・
まあググればいいんでしょうけど、Zend Frameworkをスゲエ便利に使ってますって感じの
記事を読んだ事が無い・・・。

最初は命名ルールの縛りから逆にチーム開発には有用だしと半分我慢しつつ使ってきたけど
array地獄でIDEの補助も受けられないし、人間の負担が変に大きすぎる。

素人なんだけど、arrayはミスがあっても気づかなくてすごく時間を無駄にする。
けど、一気に設定を流し込む場合にこれ以外の良い方法はあるの？

>>920
クラスにするとか。

別形式で書いて機械的に変換掛ける
俺俺バリデーターを作って実装前にチェック掛ける
PHPをやめる

ZFは自分好みに拡張してなんぼじゃないかな。
取捨選択しやすくて拡張の土台として都合がいい。
その分、素体のまま開発始めようとした場合のご利益は少ないと思う。

あとはソース見てクラス設計の参考に使うのも結構いいかも

基底クラス郡

>>917
可読性が悪い理由は簡単で
互換性を重視しているからだよ。

PHP4に対応するために、あえてPHP5の機能を
使わないで作られている。

いまどきPHP4なんてと思うかもしれないが、
CakePHPが人気が出たときはPHP4のサポートは終了しておらず、
PHP5への移行期だったから人気が出た。
いまだに古いRHELとかPHP4を搭載したディストリが
サポート期間中だったりする。

PHP5の機能を使わなくたって、可読性の良い
コードは書けると思う。

フレームワークの良し悪しは好みかもしれんが、
ZendFrameworkの明確なコード規約は素晴らしいと思う。

冗長と感じるかもしれないが、IDEとの親和性が抜群に良いのでチーム開発する上では必須。

>>927
同意です。

ところで、
>> IDEとの親和性が抜群に良い
とのことですが、何をお使いですか？
NetBeans? PDT？

参考までに教えてください。

改行とかの規約はPEARにも明記されてるし、
べつにCakeにないからどうという話じゃないと思う
レイヤーが違うというか

>>931
誰もCakeを否定していないし、何故PEARが出てくる。

>>930 >>933
＞phpDocの書き方を含めて、各種命名規約、インデント改行規約、PHP閉じタグ無し等が名言
コーディング規約って言ったら普通こういうのを定義したものを指すんだから
ZF云々じゃなくてコーディング規約云々の話だね。

http://pear.php.net/manual/ja/standards.php
http://trac.cakephp.org/wiki/Developement/CodingStandards
http://trac.symfony-project.org/wiki/HowToContributeToSymfony#CodingStandards
http://framework.zend.com/manual/ja/coding-standard.html

>>934
その4つの規約にも、それぞれメリットデメリットがあるし、規約も含めてのフレームワークだと思うよ。

個人的には最も枯れているPEAR記法をベースにしたZend規約がベターで、
PDT(ZendStudio)との親和性も高いと感じたのさ。

相性の悪い規約とIDEってあるの？
規約やIDEの評価基準に使いたいから、純粋に知りたい

実行時に動的にバインドする系のはヒントが出ないよね

しいて言えばPEAR＆Zend形式はアンダースコア区切りの疑似ネームスペースを採用しているので、
パッケージ名が被る心配はほぼ無いってのが強み。

cakeはPHP4コード＆マジックメソッド実装が多めで補完が弱い。
Symfonyは2.0でZend風の命名規約に移行するし、
Twig等の周辺ライブラリは既にZend形式になっている。

>>970
5.2を完全に切り捨てるのはまだ早いからかと。

あと、PHPのnamespaceはお世辞にも使いやすいとは言えない。
(PEAR＆Zend形式から乗り換えるメリットがほっとんど無い)

まず、

・クラスの完全修飾にバックスラッシュが入る
　→ 文字列にクラス名入れる時に面倒がおこる

・名前解決が無駄に複雑
　→ 同ネームスペース内であれば、記述が楽になるかもしれんが、
　　 大抵の場合は \ で始まる絶対パスで記述する事になる。


5.3の他の機能は素晴らしいと思うが、
Zend形式でなく、namespaceを使う明確なメリットを教えて欲しい。

バックスラッシュはエスケープにも使うからなぁ

やっぱり型あり言語がいいよ

普通って何？
ていうか普通は省略しない。

>>945-946
むしろおまいらの普通はJava基準

>>945
PHP4との互換性のためだから仕方ない

まだPHP4対応で書かなきゃいけない可哀想な人なんだ察しろよ

>>947
Javaは省略したらprivateにはならないよ。