dynamic loading and unloading of module

Hi,

I want to load and remove dynamically Module in an application. Removing is possible, but

I am not able to reload it. Is there any way to do it?

Is it even recommendable to do something like this?

Ulli

module Mod
def foo
puts "fooing"
end
end

module Modd
def foo
puts "fooing2"
end
end

class C
include Mod

def self.remove_module(m)
m.instance_methods.each{|m| undef_method(m)}
end

def self.addModul m
include m
end
end

c = C.new
c.foo
C.remove_module(Mod)

C.addModul(Modd)
c.foo

Once a module is included, prepended or extended the action cannot be
reversed. Yes, you can remove its methods, but I don't know what you would
do about constants.

Cary

···

Sent from my Apple II+

On Thu, Aug 15, 2019 at 1:50 AM ulli bei Unity <upahermann@unitybox.de> wrote:

Hi,

I want to load and remove dynamically Module in an application. Removing
is possible, but

I am not able to reload it. Is there any way to do it?

Is it even recommendable to do something like this?

Ulli

module Mod
  def foo
    puts "fooing"
  end
end

module Modd
  def foo
    puts "fooing2"
  end
end

class C
  include Mod

  def self.remove_module(m)
    m.instance_methods.each{|m| undef_method(m)}
  end

  def self.addModul m
        include m
    end
end

c = C.new
c.foo
C.remove_module(Mod)

C.addModul(Modd)
c.foo

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

What are you trying to accomplish? Obligatory question: do you know Zeitwerk
<https://github.com/fxn/zeitwerk>? (I am the author.)

I wouldn’t use a module here. Sounds like the factory pattern might be a
better option.

···

On Thu, Aug 15, 2019 at 5:10 PM Cary Swoveland <cary@swoveland.com> wrote:

Once a module is included, prepended or extended the action cannot be
reversed. Yes, you can remove its methods, but I don't know what you would
do about constants.

Cary

Sent from my Apple II+

On Thu, Aug 15, 2019 at 1:50 AM ulli bei Unity <upahermann@unitybox.de> > wrote:

Hi,

I want to load and remove dynamically Module in an application. Removing
is possible, but

I am not able to reload it. Is there any way to do it?

Is it even recommendable to do something like this?

Ulli

module Mod
  def foo
    puts "fooing"
  end
end

module Modd
  def foo
    puts "fooing2"
  end
end

class C
  include Mod

  def self.remove_module(m)
    m.instance_methods.each{|m| undef_method(m)}
  end

  def self.addModul m
        include m
    end
end

c = C.new
c.foo
C.remove_module(Mod)

C.addModul(Modd)
c.foo

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

I do not think so. To me this looks like an item that can play different
roles at different times or gain capabilities and have them removed.
Factory just allows variants for creation but then capabilities are fixed.
Certainly you cannot remove something after creation with the factory
pattern.

Kind regards

robert

···

On Fri, Aug 16, 2019 at 1:10 PM Chris Roerig <croerig@gmail.com> wrote:

I wouldn’t use a module here. Sounds like the factory pattern might be a
better option.

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can -
without end}
http://blog.rubybestpractices.com/

Hi. You can’t “remove” them but you can replace them by calling the factory
again. My thought was to stuff the functionality needed into dedicated
classes and swap that functionality as the need changes. That being said,
it’s only one way to address the issue.

Cheers

···

On Sun, Aug 18, 2019 at 6:28 AM Robert Klemme <shortcutter@googlemail.com> wrote:

On Fri, Aug 16, 2019 at 1:10 PM Chris Roerig <croerig@gmail.com> wrote:

I wouldn’t use a module here. Sounds like the factory pattern might be a
better option.

I do not think so. To me this looks like an item that can play different
roles at different times or gain capabilities and have them removed.
Factory just allows variants for creation but then capabilities are fixed.
Certainly you cannot remove something after creation with the factory
pattern.

Kind regards

robert

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can -
without end}
http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

But note that the object needs to retain the state. That becomes awfully
complex with factory pattern because then you have to feed in the previous
object, replace references - basically it is not factory any more and the
handling becomes quite complex because you are not retaining object
identity - which, it seems to me, is required here. As said, I do not think
factory pattern is the right tool here.

Kind regards

robert

···

On Sun, Aug 18, 2019 at 1:31 PM Chris Roerig <croerig@gmail.com> wrote:

Hi. You can’t “remove” them but you can replace them by calling the
factory again. My thought was to stuff the functionality needed into
dedicated classes and swap that functionality as the need changes. That
being said, it’s only one way to address the issue.

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can -
without end}
http://blog.rubybestpractices.com/

It sounds like what would ideally be needed is something like Forwardable
but that lets you change the list of delegates dynamically.

martin

···

On Mon, Aug 19, 2019 at 3:31 AM Robert Klemme <shortcutter@googlemail.com> wrote:

On Sun, Aug 18, 2019 at 1:31 PM Chris Roerig <croerig@gmail.com> wrote:

Hi. You can’t “remove” them but you can replace them by calling the
factory again. My thought was to stuff the functionality needed into
dedicated classes and swap that functionality as the need changes. That
being said, it’s only one way to address the issue.

But note that the object needs to retain the state. That becomes awfully
complex with factory pattern because then you have to feed in the previous
object, replace references - basically it is not factory any more and the
handling becomes quite complex because you are not retaining object
identity - which, it seems to me, is required here. As said, I do not think
factory pattern is the right tool here.

I believe the problem is that we do not know the original use case, right?

You can redo trivially the ancestor chain of the parent class if you delete
the constant and define the whole thing again. That is the approach taking
to reload stuff in Rails.

You can inject behavior to the singleton class of instances, so only the
instance gets decorated, and the original class does not have the ancestor
chain affected. Different instances may be decorated differently (this
invalidates methods cache IIRC, but one thing is the technique needed to
solve something, and a different thing is performance.)

Active Support does some unloading by keeping a reference to original
methods and restoring them, but it is very manual/ad-hoc.

There are several techniques, it all depends on the details of what the OP
wants to accomplish. How often do you want to "unload", why do you want to,
etc.