- プログラミング雑談スレ♯+++
353 ：デフォルトの名無しさん[sage]：2014/10/07(火) 19:34:21.71 ID:7LrCT+Kb - >>350
おおむね正しいと思うよ
・プログラミングを独習するには10年かかる
http://www.yamdas.org/column/technique/21-daysj.html
|
- 【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ46【pl,rb,php,js】
606 ：デフォルトの名無しさん[sage]：2014/10/07(火) 23:28:12.66 ID:7LrCT+Kb - >>601
>ラッパー被せりゃいい話。
だから Kivy ではラッパーで包むブリッジコードをObj-Cでゴリゴリ手書きしなければならないって話だよ
Kivyドキュメントにはしっかり「(Pyobjusでは)ハンドラを実装できない(>>600)」と明記されているのに....
こちらは >>598 の要望に応えて >>600 で説明したのだから、今度はこちらが要望する：
いったい何故bridgeを全部Pythonだけで書けるなんて結論になったのか説明しろよ
>LLを組込むケースを考えてみればいい
>バインダ込みの言語もあればそうでないものもある
>その違いで優劣はないし瑣末な問題だよ
まずここで議論しているのは Kivy なのだから、一般的なLL組込みの想定は「話のすり替え」ではないのかな？
あえて言えば、Kivy の致命的欠陥はドキュメントにある「問題が起こるかもしれない(>>600)」の部分だ
つまり kivy 作者本人ですら Python でハンドラを書いた時に問題が起こる発生条件を定義して文書化できていない
結局、新規にあるフレームワーク対応に挑戦するたび、問題発生の有無を一つ一つ手探りで確認する必要がある
憶測になるが、Kivy作者が問題無しと判断できたのは単純なFoundationだけで、CoreMotionを含む複雑な
フレームワークでは問題の発生条件を把握できていないから、GitHub のサンプルコード群が空っぽなのだろね
RubyMotion ではそんな問題は起きないのに、それでも「その違いで優劣はないし瑣末な問題だよ」と言えるのだから、
Python プログラマとは本当によく調教された奴隷だと思う
>自由を与えられた奴隷の考えに通じるね。
ああ、この箇所については同意するよ
Python という奴隷の環境に慣れ過ぎると、驚いた事に自分の足を繋いでいる「手続き型」という鎖の自慢を始める
そして「手続き型」という鎖に繋がれていない自由な Ruby を嘲笑さえする
そして奴隷はどこまでも奴隷に過ぎない
|
- スレ立てるまでもない質問はここで 138匹目
804 ：デフォルトの名無しさん[sage]：2014/10/07(火) 23:46:19.24 ID:7LrCT+Kb - >>800
イベントの発生元を検証したいのなら、イベントのパラメタで
発生元オブジェクトを渡して、使用者がチェックすればいいのでは
たとえば OSX/iOS の Cocoa フレームワークではそのような API 設計になっているから、
必要であれば(テスト/デバッグの時だけ)検証するコードを書ける
もしも>>800 の使っているフレームワークがそのようなAPI設計になっていないなら、
リスナーを正しく設定して後は天に祈るしかないだろね
|