Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > If you are happy with the direction of Ruby 1.8.7+, respond

Reply
Thread Tools

If you are happy with the direction of Ruby 1.8.7+, respond

 
 
Coey Minear
Guest
Posts: n/a
 
      02-12-2009
Jeremy Henty writes:
> On 2009-02-11, Pit Capitain <(E-Mail Removed)> wrote:
> > 2009/2/11 Rados?aw Bu?at <(E-Mail Removed)>:
> >> h={}
> >> h[{"foo" => 1}] = 100
> >> p h[{"foo" => 1}]
> >>
> >> ruby 1.8.6 prints "nil", 1.8.7 prints "100".

> >
> > Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this
> > is an example where the 1.8.7 version yields the result most people
> > would expect,

>
> No it doesn't. Most people would expect 1.8.7 to yield the same
> result as 1.8.6 . That is the point.
>
> Regards,
>
> Jeremy Henty
>


As I read this, my feeling about what "most people" would expect
should fall into one of two categories:
- hashes should allow (different) hashes to be used as keys; or
- hashes should _not_ allow hashes to be used as keys.

If someone feels the first response is correct, then '100' would be
what they expect from Ruby. If someone feels the second response is
correct, then they would probably expect a SyntaxError or RuntimeError
exception to be thrown.

So from my perspective, having a hash with a hash as a key return
'nil' is a bug (in the example given above, where it was previously
set), and bugs should be fixed, in all versions. You are arguing from
the third camp of "I'm used to the bug so please don't fix it."

Of course, these are just my opinions. And in general, I do fall into
the "don't change the API behavior between 1.8.6 and 1.8.7" camp. But
in this case, I would say the 1.8.6 behavior described is a bug and
should be addressed.


Coey Minear

 
Reply With Quote
 
 
 
 
Prashant Srinivasan
Guest
Posts: n/a
 
      02-12-2009
I'm in the happy camp, mostly. It's fine to add new features to an
upwardly compatible release as long as one doesn't sacrifice the
stability(given this is a "production" release) - i.e., upwardly
compatible does NOT mean that feature set of version x.y.z should be the
same as the feature set of x.y.z+1. API compatibility across 'teeny'
releases is important, and, is something Matz and others have
professed(in a thread I don't have a pointer handy, but it's on ruby-core).

Fixes to bugs, IMO, cannot be counted as making the software
incompatible - if they did, the language implementation would get nowhere.

On the other hand, changes to the existing APIs that are not generally
accepted as bugs definitely count as incompatibilities - IMO, it's this
area thats tinged with shades of gray, since I cannot easily tell if
some 'bug fixes' are indeed 'bug fixes' or if they break the
compatibility expectations that the Ruby versioning system sets.( I
work for a Ruby vendor that, among other things, promises compatibility,
and any mixed bag of fixes + compatibility breakages, if indeed it is
so, is an issue to deal with).

Just my 2 cents,
-ps







Coey Minear wrote:
> Jeremy Henty writes:
> > On 2009-02-11, Pit Capitain <(E-Mail Removed)> wrote:
> > > 2009/2/11 Rados?aw Bu?at <(E-Mail Removed)>:
> > >> h={}
> > >> h[{"foo" => 1}] = 100
> > >> p h[{"foo" => 1}]
> > >>
> > >> ruby 1.8.6 prints "nil", 1.8.7 prints "100".
> > >
> > > Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this
> > > is an example where the 1.8.7 version yields the result most people
> > > would expect,

> >
> > No it doesn't. Most people would expect 1.8.7 to yield the same
> > result as 1.8.6 . That is the point.
> >
> > Regards,
> >
> > Jeremy Henty
> >

>
> As I read this, my feeling about what "most people" would expect
> should fall into one of two categories:
> - hashes should allow (different) hashes to be used as keys; or
> - hashes should _not_ allow hashes to be used as keys.
>
> If someone feels the first response is correct, then '100' would be
> what they expect from Ruby. If someone feels the second response is
> correct, then they would probably expect a SyntaxError or RuntimeError
> exception to be thrown.
>
> So from my perspective, having a hash with a hash as a key return
> 'nil' is a bug (in the example given above, where it was previously
> set), and bugs should be fixed, in all versions. You are arguing from
> the third camp of "I'm used to the bug so please don't fix it."
>
> Of course, these are just my opinions. And in general, I do fall into
> the "don't change the API behavior between 1.8.6 and 1.8.7" camp. But
> in this case, I would say the 1.8.6 behavior described is a bug and
> should be addressed.
>
>
> Coey Minear
>
>



 
Reply With Quote
 
 
 
 
Rick DeNatale
Guest
Posts: n/a
 
      02-12-2009
