[#6864] ruby 1.8.4 rc breaks alias_method/rails in bad ways — "Ara.T.Howard" <ara.t.howard@...>

20 messages 2005/12/09
[#6870] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...> 2005/12/12

Ara.T.Howard wrote:

[#6872] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, [ISO-8859-15] Florian Growrote:

[#6873] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — James Edward Gray II <james@...> 2005/12/12

On Dec 12, 2005, at 1:19 PM, ara.t.howard@noaa.gov wrote:

[#6874] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, James Edward Gray II wrote:

[#6891] Time.utc! and Time.localtime! — Daniel Hobe <hobe@...>

Writing a script yesterday I found out, much to my surprise, that the

16 messages 2005/12/14

[#6918] change to yaml in 1.8.4 — ara.t.howard@...

14 messages 2005/12/16

[#6934] 1.8.x, YAML, and release management — Ryan Davis <ryand-ruby@...>

I'm concerned that 1.8.3's acceptance of non-backwards-compatible

28 messages 2005/12/18

[#6996] Problems building 1.8.4 with VS8 C++ Express Edition (cl 14.00) — Austin Ziegler <halostatue@...>

Visual Studio C++ 2005 Express Edition (VS 8.0)

20 messages 2005/12/27

Re: Time.utc! and Time.localtime!

From: Yukihiro Matsumoto <matz@...>
Date: 2005-12-15 08:21:37 UTC
List: ruby-core #6904
Hi,

In message "Re: Time.utc! and Time.localtime!"
    on Thu, 15 Dec 2005 17:16:16 +0900, Kev Jackson <kevin.jackson@it.fts-vn.com> writes:

|>Hmm, usually I don't respond to mails saying "un-rubyish" or "POLS",
|>but this time I agree with that "utc" and "getutc" combination is more
|>un-rubyish than "utc" and "utc!".  But I'm not sure if we can fix it
|>for compatibility reason.

|Could you not keep the old methods for bwc and add new more 'ruby-ish' 
|methods as well?  (or aliases if it's in ruby code rather than in C)
|
|Not looked deeply into this at all, but I would have thought that adding 
|a method that simply refers back to the original method, but is more 
|nicely named shouldn't be too hard

Adding two new methods is OK.  Even removing methods is OK too.  But
changing "utc" behavior like this is problematic, since the
interpreter cannot tell which "utc" programmers want to use.

							matz.

In This Thread