機能要望 > その他 > Yellow book for EC-CUBE |
その他
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
ゲスト |
投稿日時: 2013/6/16 16:46
対応状況: −−−
|
Yellow book for EC-CUBE EC-CUBEも、2.12となり、OSSとしての間口も広がり、
EC-CUBE-3(?)に向けて、そろそろ 「Yellow Book for EC-CUBE」 が必要な時点になって来ているのではないでしょうか? |
|
ゲスト |
投稿日時: 2013/6/16 17:27
対応状況: −−−
|
Re: Yellow book for EC-CUBE 先の
引用: 【追記】 これはどの辺が『勘弁』なんでしょうか? 小生の場合は、JavaのSWTで「setter getter」は馴染めず、staticで回避しました。 |
|
seasoft |
投稿日時: 2013/6/16 18:26
対応状況: −−−
|
神 ![]() ![]() 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: Yellow book for EC-CUBE 私は、対応する多くの変数に対して、いちいち冗長に記述しなきゃいけないだけでも嫌です。それで、サンプルコードの様な、(PHP ではコンパイルが通る) 気づきにくいエラーを招く二重苦では、メリットも相殺されるかなと。
そもそも、Java の世界でも、画一的な setter getter は議論の対象ですからね。PHP で真似事してもね・・・ 無論、適所適所で他言語のパターンを参考にするレベルは良いと思うんですよ。
|
ゲスト |
投稿日時: 2013/6/16 20:07
対応状況: −−−
|
Re: Yellow book for EC-CUBE 小生も、多分、
引用: 画一的な setter getter を、直感的に嫌ったのでしょう、、、 SWTでの setter getter は、今だに理解できないです。 db fieldに対する コンストラクタ(これも setter getter なのか?は、小生の中では疑問ですが)は、 db アクセスでのエンバグを回避出来ています。 そうした意味で エンティティ setter getter コンストラクタ の意味をEC-CUBE内での定義としておかないと 無用なフレーミングを招くだけです。 引用: 無論、適所適所で他言語のパターンを参考にするレベルは良いと思うんですよ。 そうした、広義の意味で、 ・EC-CUBEがあらぬ方向へ向かってしまった時の修正。 ・『(本人も)意図しない「未規定コード」』の後始末。 に、貴重なリソースが消費されない様にするため。。。 が、本スレッドの意図です。 |
|
nanasess |
投稿日時: 2013/6/16 21:55
対応状況: −−−
|
神 ![]() ![]() 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: Yellow book for EC-CUBE 引用:
サンプルコードのやつは typo です. スミマセン. 僕もできたら, getter/setter は作りたくないのですが, メンバ変数を private にしたかった(むやみやたらに他クラスからメンバ変数にアクセスしてほしくない)ため, やむおえず getter/setter を作りました. 引用:
こちらに関しては賛成です. 安全で, 生産性の高いコーディングスタイルがあれば, ご教授いただきたいです. |
seasoft |
投稿日時: 2013/6/16 23:18
対応状況: −−−
|
神 ![]() ![]() 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: Yellow book for EC-CUBE 他言語のスタイルを真似事をするときには、PHP がスクリプト言語である事なども念頭に、適否の判断や実装の見直しをする必要があろうかと思います。
とりあえず、やたら private なのは、カスタマイズの足かせにもなるので嫌いです。 (EC-CUBE 本体のコミッターの立場では、実装時に private にしたい事は多々ありますが) そして、カスタマイズも考慮して本体のアクセス権を設計するのは、自分には荷が重いかも・・・ 多分、そういう人が PHP の開発者には多いので、「var」がレギュラー復帰する 単純に Java っぽい事をするのは、EC-CUBE を Java に移植してからが良いかなと思います。
|
nanasess |
投稿日時: 2013/6/17 10:11
対応状況: −−−
|
神 ![]() ![]() 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: Yellow book for EC-CUBE 引用:
もちろん、ライトなコーディングが可能なスクリプト言語の良さもありますし、好みもありますので、このスタイルをEC-CUBE本体に取り入れる予定は、今のところありません。 private にしてしまうと、ある程度のルールが生まれる(きちんと継承して拡張する等のルールを強制する)ので、カスタマイズの足かせになるというのも同意です。 EC-CUBE の原型を留めなくなるような大規模なカスタマイズになると、ある程度のルールの強制無くては、保守しづらくなるため、結果的に Java に近い構文になりました。 しかし、PHP の仕様上、かなり無理をしている箇所もあり、無理しすぎると効率も落ちるため、適材適所で適用したら良いと思います。 |
red |
投稿日時: 2013/6/17 20:59
対応状況: −−−
|
神 ![]() ![]() 登録日: 2010/2/15 居住地: 東京都 投稿: 1571 |
Re: Yellow book for EC-CUBE メンバー変数をprivateはselfを使うことで出来ないでしょうか
まぁExを使う以上継承できるようにしておかないとダメだと思いますが・・ もしEC-CUBE3が作られるなら、自動アップデートや、バージョンアップで大きくしようが変わるなどがなくなるといいですけどねぇ
|
seasoft |
投稿日時: 2013/6/17 23:29
対応状況: −−−
|
神 ![]() ![]() 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: Yellow book for EC-CUBE アクセス権限やその周辺での気になる点はあるにしても、エンティティクラスの概念は有用かもと思っています。
フロント機能・管理機能間で、もう少し共有できるデータ構造や付随する処理構造があると良いなぁとは日々感じています。 一方で、元スレで上がったような、(税処理はともかく) DB に色々とヤラせるスタイルも嫌いではないし、、、 絵に描いた餅かもしれないけど悩みます。描かないと始まらないし。
|
seasoft |
投稿日時: 2013/6/18 0:22
対応状況: −−−
|
神 ![]() ![]() 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: Yellow book for EC-CUBE バージョンアップ版に対抗して、(オフィシャルでもフォークでも)安定保守版が生まれるくらいに洗練したものになったら良いですけどね・・・
今のところ、壊さないと直せない部分も山積しているし、広がり過ぎて壊しようもない部分もあるし・・・ 安定保守ラインには程遠いポジション・・・ ホントこの5年間、真の暇を体感できてません。 この調子だと、あと20年間くらいは・・・ もはや、ポスト EC-CUBE に期待するくらいしか、楽できる道を思いつけません(笑) そのためには、きっと (PHP6 ではない) ポスト PHP5 が必要な訳で・・・
|
(1) 2 » |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |