[#29374] nil.to_s — Shugo Maeda <shugo@...>

前田です。

59 messages 2006/09/01
[#29375] Re: nil.to_s — "U.Nakamura" <usa@...> 2006/09/01

こんにちは、なかむら(う)です。

[#29380] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29387] Re: nil.to_s — Shugo Maeda <shugo@...> 2006/09/01

前田です。

[#29390] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29398] Re: nil.to_s — "NARUSE, Yui" <naruse@...> 2006/09/01

成瀬です。

[#29400] Re: nil.to_s — Yukihiro Matsumoto <matz@...> 2006/09/01

まつもと ゆきひろです

[#29491] symbol and string — Tanaka Akira <akr@...>

open-uri で :proxy=>nil という指定を行うと、以下のようにエラーになります。

33 messages 2006/09/05
[#29499] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/05

まつもと ゆきひろです

[#29500] Re: symbol and string — Tanaka Akira <akr@...> 2006/09/05

In article <1157470154.047826.13379.nullmailer@x31.priv.netlab.jp>,

[#29503] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/06

まつもと ゆきひろです

[#29504] Re: symbol and string — Tanaka Akira <akr@...> 2006/09/06

In article <1157505538.340126.8472.nullmailer@x31.priv.netlab.jp>,

[#29507] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/06

まつもと ゆきひろです

[#29512] Re: symbol and string — keiju@... (石塚圭樹) 2006/09/06

けいじゅ@いしつかです.

[#29529] Re: symbol and string — SASADA Koichi <ko1@...> 2006/09/08

 ささだです。

[#29530] Re: symbol and string — Yukihiro Matsumoto <matz@...> 2006/09/08

まつもと ゆきひろです

[ruby-dev:29544] Re: symbol and string

From: SASADA Koichi <ko1@...>
Date: 2006-09-08 17:45:18 UTC
List: ruby-dev #29544
 ささだです.

 ちょっといろいろ混じってしまってわかりづらくなってしまっているんです
が,私が一番問題にしたかったのは「Symbol と String の各オブジェクトが,
to_s した結果が同じであったとき,Hash のキーとして同じものとして扱われる
こと」です.Symbol が文字列のメソッドを持つのは,結構賛成です.

Yukihiro Matsumoto wrote:
> | とりあえず感覚的に「ありえねー」と思うので,それじゃ理由になんないです
> |よねぇ.
> 
> そうですねえ。とりあえずSmalltalkではこうなってますしね。

 Smalltalk の Hash は Dictionary でしたっけ.それが,シンボルと文字列を
同じキーとして扱う,ということでしょうか.


> | Lisp なんかでは,この辺ってどうなんでしょう.eq*? な関数でシンボルが同
> |じ値を返すことはあるんでしょうか.
> 
> ComminLispはstring-*な関数は文字列もシンボルも受け付けますね。

 CommonLisp で Hash のような存在は何になるんでしょう.

 数少ない,私の知っているLispだとGaucheがあるんですが,Gauche だとこの
ようなものは無いようです.


-----
 ここでまた話が変わります.

> | 実は,Symbol に統一するのがいいんじゃないかと思っておりました.このコ
> |ンテキストでは Symbol が返ってくる事をなんとなく期待しませんか? String
> |系のメソッドは,:sym.to_s.foo の短縮形と覚えるべきでしょうか.でも,foo
> |が String 系のメソッドだったっけ,と覚えるのが大変そうです.
> |
> | もし,これらの理由が「Symbol は GC しないから」ということなら,Symbol
> |を GC するように検討してみるのはどうでしょうか(薮蛇かも).
> 
> SymbolをGCですか。できるのかな。

 まず,まつもとさん的には,Symbol#succ などで文字列が返るのは,問題な
い,そうあるべき,とお考えなんでしょうか.それとも,実装の都合でしょうが
なく,なんでしょうか.


-----
 ここでまた話が変わります.

> | 今回の変更で,SPECIAL_CONST_P(sym) == 0 になったので,なんとななるん
> |じゃないのかなー,と,なんとなく思っているんですが,甘いでしょうか.mark
> |するところがちょっと増えるだけかな,とか思ってるんですが.うーん,Symbol
> |にしないで ID だけ使っているものもあるので,やっぱり難しいか? 
> 
> IDを取り出す時点でSymbolは作ってますから、「Symbol にしない
> で ID だけ使っている」ものはないんですが、IDしか保持していな
> いケースは結構あります。IDとSymbolのunifyを実現しないとGCは
> 実装できないような気がします。
> 
> そうすると、
> 
>   rb_funcall(obj, '+', obj2)
> 
> のようなのを全部
> 
>   rb_funcall(obj, rb_intern("+"), obj2)
> 
> に置き換えないといけませんねえ。

 その例がそうなる理由はよくわかんないんですが,ID と Symbol オブジェク
トは別に考えられないでしょうか.

symbol_table:
 ID (C 文字列) => Symbol オブジェクト

・rb_intern() が作るものは「消しちゃいけない」Symbolオブジェクト
・Symbol#succ などが作るものは「GC可能な」Symbolオブジェクト(GC時に
symbol_table からその値を消す)

ことで実現できるんではないかと(GCのために,消しちゃいけないSymbolTable
を別途持ってもいいかも)

などと考えました.

 消しちゃいけないのは ID として利用されるものなんですから.

 ただ,

  id1 = :Sym.succ.object_id
  GC.start
  id2 = :Sym.succ.object_id

で id1 == id2 であることは保証されませんが....これで困ることはあるんだ
ろうか.

-- 
// SASADA Koichi at atdot dot net

In This Thread