From: Brian Mitchell Date: 2004-11-01T16:48:20+09:00 Subject: Re: New Ruby conditional semantics thoughts On Mon, 1 Nov 2004 13:48:51 +0900, Christoph wrote: > Robert Klemme schrieb: > .... > > > > class Object > > def to_b() self end > > end > > > > class SpecialBoolHandling > > def to_b ... end > > end > > > > if x.to_b > > ... > > else > > .. > > end > > > > I believe I've read a comment of Matz about this (implicitely calling > > to_b or somethig similar) where he mentioned performance as the reason > > why not to do it, bI'm not 100% sure. > > I once proposed a "truth" flag scheme akin to Ruby's > "tainted" and "frozen" flags schemes which can implemented > with an (depending on taste) acceptable performance penalty. > I believe that the implementation ([ruby-core:279] and > [ruby-core:294]) is still valid. > > I'd also choose this truth flags scheme over boolean > conversion methods any day, irrespective of performance > issues. > Just remember that we are NOT converting to boolean. In fact conversion to boolean is totally unneeded by this model. to_b was simple but that would require the creation of a VALUE for return. This does not. In fast it just calls a method that will yield relative to its "boolean value". I am currently looking at the 1.9 cvs code trying to decipher how they go about things now and what changes would need to be made at C level. Since this is a possible change for 2.0 not current revisions I will need to at least implement it in cvs head. The reason this is probably going to be done in C is because a large part of the job will be the parser's and other stuff that may be found through out ruby code. It is not something easy to do well in pure Ruby and maintain speed and safety of the code. In order to make this a possible RCR we must look at a real implementation because this is such a fundamental component of Ruby. The draw back of course is that a patch will be required which is a more inconvenient than a pure ruby implementation or a ruby extension. A reason not to use a truth flag is that boolean value may involve call-time evaluation of truthfulness. This removes the perceived lazy evaluation. This would normally create a large performance hit but, we can implement faster code in Object by default and then allow overrides that may be slower (if in ruby). A way to use it: internal representation of a non-overridden object might use a truth flag as that fast implementation. The unfortunate thing about most everything I just said is that I am still learning the internals of Ruby (beyond ruby.h ;) ). This means I may not understand the C implementation correctly. Either way, it is something I am looking at right now. If any of you guys have pointers they are welcome. Also, I am on #ruby-lang as binary42 a large portion of the day and evening (Mountain Time) if you would like a more interactive conversation about this. Thanks for your input! I will look at the posts in the morning. :) Brian Mitchell.