Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

[Resolved] Ruby - Question about

I have a window class that inherits from Window_Selectable. Let it be Window_Mine.

So Window_Mine < Window_Selectable < Window_Base.

I wanted to know if there is a way to call the update method of the class Window_Base from inside the update method of Window_Mine without using "super", since I don't want the Window_Selectable update code to be executed and i want to jump to Window_Base. I was thinking to something like Window_Class::update... 
 
I have never tried this, but you could try...
Code:
class Window_Base
  def Window_Base.update
    update
  end
end

class Window_Mine < Window_Selectable
  def update
    Window_Base.update
    # your code
  end
end

Again, I have not tried this. If it doesn't work, let me know.
 

khmp

Sponsor

Ruby doesn't support multiple inheritance. So you can't have:

Code:
class Window_Mine < Window_Selectable < Window_Base

end

The best way to get the update code from Window_Base is to copy the code from Window_Base's update and paste it into your Window's update. However I don't know why you would inherit from Window_Selectable and not use super to get both updates. Calling super in your window's update will call Window_Selectable's update which will call Window_Base's update.

Good luck with it charlie.lee! :thumb:
 
SephirothSpawn":35g8emb9 said:
I have never tried this, but you could try...
Code:
class Window_Base
  def Window_Base.update
    update
  end
end

class Window_Mine < Window_Selectable
  def update
    Window_Base.update
    # your code
  end
end

Again, I have not tried this. If it doesn't work, let me know.

No. Stack level too deep on the third line.

@khmp
I don't need the code in Window_Selectable::update, it would mess-up everything. I could make a class that inherits directly from Window_Base and copy all the Window_Selectable methods but the ones i redefined (EDIT: this would be the more "correct" solution maybe), but if i just could skip the superclass in the "super" chain...
 
create an alias for the window_base update, and call it in the window_Mine update method.
Code:
class Window_base
    alias myupdate update   
end
class Window_Mine < Window_Selectable
   def update
      myupdate
   end
end


As  myupdate doesn't exist in Window mine, ruby will search in all the ancestor up to the Object Class to find the method.
So as it doesn't exist in window_selectable either, it'll try to call a method myupdate from Window_Base
and yoohoooo there is one!
 
trebor777":3ru3hqiz said:
create an alias for the window_base update, and call it in the window_Mine update method.
Code:
class Window_base
    alias myupdate update   
end
class Window_Mine < Window_Selectable
   def update
      myupdate
   end
end


As  myupdate doesn't exist in Window mine, ruby will search in all the ancestor up to the Object Class to find the method.
So as it doesn't exist in window_selectable either, it'll try to call a method myupdate from Window_Base
and yoohoooo there is one!

Very good idea! It works of course.

Let's see if SephirothSpawn has a solution that does not involve changes or addition to Window_Base.
 
What I am working on is an addon to the Module class. You'll be able to use it like this:
Code:
class A
  def blah
    p 1
  end
end

class B < A
  def blah
    p 2
  end
end

class C < B
  super_skip :blah, A
  def blah
    super
  end
end

object = C.new
object.blah

The super_skip method will allow you to go from one class, to an ancestor class without executing middle ancestor classes.

I have one little bug left in what I have done... Starting to annoy me a little frankly. I'll have it in a few minutes. Need a ten minute break.


EDIT: HAHA. Silly scope error. Ok, here's what I have done:
Code:
class Module
  def super_skip(method_name, tpc, script_name = 'modulemethodskip')
    method_name = method_name.id2name
    ancestors = self.ancestors
    unless ancestors.include?(tpc)
      p 'Un-defined Parents Class - ' + tpc.to_s
      return
    end
    index = 0
    target_index = ancestors.index(tpc)
    p ancestors, index, target_index
    loop do
      index += 1
      break if index >= target_index
      cname1 = ancestors[index].to_s
      cname2 = ancestors[index - 1].to_s
      aliasn = "seph_#{script_name}_#{cname1.downcase}_#{method_name}"
      string  = "class ::#{cname1};"
      string += "  alias_method :#{aliasn}, :#{method_name};"
      string += "  def #{method_name}(*args);"
      string += "    super(*args);"
      string += "    return if self.is_a?(#{ancestors[index - 1]});"
      string += "    self.#{aliasn}(*args);"
      string += "  end;"
      string += "end;"
      eval string
    end
  end
end

It's nothing super difficult. [/really bad joke]

It passes through the ancestor classes, aliasing the method until it gets to the class directly before the target parent class. In the new method, it uses the super call. It then returns if the object is the type of class that super_skip call came from. Otherwise, it calls the alias method.
 
I've looked all over and couldn't find anything like this at all in any Ruby documentation. Another thing to add to the MACL. Hehe.


@khmp: Yep. Class < Module < Object

Then there the Kernel module, which is included in class Object as well.
 
this is very curious... But why did charlie.lee need to get rid of "super"? I know he tried to call a method inherited from another class but I still don't get the idea behind this need.
 
Let's just look at my example:
Code:
class A
  def blah
    p 1
  end
end

class B < A
  def blah
    p 2
  end
end

class C < B
  super_skip :blah, A
  def blah
    super
  end
end

charlie.lee only wanted the "p 1" to execute, not the "p 2". That's all.
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top