Hello,
Is there a Ruby language specification?
I read the following on wikipedia;
There is currently no specification of the Ruby language, so the
original implementation is considered to be the de facto reference.
I'm no authority on these matters, but wouldn't it be safer to draft a
specification formally?
~Mayuresh
Rubinius and JRuby use a shared RSpec suite which they use to test
compatiability. It's not the Official Spec(tm) but I think it's the
closest to one.
Farrel
2008/8/9 Mayuresh Kathe <kathe.mayuresh@gmail.com>:
I read the following on wikipedia;
There is currently no specification of the Ruby language, so the
original implementation is considered to be the de facto reference.I'm no authority on these matters, but wouldn't it be safer to draft a
specification formally?
--
Aimred - Ruby Development and Consulting
Mayuresh Kathe wrote:
I'm no authority on these matters, but wouldn't it be safer to draft a
specification formally?~Mayuresh
I don't know that Ruby will ever have a formal spec (a la Python), but
there are ongoing discussions involving the major players. You can find
more info at http://ruby-design.pbwiki.com/\. There is also a RubySpec
project that can be found on github (I think this is what Farrel was
refering to): http://github.com/rubyspec/rubyspec/tree/master\.
Unfortunately, the spec is currently focused on 1.8.
-Josh
--
Posted via http://www.ruby-forum.com/\.
that is so far from an actual specification it isn't funny.
On Aug 9, 2008, at 06:42 , Farrel Lifson wrote:
Rubinius and JRuby use a shared RSpec suite which they use to test
compatiability. It's not the Official Spec(tm) but I think it's the
closest to one.
Erm, how? Is there something particularly deficient about the actual specs?
Or are you just uncomfortable with having a test suite be a specification?
If it's the latter, read on.
My thoughts: If you've ever filed a decent bug report, you've already done
this. Even for an "enhancement", even for older trackers like Bugzilla,
there's an expectation that you'll write something like this:
Steps to reproduce:
1. Log in
2. Go to your profile
3. Click on 'foo'
Expected result:
It should 'bar' when I click 'foo'.
Actual result:
I got an "Internal Server Error: 500" error. Log pasted below.
Now, actually parse that out. Sounds exactly like a regression test, to
me. "Steps to reproduce" are steps to setup the test. "Expected result" is
your assertions.
Again, who says it has to be a bug? Test-driven development suggests that you
should code by writing the test first, then fix it. Shouldn't the same hold
true for enhancements, also? All that would change is that "Expected result"
would be some feature that doesn't exist yet.
Behavior-driven development (behaviour-driven.org) and supporting software
(rspec.info) only make this relationship more explicit. Given a
properly-formatted feature specification (similar to above), you can actually
generate skeleton integration tests (called "stories").
It works the other way around, too -- Rspec will generate English-language
versions of its tests, which can be used as a specification.
When you think about it, any open standard should have at least an open
implementation. If it is meant to allow multiple implementations, it should
also have an automated test suite -- for the Web, we have validator.w3.org,
as well as the Acid2 (and now Acid3) tests, as an easy way to measure a
particular implementation's adherence to the standard.
We all agree that a suite of compatibility tests is a good thing, right?
Here are those links again, in case your client didn't make them into links:
On Saturday 09 August 2008 23:26:28 Ryan Davis wrote:
On Aug 9, 2008, at 06:42 , Farrel Lifson wrote:
> Rubinius and JRuby use a shared RSpec suite which they use to test
> compatiability. It's not the Official Spec(tm) but I think it's the
> closest to one.that is so far from an actual specification it isn't funny.
Ryan Davis wrote:
Rubinius and JRuby use a shared RSpec suite which they use to test
compatiability. It's not the Official Spec(tm) but I think it's the
closest to one.that is so far from an actual specification it isn't funny.
I think that substituting a suite of tests (or "expected behaviors") is
more in keeping with "the Ruby way" than a formal language
specification. After all, isn't the primary goal of a language spec to
ensure that your program will run on a given system? Why can't a test
suite give me that assurance as well as a formal spec?
In fact, Joel Spolsky's bit on "Martian Headsets"
(Martian Headsets – Joel on Software) is rather informative
for this discussion. If Ruby had a standard, but not a comprehensive
test suite, we'd probably be _less_ confident of the
cross-implementation compatibility of our programs. That's not to say
that a formal specification would be a bad thing, just that between a
test suite and a formal spec, the spec is less important.