[Note: parts of this message were removed to make it a legal post.]

On Thu, Feb 12, 2009 at 10:59 AM, James Coglan <(E-Mail Removed)>wrote:

> 2009/2/12 Jeremy Henty <(E-Mail Removed)>
>
> > On 2009-02-11, Pit Capitain <(E-Mail Removed)> wrote:
> > > 2009/2/11 Rados?aw Bu?at <(E-Mail Removed)>:
> > >> h={}
> > >> h[{"foo" => 1}] = 100
> > >> p h[{"foo" => 1}]
> > >>
> > >> ruby 1.8.6 prints "nil", 1.8.7 prints "100".
> > >
> > > Ah, you mean Hash#hash. Thanks a lot, I didn't know that. But this
> > > is an example where the 1.8.7 version yields the result most people
> > > would expect,

> >
> > No it doesn't. Most people would expect 1.8.7 to yield the same
> > result as 1.8.6 . That is the point.

>
>
>
> Though I fall on the 'unhappy' side, this change is clearly fine: 1.8.6
> behaviour is clearly a bug and should be fixed, that's the point of bug fix
> releases. Relying on buggy behaviour is a bad idea, and so is making
> changes
> to ostensibly correct behaviour in minor releases.
>


The problem is that one man's bug is another's breaking change. Lot's of
people always found the fact that Strings acted like collections of
character codes rather than characters as a bug.

>ruby -e'p "abc"[0]'

97

fixed by 1.9
>ruby1.9 -e'p "abc"[0]'

"a"

But there is a lot of Ruby <1.8.7 code whose correct behavior depends on
that "bug" considering it part of the old Ruby language definition.

And there's lots of history of that behavior being defined not as a bug but
as the way that Ruby works.

The problem with making semantic changes like this, whether they are
pseudo-bugfixes or not, is that it's very hard to sort out ahead of time
what impact they will have on the installed base of code using the 'stable'
version.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

 
Reply With Quote
 
Pit Capitain
Guest
Posts: n/a
 
      02-13-2009
2009/2/13 Jeremy Henty <(E-Mail Removed)>:
> OK, I accept your point for this particular change. It doesn't hold
> for other changes, eg. methods returning Enumerators when they used to
> return Arrays.


Jeremy, can you show us an example?

Regards,
Pit

 
Reply With Quote
 
Marc Heiler
Guest
Posts: n/a
 
      02-13-2009
I am indifferent to it, may I post here as well?

My only general complaint would be that I think that some releases may
have more bugs than others. Maybe a year ago, the ruby release candidate
for some 1.9.x version had an irb which segfaulted for me. The later
1.9.x irb didn't segfault anymore. Irb is quite important for me so I
was surprised to see irb has had difficulties.

My wish would be that the amount of bugs is kept to a minimum.
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Tony Arcieri
Guest
Posts: n/a
 
      02-16-2009
[Note: parts of this message were removed to make it a legal post.]

On Wed, Feb 11, 2009 at 10:12 AM, Gregory Brown
<(E-Mail Removed)>wrote:

> This one is for those who wish that Ruby 1.8 would go *back* to being
> 1.8.6 compatible in Ruby 1.8.8. If you agree with this, share your
> thoughts or at least a simple '+1'. If you disagree, please find the
> other thread titled 'If you are happy with the direction of Ruby
> 1.8.7, respond'. If you are in the middle, I don't know what you
> should do... write two posts?
>


If you ask me, what the Pythonistas got right that Ruby 1.8.7+ does not is:

from __future__ import x

I think it's great that Ruby 1.8.7+ wants to include all these nifty 1.9
features. But, I don't think they should be "on" by default.

I think it'd be great if certain features (e.g. the 1.9.x enumerators) were
available if you were to, say, require "future/enumerator" or something.

If that were the case, I'd be on board with backporting everything, although
changes to the grammar of the language itself might be difficult to enable
in this manner, and many bring backwards compatibility issues.

--
Tony Arcieri

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
If you are unhappy with the direction of Ruby 1.8.7+, respond Gregory Brown Ruby 171 02-15-2009 01:54 PM
OT: Happy Happy Joy Joy! Mike T. MCSE 79 11-19-2006 08:22 PM
HEXUS.opinions :: Have a happy happy gaming holiday Silverstrand Front Page News 0 12-23-2005 04:12 PM
Happy Happy Joy Joy, I recovered my photos Tama Mativa Digital Photography 9 05-24-2004 04:58 PM
happy happy christmas showgun MCSE 26 12-17-2003 07:11 PM



Advertisments