~ubuntu-branches/ubuntu/utopic/ruby-gir-ffi/utopic-proposed

« back to all changes in this revision

Viewing changes to DESIGN.md

  • Committer: Package Import Robot
  • Author(s): TANIGUCHI Takaki
  • Date: 2014-06-22 16:13:36 UTC
  • mfrom: (10.1.1 sid)
  • Revision ID: package-import@ubuntu.com-20140622161336-zo88bzrlqw71cpyy
Tags: 0.7.4-1
* Imported Upstream version 0.7.4
* Bump Standards-Version to 3.9.5 (with no changes)

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
# Design of Gir-FFI
 
2
 
 
3
## Basic Idea
 
4
 
 
5
Gir-FFI uses FFI to read information from the GObject Introspection
 
6
Repository. Based on that it creates bindings for the information read.
 
7
 
 
8
## Class and method creation
 
9
 
 
10
GirFFI::Builder creates classes and modules at runtime and adds appropriate
 
11
method_missing methods to them to generate methods and perhaps other
 
12
classes when required.
 
13
 
 
14
The following options were discarded, at least for now.
 
15
 
 
16
* Create classes and all of their methods at runtime. This would be very
 
17
  similar to the method chosen, but would concentrate all the overhead at
 
18
  start-up, some of which would be used for creating methods that will
 
19
  never get called.
 
20
 
 
21
* Allow offline creation of ruby source generated from the GIR. This is
 
22
  still in interesting idea, but off-line source code generation is not
 
23
  really the Ruby way.
 
24
 
 
25
## Method Naming
 
26
 
 
27
Probably, get_x/set_x pairs should become x and x= to be more Ruby-like.
 
28
This should be done either by defining them as such directly, or by
 
29
aliasing. Blindly going by the name leads to weird results thoough, like
 
30
having x, x= and x_full= as a set. Also, some get_ or set_ methods take
 
31
extra arguments. These probably shouldn't become accessors either.
 
32
 
 
33
Boolean-valued methods could get a ? at the end.
 
34
 
 
35
This requires a lot more thought. For now, the full method names as
 
36
defined in the GIR are used.
 
37
 
 
38
## Ruby-GNOME Compatibility
 
39
 
 
40
Full Ruby-GNOME compatibility cannot be achieved automatically, since its
 
41
object hierarchy differs from that of standard GObject: It puts Object in
 
42
the GLib namespace, and defines signal_connect and friends as methods of
 
43
GLib::Instantiable; In standard GObject they are functions.
 
44
 
 
45
Possibly, compatibility enhancing code can be added for these specific
 
46
exceptions.
 
47
 
 
48
## Reference Counting
 
49
 
 
50
Because we can always make sure GObjects are unref'd when the Ruby object
 
51
is GC'd, the mechanism of floating references actually gets in the way a
 
52
bit. Therefore, when floating GObjects are constructed, GirFFI will sink
 
53
them. All GObjects can then safely be unref'd using a Ruby finalizer.
 
54
GObjects obtained through other mechanisms than with a constructor will be
 
55
ref'd once when wrapping them in a ruby object.
 
56
 
 
57
## Bootstrapping Class Design
 
58
 
 
59
The interface to the GObject Introspection Repository itself is also
 
60
introspectable. The interface is specified in terms of structs and
 
61
functions rather than objects and methods. For now, the hard-coded Ruby
 
62
bindings for this don't follow the introspected specification: Gir-FFI
 
63
cannot bootstrap itself.
 
64
 
 
65
## Object initialization
 
66
 
 
67
An attempt at making Thing.new less hacky.
 
68
 
 
69
Goals:
 
70
 
 
71
* No aliasing of Ruby's new. Overriding is possible with super being called.
 
72
* #initialize should behave as expected. We may enforce use of super in Ruby
 
73
  subclasses.
 
74
 
 
75
Schematic depiction of what happens (can happen):
 
76
 
 
77
```ruby
 
78
class GObject::Object
 
79
  def self.new *args
 
80
    # Stage A
 
81
    super(*other_args)
 
82
    # Stage C
 
83
  end
 
84
 
 
85
  def initialize *other_args
 
86
    # Stage B
 
87
  end
 
88
end