Re: Eval'ing 'yield' in 1.8 and 1.9

Hi Jeremy,

I hear ya! But there is a very fine line between the tests for more or
less official specification and the tests for bug-for-bug
compatibility with Matz Ruby.

I'd rather have a strong set of RubySpec tests, testing intentional
and designed behavior,  then the tests that blindly mimic current MRI
behavior, including the quirks and bugs.

That way, if other implementation fails some test, the implementor
should have a great confidence that the spec/test is indeed meaningful
and shouldn't be ignored.

Look at this from alt. implementation engineer point of view. If
RubySpecs for 1.8 force you to implement one behavior (which isn't
even intentional one!), and then RubySpecs for 1.9 force you to
implement another one, that'd waste some of the (very limited) time on
implementing wrong behavior.

Granted, some of the quirks and bugs are actually considered as
features by some, and sometimes we have no choice but to ask here, on
ruby-core :) And if some real libraries out there depend on such
quirks, we probably should have them specc'ed indeed.

Hey, but if you'd really like to participate and to contribute, you're
always welcome! :)
http://rubyspec.org/  (and #rubyspec on freenode IRC).

Thanks,
  --Vladimir

On Tue, Jun 3, 2008 at 8:04 PM, Jeremy Henty <[e-mail]> wrote:
> On Wed, Jun 04, 2008 at 01:29:05AM +0900, Vladimir Sizikov wrote:
>
>> Thanks! So,  I'll remove  the RubySpec test  that enforces  this 1.8
>> accidental behavior for all 1.8 level implementations,
>
> Pardon me, but is this really  a good idea?  What happens if different
> "Ruby-1.8  compatible"  implementations start  handling  this case  in
> different  ways?  You  could  end  up with  Ruby-1.8  code that  looks
> portable, but isn't.  It will be bad news if people who develop on MRI
> get strange unexpected failures when porting to eg. Maglev.
>
>> since  there  is  no  point  of  enforcing  something  that  is  not
>> considered as a intentional behavior.
>
> But maybe there is a  point?  Maybe it's better to enforce consistency
> even  though  the "correct"  behaviour  is  the  result of  historical
> accident?
>
> Just my 2  cents.  (I'm a long time  lurker but I don't claim  to be a
> language expert.)
>
> Regards,
>
> Jeremy Henty
>
>