[#8168] {literal}#[]= — EGUCHI Osamu <eguchi@...>

えぐち@エスアンドイーです。

16 messages 1999/11/01
[#8172] Re: {literal}#[]= — matz@... (Yukihiro Matsumoto) 1999/11/01

まつもと ゆきひろです

[#8176] Multiple self assignment — Kazuhiro Yoshida <moriq.kazuhiro@...>

もりきゅうです。

35 messages 1999/11/01
[#8178] Re: Multiple self assignment — matz@... (Yukihiro Matsumoto) 1999/11/01

まつもと ゆきひろです

[#8212] Re: Multiple self assignment — Kazuhiro Yoshida <moriq.kazuhiro@...> 1999/11/02

もりきゅうです。

[#8213] Re: Multiple self assignment — matz@... (Yukihiro Matsumoto) 1999/11/03

まつもと ゆきひろです

[#8232] 例外を処理する 2 項演算子 — Kazunori NISHI <kazunori@...> 1999/11/05

西@九大です。

[#8233] Re: 例外を処理する 2 項演算子 — matz@... (Yukihiro Matsumoto) 1999/11/05

まつもと ゆきひろです

[#8236] Re: 例外を処理する 2 項演算子 — Kazuhiro Yoshida <moriq.kazuhiro@...> 1999/11/05

もりきゅうです。

[#8266] Re: 例外を処理する 2 項演算子 — EGUCHI Osamu <eguchi@...> 1999/11/07

えぐち@エスアンドイー です。

[#8269] Re: 例外を処理する 2 項演算子 — gotoken@... (GOTO Kentaro) 1999/11/07

In message "[ruby-dev:8266] Re: 例外を処理する 2 項演算子"

[#8271] Re: 例外を処理する 2 項演算子 — matz@... (Yukihiro Matsumoto) 1999/11/08

まつもと ゆきひろです

[#8274] Re: 例外を処理する 2 項演算子 — keiju@... (石塚圭樹) 1999/11/08

けいじゅ@日本ラショナルソフトウェアです.

[#8204] Re: [ruby-list:18281] Re: アクセス制御について — Shugo Maeda <shugo@...>

前田です。

12 messages 1999/11/02
[#8205] Re: [ruby-list:18281] Re: アクセス制御について — Shin-ichiro Hara <sinara@...> 1999/11/02

原です。

[#8315] Re: [ruby-list:18601] Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{} — Kazunori NISHI <kazunori@...>

西@九大です。

37 messages 1999/11/15
[#8316] Re: [ruby-list:18601] Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{} — matz@... (Yukihiro Matsumoto) 1999/11/15

まつもと ゆきひろです

[#8369] Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{} — Koji Arai <JCA02266@...> 1999/11/18

新井です。

[#8374] Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{} — matz@... (Yukihiro Matsumoto) 1999/11/18

まつもと ゆきひろです

[#8384] Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{} — Koji Arai <JCA02266@...> 1999/11/19

新井です。

[#8405] 1.4.3 (Re: Re: [REQ] [].grep(pat){} ==> [].grep(pat).collect{}) — matz@... (Yukihiro Matsumoto) 1999/11/24

[#8319] Re: Exception handling — Jun Adachi <adachi@...>

安達@沖データと申します。

21 messages 1999/11/16
[#8350] Re: Exception handling — Kazunori NISHI <kazunori@...> 1999/11/17

西@九大です。

[#8446] [REQ] {enumerable, integer, range}.rand — Kazunori NISHI <kazunori@...>

西@九大です。

37 messages 1999/11/29
[#8449] Re: [REQ] {enumerable, integer, range}.rand — matz@... (Yukihiro Matsumoto) 1999/11/30

まつもと ゆきひろです

[#8463] Re: [REQ] {enumerable, integer, range}.rand — Kazunori NISHI <kazunori@...> 1999/11/30

西@九大です。

[#8474] Re: [REQ] {enumerable, integer, range}.rand — matz@... (Yukihiro Matsumoto) 1999/12/01

まつもと ゆきひろです

[#8476] Re: [REQ] {enumerable, integer, range}.rand — Kazunori NISHI <kazunori@...> 1999/12/01

西@九大です。

[#8487] Re: [REQ] {enumerable, integer, range}.rand — matz@... (Yukihiro Matsumoto) 1999/12/02

まつもと ゆきひろです

[#8494] Re: [REQ] {enumerable, integer, range}.rand — Kazunori NISHI <kazunori@...> 1999/12/02

西@九大です。

[#8451] new Hash (Re: [ruby-list:19043]) — Wakou Aoyama <wakou@...>

青山です。

18 messages 1999/11/30

[ruby-dev:8439] Re: constant?

From: matz@... (Yukihiro Matsumoto)
Date: 1999-11-28 16:07:20 UTC
List: ruby-dev #8439
まつもと ゆきひろです

In message "[ruby-dev:8435] Re: constant?"
    on 99/11/27, GOTO Kentaro <gotoken@math.sci.hokudai.ac.jp> writes:

|ぼくもあまり深く考えていなかったので改めて考察してみたところ、
|どうやら定数は安全性を提供するが汚染モデルとは異なる機能を提
|供するモノのようです。

まったくその通りです。っていうか、セキュリティレベルと絡めて
考えるという発想そのものがありませんでした。確かにレベル4で
定数の変更を禁止していますが、あれはグローバルな状態の変更禁
止の一環ですから、この件とは分離して考えた方が良いでしょう。

|さて、再代入できない定数というのはインタプリタがある種の安全
|性を保証してくれる名前のことではないでしょうか。この安全性を
|上の(i),(ii)に対応させてみます。
|
|  (1) 名前なのでその有効性はインタプリタが検査する
|  (2) その名前空間が存在する限り値の一意性が保証される

(1)については異論はないのではないでしょうか。現在の定数相当
のスコープと未初期化の場合にエラーとなるスロットの存在は妥当
であるとほとんどの人が同意してくださると思います。

(2)については考えるべき点がいろいろあると思います。

  (a) 定数の再定義を一切禁止する(昔の仕様)

      結果として値の一意性は保証されるが、たとえばJed/Rubyで
      プログラムを修正の上、再実行などが行えないという不自由
      さがあります。

  (b) トップレベルでの再定義を許す(1.4の仕様)

      プログラムのロードレベルでは再定義を許すので、厳密には
      定数ではないのですが、メソッド内では値が変更できないの
      で(抜け道を使わない限り)、実行中に値が移り変わることは
      ありません。普通の変数よりはマシですが、これは「定数」
      じゃないという指摘はもっともです(私は妥協できると思っ
      てるけど)。

  (c) 初期化されたものはメソッド内でも代入可能(1.5.0の仕様)

      試験的に1.5.0で採用している仕様です。これは実行時にも
      値が移り変わりますから、完全に定数ではありません。いま
      まで奇妙な方法で実現していたクラス変数(相当)が実現でき
      るのは嬉しいことですが、かつての仕様でまがりなりに存在
      していた値の定数性は完全に失われています。「定数」じゃ
      ない別の名前を考える必要があるというのが最大の問題のよ
      うに思いますが、「値の一意性」が失われるのもそれはそれ
      で大きなデメリットかもしれません。

  (d) 代入可能だが指定されたものだけは定数

      ごとけん案と言っても良いのかな? 「値の一意性」を外側
      から指定する性質として用意しようという考えだと思います。
      実行のことは置いて考えるとして、気になるのは

        * 全体としては「定数」でないので別の名前を考える必要
          がある(しかも、その名前は「変数」という単語を含ま
          ない方が良い)

        * 「再定義の不自由」の問題をどう回避するか。

        * スコープが同じだとは言え、定数(的性質を持つもの)と
          変数を同じものとして考えて良いのか。単なる性質の違
          いを越えているのではないか。

      などです。

そして、既に触れていますが名前の問題です。名前がすんなり決ま
らないってことは議論(考察)が不足していると考えることができる
かもです。
                                まつもと ゆきひろ /:|)

In This Thread

Prev Next