09/11/18 23:27:05 nmLyX5fb
>>75
strictで使える要素と属性、framesetで使える要素と属性・・・のように必要なものだけを取得するようなことをしてます
目的はdoctype別補完辞書作成の為なんです
IDEは全て試したわけではありませんがaptanaとDreamweaverを試した限りではあるdoctyleに対応しない属性が出てきますし足りない属性も出てきます
反応良かったらコード公開するつもりでした
質問は締め切りROMに戻ります
ますありがとうございました
84:nobodyさん
09/11/18 23:44:48
>$Lib_Kindが1だったらPEAR::DB、2だったらPEAR::MDB2使用
クラス使う意味が半分かそれ以上消えとるな。
85:nobodyさん
09/11/19 00:01:54
>>84
ｋｗｓｋ
86:nobodyさん
09/11/19 00:29:52
20年ほど前の、プログラミング言語C++でもしっかり明記されとるわな。
switch～caseは止めれって。(if～elseifの羅列も同じこと)
C++には相変わらずinterfaceは導入されて無い(よね?)けど、
それ以降出てきた言語たちにはinterfaceなんて有りがたいものが
あるんだから、よりその言葉に従うのが楽だわな。
87:nobodyさん
09/11/19 00:48:25
>>86
でも、それってPHP5だけを考慮に入れた場合は良いけど、PHP4まで考慮に入れたシステムの場合NGでは?
PHP4が、サポート終了ってなっているがPHP4系がいまだに使われているサーバなんて大量にまだあるからPHP4に対するプログラムの
サポートってなかなか切れないよ。
88:87
09/11/19 01:03:22
追加。
今回のようなマルチな環境に対応させるくらいのシステムなんだから古いシステムも考慮した上での作りだと思うよ。
そもそも、新しいのだけを考慮しているシステムならPHP4どころかPEAR::DBもシステムから外すべき物。
URLﾘﾝｸ(pear.php.net)
>This package has been superseded, but is still maintained for bugs and security fixes. Use MDB2 instead.
ぶっちゃけな訳しかたすると「バグとセキュリティーのためにサポートは続くがMDB2って言う後継出ているからそっち使えよ。」
PEARはPHPで書かれたライブラリだから必ずしもpearコマンドでインストール必要もなく
インストールされてないレンタルサーバでもアーカイブDLしてきてプログラムから呼び出すパスを、通せばいくらでも使える。
と言うわけで、プログラムの更新作業するのにDBは、「いらない子」。
MDB2とPDOをサポートするだけのプログラムにした方が良い。
PEAR::DB,PEAR::MDB2,PDOとサポートさせるプログラムを書いている奴が、PHP4のサポートをごっそりと打ち切ったプログラム書くのか?
89:87
09/11/19 01:27:04
>>87,>88書いて気になったけどここ見ている人たちってDB関連は、
・PEAR::DB
・PEAR::MDB2
・PDO
・そんなものラッパ使わない。各DB関数直接使う
どれが多い?
それと
・必須環境はPHP5以降。PHP4は切り捨てた。
・必須環境はPHP4以降。PHP4もサポートし続ける。
に関してもどうしている?
90:nobodyさん
09/11/19 01:39:54
・PHP5or4のみでサポートされている関数は使わない
・せっかく専用の関数が有るのだからそれらを纏めて抽象化
91:nobodyさん
09/11/19 01:57:50
>>89
IDと元質問のレス番号出しなさい。
92:nobodyさん
09/11/19 01:59:56
>>79
>別途取得する処理を書いておく必要がある
それがアホ設計だと言ってるんだがｗ
デザインパターンとか知らんのかね
93:nobodyさん
09/11/19 02:00:09 7S9/ReIJ
>>86
教科書通りのお手本を書く場合ならそれでいいけど、interfaceの実装はPHP5から。
さて私はPHP4の動作を対象外にしてまでinterfaceを使うべきですか?
PHP4を対象外にするならPHP5もPHP5.1から動作対象としてDBもPEAR::DBとPEAR::MDB2も切り捨ててより速度が出るPDOだけにしますよww
94:nobodyさん
09/11/19 02:03:51
そうしろよ
95:nobodyさん
09/11/19 02:32:52 7S9/ReIJ
>>92
デザインパターンの有効性って再利用時などに使いやすくなどだよね。
一時しのぎようのクラスにまでそのものが必要かどうかの天秤にかけると別にデザインパターンに
沿った作りにしないでもごり押しでソース書いておけばとりあえずはいいや。って結論になったアホな俺。
>>94
単純に切り捨てができれば苦労しない。
96:nobodyさん
09/11/19 03:12:12
再利用だのそんな問題ではなく
>>76を見て何とも思わないん？
まぁ書いた本人だから思わないんだろうけど、今後もプログラム書いていくなら
もうちょっとここの人達の意見にも耳を傾けてみたほうが幸せになれるんじゃないかなと思う次第
97:nobodyさん
09/11/19 03:41:33
>>76
継承を覚えろ。