Jump to content
Tsukihime

Inheriting from a module?

Recommended Posts

I am pushing out a custom BattleManager, and it overwrites a lot of existing methods and adds some new ones.

So I want to create a new battle manager that extends from the default, but then allows me to add new methods and overwrite existing methods.

How do I do this?

For example,
 

module BattleManager
  ...
end

module MyBattleManager
  #extends BattleManager

  def self.judge_win_loss
     special_ending if @win
     custom_defeat if @lost
  end

  def self.special_ending
    #my special ending
  end

  def self.custom_defeat
    #you lost
  end

end


Then when I call the code, it is like

 

 

MyBattleManager.setup(...)


Which sets up the battle just like BattleManager, but my Scene Battle will be calling MyBattleManager instead of the default BattleManager.

 

 

Share this post


Link to post
Share on other sites

You don't need to create a new module name, you add new methods to that module just adding it like:

 

module Battlemanager
  def (self)old_method
 blah
  end
end

module BattleManager
  def (self)old_method
    overwrite
  end

  def (self)new_method
     new method thing
  end
end

 

By this, if you need to overwrite an existing method, just use the same method name as usual, if you need to add new ones, add new as usual, and also you can alias a module method, create variables inside that can be read.

Edited by Mephistox

Share this post


Link to post
Share on other sites

You don't need to create a new module name, you add new methods to that module just adding it like:

 

module Battlemanager
  def (self)old_method
 blah
  end
end

module BattleManager
  def (self)old_method
 overwrite
  end

  def (self)new_method
  new method thing
  end
end

 

By this, if you need to overwrite an existing method, just use the same method name as usual, if you need to add new ones, add new as usual, and also you can alias a module method, create variables inside that can be read.

 

This is probably a noob question, but I always thought module methods were done like:

def self.someMethod

 

Not with parentheses. Or has this changed?

Share this post


Link to post
Share on other sites

You don't need to create a new module name, you add new methods to that module just adding it like:

 

module Battlemanager
  def (self)old_method
 blah
  end
end

module BattleManager
  def (self)old_method
 overwrite
  end

  def (self)new_method
  new method thing
  end
end

 

By this, if you need to overwrite an existing method, just use the same method name as usual, if you need to add new ones, add new as usual, and also you can alias a module method, create variables inside that can be read.

 

This is probably a noob question, but I always thought module methods were done like:

def self.someMethod

 

Not with parentheses. Or has this changed?

 

Aps no :P, I put the self in parentheses because they are optional and it will depend in the use that you give to the method, for example:

 

1) Use Self, when you will call the methods from the module itself:

 

module MyModule
def self.method_1
   do something
 end
end

 

And we call it like:

 

MyModule.method_1

 

Also, when we call these methods within the module like:

 

module MyModule
def self.method_1
   do something
 end

def self.method_2
   xxx = method_1
   xxxx.do something
end

-----

 

We don't use the SELF, when the method will be used in an external class that has been obtained inheritance from that module (mixin), for example:

 

module MyModule
def method_1
   do something
 end
end

class MyClass
include MyModule

  def some_class_method
  method_1
 end
end

-----

Well, at least those are the reasons I know when to use the self or not, it's like transforming a module into a class to use the methods within with no problems.

Edited by Mephistox

Share this post


Link to post
Share on other sites

You don't need to create a new module name, you add new methods to that module just adding it like:

 

By this, if you need to overwrite an existing method, just use the same method name as usual, if you need to add new ones, add new as usual, and also you can alias a module method, create variables inside that can be read.

 

I don't want to touch the existing module at all.

Just like how with subclassing where you inherit from parent classes, I want to do the same with modules.

 

Actually I don't really know why they decided to use a module for BattleManager. If they used a class then I could quickly treat it as an abstract class and extend it with as many custom Battle managers as I want, but it seems like more work is needed simply because it's a module.

 

Btw I'm implementing this idea. The battle windows and scenes are easy enough to work with because I can subclass and modify what I need, but I can't think of a way to deal with the module.

 

Each battle system will define their own custom BattleManager which may modify existing methods. If you're just using one BattleManager it's not very flexible.

Edited by Tsukihime

Share this post


Link to post
Share on other sites

LOL

Due to all methods from the BattleManager be of the singleton class, you can import then.

 

But you can try this hack, this is an simple example, uses basic conceps of meta programming:


module Module1

def self.lol(num)

num * num

end

end

 

module Module2

class << self

alias :alias_original_method_missing :method_missing

def method_missing(meth, *args)

if Module1.singleton_methods.include?(meth)

Module1.send(meth, *args)

else

alias_original_method_missing(meth, *args)

end

end

end

end

 

p Module2.lol(10)

p Module2.bump(10)

Share this post


Link to post
Share on other sites
you can import then.

 

Is the snippet you wrote for importing? Or is there another way to import?

Share this post


Link to post
Share on other sites


class Module

def singleton_extend(s_class)

@singleton_extensions ||= []

@singleton_extensions << s_class

@singleton_extensions.uniq!

@singleton_extensions.compact!

nil

end

alias :alias_original_method_missing :method_missing

def method_missing(meth, *args)

@singleton_extensions.each do |mod|

if mod.singleton_methods.include?(meth)

return mod.send(meth, *args)

else

begin

return alias_original_method_missing(meth, *args)

rescue => error

raise error, error.message, caller(2)

end

end

end

end

end

 

module Module1

def self.lol(num)

num * num

end

end

 

module Module2

singleton_extend Module1

end

 

p Module2.lol(10)

p Module2.bump(10)

 

This is really better, an abstraction to extends a module with the singleton class of other module LOL

 

 

Sorry, I mean "you cant"

Edited by Cidiomar

Share this post


Link to post
Share on other sites

lol why did they even write it as a module.

It's not like it's being included anywhere.

 

Maybe I should just turn it into a class or something.

Edited by Tsukihime

Share this post


Link to post
Share on other sites

You can do it like this as well:

class << BattleManager

Basicially this means that you can add new methods to BattleManager as well as changing the "self" methods without needing to type def self.method_name.

Of course, you should always aliasing the methods you want to change/override.

Share this post


Link to post
Share on other sites

You can do it like this as well:

class << BattleManager

Basicially this means that you can add new methods to BattleManager as well as changing the "self" methods without needing to type def self.method_name.

Of course, you should always aliasing the methods you want to change/override.

 

Is that the same effect as

 

class Parent

 def initialize(number)
    @number = number
 end

 def parent_method
    ...
 end
end

class Child << Parent

 def child_method
    return @number
 end
end

 

?

 

Cause I want to have multiple battle managers but I don't want to write them as completely separate modules.

Edited by Tsukihime

Share this post


Link to post
Share on other sites

Can I include modules with only self methods in other classes and somehow call those methods? lol

Edited by Tsukihime

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
Top ArrowTop Arrow Highlighted