# Compliant\_on(:ruby) in RubySpecs

**URL:** <https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089>\
**Category:** IronRuby\
**Created:** [January 7, 2009, 9:27am UTC](https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089 "2009-01-07T09:27:41Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shri\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/898d66/32.png) [@Shri\_B](https://www.ruby-forum.com/u/Shri_B)\
**Post date:** [January 7, 2009, 9:27am UTC](https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089/1 "2009-01-07T09:27:41Z")

</div>

I noticed that besides not\_compliant\_on to disable tests on specific  
Ruby implementations, there is also compliant\_on to enable tests only on  
selected implementations. There are ~120 such instances. To make  
IronRuby compliant, we not only have to reduce the number of \*\_tags.txt  
files, we also have to add “:ir” to all uses of compliant\_on.

However, this seems backwards. Shouldn’t we try to remove most uses of  
compliant\_on, and instead add tags for the implementations where the  
test does not work? There may be a few valid uses of compliant\_on for  
tests which only work on, say, JRuby. However, only a handful of the  
occurrences are of this kind. The vast majoriy include :ruby which means  
it should be the standard.

Should it be a goal to change compliant\_on so that it does not allow  
:ruby?

Thanks,  
Shri

---

<div class="post-metadata">

**Author:** ![Shri\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/898d66/32.png) [@Shri\_B](https://www.ruby-forum.com/u/Shri_B)\
**Post date:** [January 7, 2009, 8:03pm UTC](https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089/2 "2009-01-07T20:03:08Z")

</div>

I can check with Brian, but my understanding is as follows. The spec’s  
are meant to be a complete packaged spec. Tag files are a convenience  
for using the spec’s as a regression test. I feel, and I would guess  
this to be Brian’s feelings, that when an implementation is complete (as  
in everything is implemented), there should not be a set of tag files  
for that implementation.

The other goal of the spec’s is to be a spec. To that goal, you  
shouldn’t have to go outside of the spec’s to find out compliance  
information. Including the information into the file makes it easier to  
see what a specific implementation of Ruby supports. Keeping the code  
DRY in tests isn’t as important as conveying information in those tests.

JD

From: Shri B.  
Sent: Wednesday, January 07, 2009 12:26 AM  
To: Jim D.  
Cc: removed\_email\_address@domain.invalid  
Subject: compliant\_on(:ruby) in RubySpecs

I noticed that besides not\_compliant\_on to disable tests on specific  
Ruby implementations, there is also compliant\_on to enable tests only on  
selected implementations. There are ~120 such instances. To make  
IronRuby compliant, we not only have to reduce the number of \*\_tags.txt  
files, we also have to add “:ir” to all uses of compliant\_on.

However, this seems backwards. Shouldn’t we try to remove most uses of  
compliant\_on, and instead add tags for the implementations where the  
test does not work? There may be a few valid uses of compliant\_on for  
tests which only work on, say, JRuby. However, only a handful of the  
occurrences are of this kind. The vast majoriy include :ruby which means  
it should be the standard.

Should it be a goal to change compliant\_on so that it does not allow  
:ruby?

Thanks,  
Shri

---

<div class="post-metadata">

**Author:** ![Shri\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/898d66/32.png) [@Shri\_B](https://www.ruby-forum.com/u/Shri_B)\
**Post date:** [January 7, 2009, 9:02pm UTC](https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089/3 "2009-01-07T21:02:56Z")

</div>

I see the point of having all the information within the specs. It is  
useful to read a spec and to be able to know how other implementations  
behave (assuming the implementation is solid enough as to not cause a  
huge number of usages of not\_compliant\_on in the test code base).

However, I think compliant\_on(:ruby, :ir) for example should be replaced  
with not\_compliant\_on(:jruby, :rubinius). That is, only opt-out should  
be supported, not opt-in. Otherwise, other implementations may not run  
the test even if they support that functionality.

From: Jim D.  
Sent: Wednesday, January 07, 2009 10:57 AM  
To: Shri B.  
Cc: removed\_email\_address@domain.invalid  
Subject: RE: compliant\_on(:ruby) in RubySpecs

I can check with Brian, but my understanding is as follows. The spec’s  
are meant to be a complete packaged spec. Tag files are a convenience  
for using the spec’s as a regression test. I feel, and I would guess  
this to be Brian’s feelings, that when an implementation is complete (as  
in everything is implemented), there should not be a set of tag files  
for that implementation.

The other goal of the spec’s is to be a spec. To that goal, you  
shouldn’t have to go outside of the spec’s to find out compliance  
information. Including the information into the file makes it easier to  
see what a specific implementation of Ruby supports. Keeping the code  
DRY in tests isn’t as important as conveying information in those tests.

JD

From: Shri B.  
Sent: Wednesday, January 07, 2009 12:26 AM  
To: Jim D.  
Cc: removed\_email\_address@domain.invalid  
Subject: compliant\_on(:ruby) in RubySpecs

I noticed that besides not\_compliant\_on to disable tests on specific  
Ruby implementations, there is also compliant\_on to enable tests only on  
selected implementations. There are ~120 such instances. To make  
IronRuby compliant, we not only have to reduce the number of \*\_tags.txt  
files, we also have to add “:ir” to all uses of compliant\_on.

However, this seems backwards. Shouldn’t we try to remove most uses of  
compliant\_on, and instead add tags for the implementations where the  
test does not work? There may be a few valid uses of compliant\_on for  
tests which only work on, say, JRuby. However, only a handful of the  
occurrences are of this kind. The vast majoriy include :ruby which means  
it should be the standard.

Should it be a goal to change compliant\_on so that it does not allow  
:ruby?

Thanks,  
Shri

---

<div class="post-metadata">

**Author:** ![Shri\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/898d66/32.png) [@Shri\_B](https://www.ruby-forum.com/u/Shri_B)\
**Post date:** [January 7, 2009, 9:33pm UTC](https://www.ruby-forum.com/t/compliant-on-ruby-in-rubyspecs/157089/4 "2009-01-07T21:33:00Z")

</div>

[http://rubyspec.org/wiki/rubyspec/Guards](http://rubyspec.org/wiki/rubyspec/Guards)

If you scroll to the compliant portion of the page, you’ll see that they  
actually have different meanings, and they are based on the reference  
implementation (CRuby). I had forgotten this until just now.

JD

From: Shri B.  
Sent: Wednesday, January 07, 2009 11:39 AM  
To: Jim D.  
Cc: removed\_email\_address@domain.invalid  
Subject: RE: compliant\_on(:ruby) in RubySpecs

I see the point of having all the information within the specs. It is  
useful to read a spec and to be able to know how other implementations  
behave (assuming the implementation is solid enough as to not cause a  
huge number of usages of not\_compliant\_on in the test code base).

However, I think compliant\_on(:ruby, :ir) for example should be replaced  
with not\_compliant\_on(:jruby, :rubinius). That is, only opt-out should  
be supported, not opt-in. Otherwise, other implementations may not run  
the test even if they support that functionality.

From: Jim D.  
Sent: Wednesday, January 07, 2009 10:57 AM  
To: Shri B.  
Cc: removed\_email\_address@domain.invalid  
Subject: RE: compliant\_on(:ruby) in RubySpecs

I can check with Brian, but my understanding is as follows. The spec’s  
are meant to be a complete packaged spec. Tag files are a convenience  
for using the spec’s as a regression test. I feel, and I would guess  
this to be Brian’s feelings, that when an implementation is complete (as  
in everything is implemented), there should not be a set of tag files  
for that implementation.

The other goal of the spec’s is to be a spec. To that goal, you  
shouldn’t have to go outside of the spec’s to find out compliance  
information. Including the information into the file makes it easier to  
see what a specific implementation of Ruby supports. Keeping the code  
DRY in tests isn’t as important as conveying information in those tests.

JD

From: Shri B.  
Sent: Wednesday, January 07, 2009 12:26 AM  
To: Jim D.  
Cc: removed\_email\_address@domain.invalid  
Subject: compliant\_on(:ruby) in RubySpecs

I noticed that besides not\_compliant\_on to disable tests on specific  
Ruby implementations, there is also compliant\_on to enable tests only on  
selected implementations. There are ~120 such instances. To make  
IronRuby compliant, we not only have to reduce the number of \*\_tags.txt  
files, we also have to add “:ir” to all uses of compliant\_on.

However, this seems backwards. Shouldn’t we try to remove most uses of  
compliant\_on, and instead add tags for the implementations where the  
test does not work? There may be a few valid uses of compliant\_on for  
tests which only work on, say, JRuby. However, only a handful of the  
occurrences are of this kind. The vast majoriy include :ruby which means  
it should be the standard.

Should it be a goal to change compliant\_on so that it does not allow  
:ruby?

Thanks,  
Shri