[ruby-core:21822] [Feature #1102] Prepend Module

0 views
Skip to first unread message

Thomas Sawyer

unread,
Feb 3, 2009, 9:37:24 PM2/3/09
to ruby...@ruby-lang.org
Feature #1102: Prepend Module
http://redmine.ruby-lang.org/issues/show/1102

Author: Thomas Sawyer
Status: Open, Priority: Normal
Category: core, Target version: 1.9.x

Currently when a module is included into a classes, it is appended to the class hierarchy (ie. the method lookup order). This of course makes sense, but there are times when it would be useful to *prepend* the module. For example:

class C
def x; "x"; end
end

module M
def x; '[' + super + ']'; end
end

class C
prepend M
end

C.new.x #=> "[x]"

One big advantage of this is being able to override methods in a safer way, rather than using alias or tricks like alias_method_chain.


----------------------------------------
http://redmine.ruby-lang.org

Roger Pack

unread,
Feb 7, 2009, 9:42:42 PM2/7/09
to ruby...@ruby-lang.org
> Currently when a module is included into a classes, it is appended to the class hierarchy (ie. > the method lookup order). This of course makes sense, but there are times when it would be > useful to *prepend* the module. For example:

I suppose one [not too useful] hack at it could be something like

class Class
def insert_module_at_top mod
previous_ancestors = self.ancestors.select{|a| a.class == Module}
include mod
previous_ancestors.each{|a| include a.dup}
end
end

#again we have to start with a module.

module Original


def x; '[' + super + ']'; end
end

class A
include Original
end

module Prepend


def x; "x"; end
end

A.insert_module_at_top Prepend
puts A.new.x
=> [x]

Perhaps what we're saying here is we wish we could "grab" methods from
classes, to be able to manipulate the hierarchy better? This is
possible with RubyParser, since you can basically get back to the
source of the method and thus copy it around, but not afaik with 1.9
-=r

trans

unread,
Mar 20, 2009, 5:50:27 AM3/20/09
to ruby...@ruby-lang.org

Well, that's not really the issue here. The need is to *wrap*
previously defined instance methods. If every method were defined in a
module (something I have suggested in the past actually) then it would
not be needed.

The utility comes from doing AOP-esque coding. Consider modules that
can initialize values.

class X
end

module P
attr :p
def initialize
@p = []
super
end
end

class X
prepend P
end

X.new.p => []

T.

Roger Pack

unread,
Mar 1, 2010, 2:47:24 PM3/1/10
to ruby...@ruby-lang.org
Issue #1102 has been updated by Roger Pack.


+1 for Module#prepend
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1102

----------------------------------------
http://redmine.ruby-lang.org

Michael Fellinger

unread,
Mar 1, 2010, 8:49:26 PM3/1/10
to ruby...@ruby-lang.org
Issue #1102 has been updated by Michael Fellinger.

Yusuke Endoh

unread,
Mar 1, 2010, 10:40:58 PM3/1/10
to ruby...@ruby-lang.org
Issue #1102 has been updated by Yusuke Endoh.

Target version changed from 1.9.x to 2.0

Hi,

This ticket was also discussed in the thread from [ruby-core:25208].


Module#prepend may be very significant feature not only to implementation
but also to Ruby's OO model itself.
Don't consider it just convenient method like Array's and String's.

So, in my opinion, this feature should not be included in 1.9.x.
We should discuss it towards 2.0.


Even if it will be included in 1.9.x, we need more discussion.
Just seeing clean example, you'll find it cool. But in fact, we must
also discuss many dirty things:

- edge semantics
- prepend into embedded class
- prepend into singleton class
- collaboration with reflection
- collaboration with future expansion (e.g., classbox)
- etc.

- implementation
- robustness
- binary compatibility
- expandability
- maintainability
- performance

I think it is difficult to discuss them without material. So, please
write a patch first if you really want.

--
Yusuke Endoh <ma...@tsg.ne.jp>

Reply all
Reply to author
Forward
0 new messages