なるせにっきスマートフォン用の表示で見るなるせにっきこの広告は、90日以上更新していないブログに表示しています。見えてしまっているので、そこらへんを考えないと穴がありそうだRubyは常にオブジェクトがあるのでboxingもなにもtaintが欲しいかじゃなくて、taintが保持されるべき状態になることがあるかと申しましょうかC#にも常にオブジェクトはある。boxingはいるんだっけか。1.0;ってやるとヒープに逃げるそれはオブジェクトモデルとは関係無さそうなどうかな。オブジェクトモデルそのものではないと思うが関係ないかというとそもそもboxing/unboxingとスタックに乗るか乗らないかは根が深い関係があると思われるので。unboxingがある時点で持てない気がするジャンプがあるのは認める。ありえないものねunboxしたいシーンもないし特異クラスと同じく、一回特異クラスになってしまったら、もう普通の世界にはもどれないというか、オブジェクトじゃないとRubyの世界に存在できないので、unboxできるはずがないそれはオブジェクトとは何かという根源的な問題に触れているように思うここでオブジェクトと値という対比がboxingだと立場になっているのでそういう反論が出てくるのだとおもう。c.fooむりじゃないかこりはやだやだできなきゃやだしかしどう考えても現実的じゃなかった。cにfooはできてはだめなんだよなつまり、この世には無数の1.0があるという宗派に改宗しないといけなくなる。したいよ?途中から見たのでよくわからんけど、即値オブジェクトが云々というより、不変オブジェクトが云々という観点で考えるべきなのではないか。その指摘は正しいような、実装と理念を混ぜてるようなrubyのオブジェクトモデルにimmutableって概念はあるのだろうかたまたまない。明には書かれてない気がするので、混同が生じているのではないだろうか。ない、ってあれだな、あるんだけど、影が薄い。flonum)とかRationalとかComplexとかはいまその混乱の狭間に置かれているという感がある。オブジェクト共有してるから即値としてつかえるよん的なクラスでないと議論がすれちがうな変更不能、と、不変、はちょっと違う。かなってほしいなってほしいかなあ。初めからあって永遠にあって決して変わらないという種類のオブジェクトがあるはずである。これをとりあえず不変オブジェクトと呼ぶ。それは不変じゃなくて普遍ではないかかもしれない。呼称は適当なのでとりあえず受け入れてくれ。なんかは間違いなくそれである。「数値」というのもそれに該当されるのではないか。1はどこにいっても1であり、どこに現れる1も全て同じオブジェクトのはずである、ということ。「不変オブジェクト」が特異メソッドなりtaintされたりしちゃいけないという道理はあるかもしれないしないかもしれない。どこかで1がtaintされうるとしたら、他の1も(同じオブジェクトなので)taintされることになることに留意。その立場だと特異メソッドもtaintも、そんなんあるはずないだろ。13.taint別にあって悪くはない。VALUE埋め込み以外で「不変オブジェクト」を実装するのは相当困難である。こんなあたりは前提として共有されたい。floatが普遍オブジェクトであるべきかってのには若干の議論の余地はある気はしないでもなかりけり6なんだけど不変なんだから別にふつうにオブジェクトつくってヒープにおいてもいいはずである。変更されそうな操作をことごとく蹴るという話に帰着するだけなのでうん。Bignumとか一通り禁止されているのだが、インスタンス変数が漏れてるというわけで、今はそういう方向なわけです。いうのはオラも十分理解できるんだけど、それはつまり「ある1」は値としての1ではなくて何か特別な意味・意図を付与された1なのであり、なのでそれはNumericの1ではなくて、1という値を持つ別のオブジェクトなんでないの、ゆえにラッピングして扱って、そのラッピングの方にtaintをつけるべきじゃないのと思うわけです。しろと思うんですが、それってつまりboxing/unboxingを自前でやれフハーハッハッハっていうことなのでなんだか悲しい気もする。特別なぼくだけの72を作りたいって話なんだから、自前でやるのは当たり前な気もするやー、ぼくは自前でやれに傾いてますよtaint必要な状況がほぼないんじゃね。いう意見に説得されたというわけで、理念は理念としておいといて、利便性という観点から適当に妥協するという考え方はなくもないかもしれにゃい。floatが目下の問題。FixnumとBignumは明らかにクラスが違うことが見た目でわかっちまうので、ちょっと挙動が違ってもしゃーないかもしれない。flonumはそうでないので、許しにくい。モヒカンに全部禁止していくと非互換になる。いうのが課題だとおもっていい?Integerに統合したい非互換になるのはどうでもよくて(マテどうでもいいのかどうあるべきかの方が問題まあ、できる/できないの観点から考えても、全部禁止に倒すしかなかろ、とは思う。他に選択肢ってあるのかな?その「全部」の洗い出しが十分じゃないかも、という感じはある。インスタンス変数が漏れてるとか、Rational/Complexあたりがどうなのかいまいちわからんとかいうのはそういうことかと。Rationalは特異メソッド禁止してたComplexもだなNumericで禁止されてるので、その子孫はみんな禁止されてると思う。「理念から言ってできるはずないのにそんなことしてたおめーが全部悪い」でいいんじゃないかと。破壊的にクラスが変わるってのはちょっと聞いたことがない禁止候補:特異メソッド、特異クラス、インスタンス変数、オブジェクトフラグ(taintなど)他なんかあったら、あるいは反論あったらどうぞ。obj.extendした時って、obj側は何も呼ばないのかNumeric#extend定義して禁止すればいいかてっとりばやいね。デザイナmatzの見解は聞きたいところではあるな。普遍オブジェクトのクラスとして登録、とかか。:RationalObjectSpaceのメソッドであろう。Classクラスのメソッドかもしれないが。ObjectSpaceかもuniversal_classはクラスがuniversalな気がしてしまうのでやや微妙Classに登録というよりは、世界に対しての登録なのでふむ、まあそうね。みたいに「俺がガンダムだ」的に叫ばせる感じ。叫んで登録されるような安っぽいメソッドではないのですまあ、ObjectSpaceでいいと思います。そもそも、declare_universalがあるクラスしか登録できないのはおかしい。2018-02-14はじめての投資SEGV探偵が往くはてなブログをはじめよう!nurseさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。