#author("2018-06-12T23:26:51+09:00;2016-11-10T01:28:10+09:00","","")
* [PHP7] 2種類のコンストラクタ（ __construct(), CLASSNAME() ）を混在させる[#neb4170a]
#author("2018-06-12T23:28:12+09:00;2016-11-10T01:28:10+09:00","","")
* [PHP7][PHP4] 2種類のコンストラクタ（ __construct(), CLASSNAME() ）を混在させる[#neb4170a]
- 元のタイトル: PHP 4 互換のコンストラクタを __construct() メソッドに置き換える
- ページ: [[BugTrack2]]
- 投稿者: [[bee]]
- 優先順位: 普通
- 状態: 完了
- カテゴリー: 本体バグ
- 投稿日: 2016-10-30 (日) 12:37:29
- バージョン: 1.5.1
- リリース予定バージョン: 1.5.2
** メッセージ [#nea1352a]
PHP 7.0 から古い形式のコンストラクタは非推奨となり、E_DEPRECATED が発生するようになりました。~
将来のバージョンアップにおいて障害となる可能性があるため、可能なうちに置き換えておくべきだと思います。
*** 公式ドキュメントより [#h15d634b]
警告
古い形式のコンストラクタは PHP 7.0 で 非推奨 となりました。
将来のバージョンで削除されるでしょう。新しいコードでは常に __construct() を使うべきです。
[[php.net:manual/ja/language.oop5.decon.php]]
*** patch [#l9516f88]
[[ja.osdn.net:users/beec1e/pastebin/4311]]
ただし、PHP 4.x では動作しなくなります。
--------
- バグを立ててから気付いたのですが、A->__construct() と A->A() の2つを作り、A->A() が A->__construct() を呼ぶ（もしくは逆の）形にすれば PHP 4/5/7 で互換が取れるようになる？ -- [[bee]] &new{2016-10-30 (日) 12:45:55};
- 将来的な関連という事で。[[BugTrack2/388]] 最低動作環境を PHP 4.1.2 から PHP 5.x にする -- &new{2016-11-01 (火) 20:54:04};
- エイリアスあるいは（再）初期化の本体部分となる関数に対して不適切な呼び出しが行われないよう注意書きコメントが必要かもしれませんが、クラス名メソッドから__construct() を呼び出すといった使い方はいちおう可能ですよ。警告が出る条件（両方存在しているときは別のが出るとか）によっては、エラー数が減らないかもしれませんけど。 -- &new{2016-11-01 (火) 21:26:15};
- ふと思ったのですが、提案部分で示されているドキュメント文章よりも少し後ろにある
PHP 5.3.3 以降、名前空間つきのクラス名の最後の部分と同じ名前のメソッドは
コンストラクタとみなされなくなりました。 名前空間を使っていないクラスは今までと変わりません。
という記載内容の方が、PukiWikiを名前空間の中で使おうとする際の問題となってるような気も -- &new{2016-11-01 (火) 21:29:53};
- 勉強になります。とはいえ、PHP 4 互換コードを書くためのコーディング規約を作って徹底しなきゃいけないかも…と考えるとあまり…（誰も新規コードを書かないし開発しないならこの件だけで済ませていいんですけどね） -- [[bee]] &new{2016-11-02 (水) 14:40:21};
- うっ。EUC-JP 版と UTF-8 版が併存してるので正規表現も何かしら規約が必要（preg* だと文字化けするかも / mb_ereg* 使ったほうがいいかも）ですよね、って書こうとしたら mbstring は PHP 4.2.0 以降のみ、使わないでって話を見つけてしまった…。 [[BugTrack/436]] -- [[bee]] &new{2016-11-02 (水) 15:33:35};
-- ちなみに preg* が Unicode サポートしない可能性がある（PCRE のコンパイルオプションに依存する）ので UTF-8 であっても mb_ereg* を使ったほうがいいという話もありますね…。d.hatena.ne.jp/hnw/20090628 -- [[bee]] &new{2016-11-02 (水) 15:58:47};
-- まあ、そもそも u 修飾子を使ってる箇所がなさそうですけど。 -- [[bee]] &new{2016-11-02 (水) 16:04:18};
- できれば積極的にPHP4で動かなくなる変更は入れたくないのですけど、E_DEPRECATEDは放っておくと次のバージョンで動かなくなりますからね… -- [[umorigu]] &new{2016-11-04 (金) 08:56:48};
- PHP7 で __construct() と A() の両方があると、E_DEPRECATEDにもならずA()の方は単純に無視されますね。とりあえずこれします -- [[umorigu]] &new{2016-11-04 (金) 20:59:26};
- 対応しました。まだPHP4で動きます。
[[1>osdn.net:projects/pukiwiki/scm/git/pukiwiki/commits/6373f6775c5f768e25580eb64ac6d8d533b450c0]] [[2>osdn.net:projects/pukiwiki/scm/git/pukiwiki/commits/74335459853fd76cdbc9a765e8c8ee93f5cc3c78]] [[Merge>osdn.net:projects/pukiwiki/scm/git/pukiwiki/commits/f1693f0c39423bce471083e9a981372d1a45ebbd]] -- [[umorigu]] &new{2016-11-06 (日) 18:08:02};
- 対応ありがとうございます && お疲れさまでした。 -- [[bee]] &new{2016-11-09 (水) 01:15:59};
- あれからいろいろ考え直してみたのですが、PHP 4 対応を単純にやめようという話ではなく 1.6/2.0 を見据えたロードマップの話をした上でそういう話をするべきだった（次期リリースが 1.5.x なら動作環境は変えられない）なと。 -- [[bee]] &new{2016-11-09 (水) 01:24:49};
-- といっても新参の私が「2.0はこうあるべきだ」なんて主張するのはアレなのですが…。 -- [[bee]] &new{2016-11-09 (水) 01:25:48};
-- 1.4.8 相当のパッチが branch_r1_6 に置かれていることすら知らなかったので、ちょっと半年ROMって来ます。 -- [[bee]] &new{2016-11-09 (水) 01:30:03};
-- 「いずれ動作環境を PHP x.y.z or later に変えるときのためのブランチを作ろう」って提案して、そっちにパッチを溜めておく（PHP 7.x で動かなくなったら適宜 cherry-pick する）感じの運用のほうが絶対楽ですよね…すみませんそこまで頭が回らなかった…。 -- [[bee]] &new{2016-11-09 (水) 01:36:52};
-- 私も新参ですし、またそれで判断が変わることはないので提案は大歓迎です。「できるだけ多くの環境で動作させる」という方針を個人的に気に入っているのと、PukiWikiはPHP部分をカスタマイズして使われていることが多い（と推測される）ため、ドラスティックな変更はできるだけ入れたくないのが正直なところです。既設サイトのバージョンアップが難しくなると「PukiWikiはもう止めよう」ということにもなりかねなく、互換性はこのProductにとって生命線なのです -- [[umorigu]] &new{2016-11-10 (木) 01:14:50};
-- branch_r1_6 は1.4.8になるはずだった実装ですが、バグ修正については取り込み済みで、今ではほぼ「スパム対策機能」のブランチになっています。ただ、1.5でこれを取り込む目途は立っていません -- [[umorigu]] &new{2016-11-10 (木) 01:27:04};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
