After an upgrade of my ruby interpreter, many of my applications
do not run any longer. The problem was quite easy to find:
The behaviour of the singleton-method: Class.inherited has changed.
This method was called, when ruby finds a declaration of a subclass.
Now the method gets called, when the subclass was defined.
class Test # <- class declared
def bla
end
end # <- class defined
I use the Class.inherited feature to predefine nested classes
and constants. A nested class definition in such a class, will refine
those predefined classes. Therefor it is necessary to define such nested
classes after the class is declared (not defined).
The name Class.inherited implies the calling after a class is defined.
I suggest a second method Class.inherits, which gets called after a subclass is
declared. I think both approaches are useful to solve different problems.
Is it possible to introduce the method into the main ruby branch?
Is it possible to introduce the method into the main ruby branch?
Hmm, this is a good chance to reconsider about hooks. Currently we
have the following hook methods.
name | timing
=========================|===========================
inherited |after “class” (in Ruby)
included |after “include”
method_added |after “def”
singleton_method_added |after “def”
=========================|===========================
I’d like to hear about when, where, what names are suitable for
class/method definition hook methods, in addition to above methods?
Timing of existing hook might be changed after the discussion.
I’ve now got a fair amount (probably 50kloc) of Ruby in production. Most
of this runs on 1.6.7. I’m frankly nervous about upgrading it to 1.8
because of the various changes in the language. Particularly worrying
are changes where some syntax is valid in both the old and new Ruby, but
the semantics are different. The .inherited change that sparked this
thread is one example, changes in precedence in rescue andling is
another. I’ve noted others that have passed by on the list.
As Ruby moves from being a hobby language into something that people use
to write serious production code, I’m wondering if we need to stop and
consider the implications of incompatibilities such as these. We could
give ourselves a serious black eye if we were to ship a new release of
Ruby that stopped some major and publically visible application from
working.
As a starting point for discussion: how hard would it be to make it a
rule that all incompatible changes are introduced in two phases. In the
first, the interpreter would announce that the behavior will change, and
then in the second (say 3 months later) the change will be introduced.
That would allow us to run our existing code against the interim
release, and give us time to fix things up before the change is made.
Cheers
Dave
···
On Thu, 2003-01-02 at 08:48, Yukihiro Matsumoto wrote:
I’d like to hear about when, where, what names are suitable for
class/method definition hook methods, in addition to above methods?
Timing of existing hook might be changed after the discussion.
In what form would this announcement be? (for the Class#inherited
example, I don’t think a warning would work, since there’s no easy way
to detect how the user intended to use the function). A list of
significant changes from version to version would be nice (trudging
through the ChangeLog isn’t very helpful).
A “Matz’s time machine” might also help. This would allow users to pick
which semantics they want during the interim. Using it might look
something like:
require “future/some_new_feature”
Major changes in syntax or semantics should probably be allowed only in
a development version or in one of these time machine modules. If
stable versions contain only bugfixes and new features, then this makes
migration to a new (more-bug-free) version much easier.
Paul
···
On Fri, Jan 03, 2003 at 12:38:28AM +0900, Dave Thomas wrote:
As a starting point for discussion: how hard would it be to make it a
rule that all incompatible changes are introduced in two phases. In the
first, the interpreter would announce that the behavior will change, and
then in the second (say 3 months later) the change will be introduced.
That would allow us to run our existing code against the interim
release, and give us time to fix things up before the change is made.
Your worry is understandable. Unofortunately , the wider Ruby
used, the less incompatibility allowed.
As a starting point for discussion: how hard would it be to make it a
rule that all incompatible changes are introduced in two phases. In the
first, the interpreter would announce that the behavior will change, and
then in the second (say 3 months later) the change will be introduced.
That would allow us to run our existing code against the interim
release, and give us time to fix things up before the change is made.
Then, I will wait for two or three months of preview time. This
pattern should be kept in the future.
By the way, back to the original issue; after examining the change
history, I found out that change was wrong. I will back it up to
the original 1.6 “inherited” behavior.
matz.
···
In message “Compatibility (was Class.inherited)” on 03/01/03, Dave Thomas dave@pragprog.com writes:
whatever happened to the idea of a compatability module? i.e. by requiring a
special module 1.8 would act just like 1.6.8. and one could do it peicemeal
perhaps, which would make it easy to migrate.
-transami
···
On Thursday 02 January 2003 08:38 am, Dave Thomas wrote:
I’ve now got a fair amount (probably 50kloc) of Ruby in production. Most
of this runs on 1.6.7. I’m frankly nervous about upgrading it to 1.8
because of the various changes in the language. Particularly worrying
are changes where some syntax is valid in both the old and new Ruby, but
the semantics are different. The .inherited change that sparked this
thread is one example, changes in precedence in rescue andling is
another. I’ve noted others that have passed by on the list.
I’d like to hear about when, where, what names are suitable for
class/method definition hook methods, in addition to above methods?
Timing of existing hook might be changed after the discussion.
This raises a somewhat bigger question.
I’ve now got a fair amount (probably 50kloc) of Ruby in production. Most
of this runs on 1.6.7. I’m frankly nervous about upgrading it to 1.8
because of the various changes in the language. Particularly worrying
are changes where some syntax is valid in both the old and new Ruby, but
the semantics are different. The .inherited change that sparked this
thread is one example, changes in precedence in rescue andling is
another. I’ve noted others that have passed by on the list.
As Ruby moves from being a hobby language into something that people use
to write serious production code, I’m wondering if we need to stop and
consider the implications of incompatibilities such as these. We could
give ourselves a serious black eye if we were to ship a new release of
Ruby that stopped some major and publically visible application from
working.
As a starting point for discussion: how hard would it be to make it a
rule that all incompatible changes are introduced in two phases. In the
first, the interpreter would announce that the behavior will change, and
then in the second (say 3 months later) the change will be introduced.
That would allow us to run our existing code against the interim
release, and give us time to fix things up before the change is made.
And, if changes must be made that break code perhaps we should offer
compatibility modules, something like:
#Say I’m running 1.8, but I want it to act like 1.6*:
require ‘ruby_1.6’
…or some similar mechanism.
Or, what about a command line option?
On Thu, 2003-01-02 at 08:48, Yukihiro Matsumoto wrote:
–
“Or perhaps the truth is less interesting than the facts?”
Amy Weiss (accusing theregister.co.uk of engaging in ‘tabloid journalism’)
Senior VP, Communications
Recording Industry Association of America
By the way, back to the original issue; after examining the change
history, I found out *that change was wrong*. I will back it up to
the original 1.6 "inherited" behavior.
Why it don't exist the equivalent of #inherited for #extend ?
In message “Re: Compatibility (was Class.inherited)” on 03/01/03, Tom Sawyer transami@transami.net writes:
whatever happened to the idea of a compatability module? i.e. by requiring a
special module 1.8 would act just like 1.6.8. and one could do it peicemeal
perhaps, which would make it easy to migrate.
We have ‘shim’ module which does completely opposite. By using that
module you can use 1.8 behavior on 1.6.x.
For the sake of flexibility I would appreciate two hooks: after declaration and
after definition of a subclass. Perhaps such a behaviour is useful for all other
hooks too (before and after a module is included, before and after a method is
defined …).
To the availability of hooks:
An additional trigger might be the definition of a nested module/class inside a
module/class. This is a feature I am missing.
By the way, back to the original issue; after examining the change
history, I found out that change was wrong. I will back it up to
the original 1.6 “inherited” behavior.
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
[23:42] drbrain@asx:~$ uname
FreeBSD
[23:42] drbrain@asx:~$ m /usr/ports/lang/ruby16-shim-ruby18/pkg-descr
Ruby Shim is a set of modules that provide the libraries and the
additional features that will appear in the next version of Ruby.
Shim between 1.6 and 1.8 includes:
features/ruby18 Hooks to support ruby 1.8 extensions
dl Interface to dynamic linker
racc-runtime Racc runtime module
stringio IO interface for String
strscan Fast string scanner
benchmark Benchmark module
fileutils File & directory manipulation
optparse Advanced command line option parser
pp Pretty printer (prettier version of `p')
set Set class
tsort Topological sorter