mvz / gir_ffi

Auto-generate bindings for GObject based libraries at run time using FFI

Home Page:https://github.com/mvz/gir_ffi/wiki

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot access/change initialize arguments in subclass

opened this issue · comments

I'm used from Ruby-GNOME2 to subclass GStreamer pipelines, but this doesn't really seem possible with GirFFI, at least not when changing the interface. See the following example:

require 'gir_ffi'

GirFFI.setup :Gst

Gst.init([])

pipe1 = Gst::Pipeline.new("pipeline1")
puts pipe1.get_name

class CustomPipeline < Gst::Pipeline

  def initialize(name)
    puts "Initializing with name #{name}"
    super(name)
  end

end

pipe2 = CustomPipeline.new("pipeline2")
puts pipe2.get_name

This gives as output:

pipeline1
ruby-gir-ffi-subclass-test.rb:12:in `initialize': wrong number of arguments (0 for 1) (ArgumentError)
    from /var/lib/gems/1.9.1/gems/gir_ffi-0.7.2/lib/gir_ffi/class_base.rb:84:in `new'
    from /var/lib/gems/1.9.1/gems/gir_ffi-0.7.2/lib/gir_ffi/class_base.rb:84:in `direct_wrap'
    from /var/lib/gems/1.9.1/gems/gir_ffi-0.7.2/lib/gir_ffi/object_base.rb:17:in `constructor_wrap'
    from /var/lib/gems/1.9.1/gems/gir_ffi-0.7.2/lib/ffi-gobject/initially_unowned.rb:8:in `constructor_wrap'
    from (eval):4:in `new'
    from ruby-gir-ffi-subclass-test.rb:19:in `<main>'

Here pipe1 works as expected, but for pipe2, it seems the argument is already consumed by GirFFI before it get to the subclassed initialize method. Is this a bug or shouldn't I be subclassing any classes generated by GirFFI?

Ruby version: ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
GirFFI version: 0.7.2

Technically, this is the intended behavior: You do not need to call super, and GirFFI will not pass arguments to subclass' initialize method. So, the following will work and print Initializing with []:

class CustomPipeline < Gst::Pipeline
  def initialize(*args)
    puts "Initializing with #{args}"
  end
end

I'm not too sure this is the desired behavior, though. I need to give this some thought.

The behavior has been changed in current master. See the documentation on subclassing for details.