[#7968] array .{first, last, at} — Kazunori NISHI <kazunori@...>

西@九大です。

25 messages 1999/10/07
[#7969] Re: array .{first, last, at} — nobu.nakada@... 1999/10/07

なかだです。

[#7983] Re: array .{first, last, at} — Kazunori NISHI <kazunori@...> 1999/10/12

西@九大です。

[#7984] Re: array .{first, last, at} — matz@... (Yukihiro Matsumoto) 1999/10/12

まつもと ゆきひろです

[#7985] [patch] Array#delete_at w/ minus value — EGUCHI Osamu <eguchi@...> 1999/10/12

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

[ruby-dev:8111] Re: signal exception semantics

From: nobu.nakada@...
Date: 1999-10-23 22:58:22 UTC
List: ruby-dev #8111
なかだです。

At Sun, 24 Oct 1999 00:13:05 +0900,
matz@netlab.co.jp (Yukihiro Matsumoto) wrote:
> うーむ、lexicalなオブジェクトのライフスパンってのは大嫌いな
> んですが、それはそれとしても、Rubyの例外は一度rescueされても
> 再raiseされることもありますし、あんまり明示的な死刑宣告はそ
> ぐわないように感じます。

  ライフスパンでコントロールというのは C++ で例えた場合の話ですか
ら。要は rescue された時点で何かできるトリガーが欲しいかなという
ことです。で、再 raise については ruby_errinfo を見て一応考慮した
つもりなんですが。それよりも rb_rescue() を見落としてるという(^^;。

	*

> また、仮に死刑宣告の導入により「例外が生きている」期間を定義
> できるようになったとして、その「生きている」間だけsignalをブ
> ロックするという仕様がふさわしいかどうかも確証が持てません。
> 
> というのもUNIXシグナルと例外とではかなりモデルが違うので、ハ
> ンドラが無く仕方なく写像しちゃった場合にはすでにシグナルモデ
> ルとは違うものですから、むりにブロックするという元の挙動を保
> 存する必要もなさそうに思うからです。

  同一要因による例外が連続して発生するというのは、例外のモデルと
してはうまくないというか、扱いが面倒なのではないかと思うのですが。
そういう意味で写像の際に「シグナルは再入しない」という形をとって
もいいように思ったわけです。

	*

> |  ずっと腐り切ったソースばかり見てたんで、リハビリが必要なようで
> |す。はっきり言って全部捨てて(並列処理をサポートする言語で)書き直
> |したいところですが、Enterprise Edition の方のご予定は?(笑)
> 
> マジな話だと仮定すると、うちの会社に連絡くだされば、Rubyプロ
> グラムの商用サポートの見積りは出せると思いますです。

  私ゃいつだってマジですが(笑)。
  しかし、この話が通るにしてももうしばらく、半年とか一年とかは無
理でしょう。まだ現行システムを引き継いでる段階ですから。
  んで、こいつがメンテナンスなんて考えるだけ無駄、再設計したほう
がコスト的・性能的に数段有利だと納得させてから、次期バージョン用
にプッシュ、というシナリオですので。

# つーかもう、ちまちま書き換えてってどうこうできるようなレベルで
# はない。設計から実装、コーディング、名前の付け方からコメントの
# 入れ方、果てはソース管理まで隙なくヘボヘボ。ヘボとヘボを集めて
# もっとヘボにしましょ、って感じ。

  まぁ、うまく行ったら御慰みってとこでしょうか、まだ。

-- 
そうだ 強気に ちょっと インチキに☆彡
    中田 "Bugるくらいがちょうどいいかも;-)" 伸悦

In This Thread