On 11/14/07 Sven Herzberg wrote:
I think it's not about the compiler doesn't barf. It was a design
decision to be able to always extend interfaces. The only thing GTK+
I guess this is a documentation issue, then, as this design decision
is not mentioned at all in the GObject documentation at
On Thu, 2007-11-15 at 11:28 +0100, Paolo Molaro wrote:
On 11/14/07 Sven Herzberg wrote:
I think it's not about the compiler doesn't barf. It was a design
decision to be able to always extend interfaces. The only thing GTK+
I guess this is a documentation issue, then, as this design
On Thu, 2007-11-15 at 01:16 +0100, Mathias Hasselmann wrote:
Wouldn't it possible to implement the GInterface as C++ class and add
an
operator like this to the GObject wrapper class:
public:
GLib::RefPtrGFooInterface operator () {
return GLib::wrap_interface (gobj ());
Kalle Vahlman wrote:
2007/11/14, Alp Toker [EMAIL PROTECTED]:
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main
deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by the binding. Of
course, if this is a more general problem, *then* it might be
approperiate to refrain from adding
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by the binding. Of
course, if this is a more general problem,
On Wed, 2007-11-14 at 12:02 +, Gustavo J. A. M. Carneiro wrote:
I guess that new vfuncs are usually tested for NULL before being
called.
Actually, I'd expect this for all vfuncs. In general, I'd expect the
interface to adapt to not having its new vfuncs implemented. C can
do
that.
On Qua, 2007-11-14 at 12:18 +0100, Murray Cumming wrote:
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by
On Wed, 2007-11-14 at 12:18 +0100, Murray Cumming wrote:
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;
is going to see random crashes when
On Wed, 2007-11-14 at 09:30 -0500, Morten Welinder wrote:
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
On Wed, 2007-11-14 at 14:00 +0100, Alexander Larsson wrote:
I guess that new vfuncs are usually tested for NULL before being called.
Actually, I'd expect this for all vfuncs. In general, I'd expect the
interface to adapt to not having its new vfuncs implemented. C can do
that.
That is
On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote:
In the case you describe GetCells is a pretty core part of the
interface, and its clearly hard to not have it do much. However, that
doesn't mean there are times when its useful. For instance, the default
implementation of the
Alp Toker wrote:
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly to C# interfaces was probably
wrong.
On Wed, November 14, 2007 11:11 am, Mike Kestner wrote:
On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote:
In the case you describe GetCells is a pretty core part of the
interface, and its clearly hard to not have it do much. However, that
doesn't mean there are times when its
Whyever would you do that? Such a struct would never be useful.
It is a simple use of an existing type in the API. I can create my own
instances of such a type, even if I cannot hand them off to anything
GObject related. I could store signal handlers there, for example.
Bottom line: a
On Wed, 2007-11-14 at 17:40 +0100, Murray Cumming wrote:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all members of a
On Wed, 2007-11-14 at 22:01 +0100, Alexander Larsson wrote:
I think this is similar to a problem we have in gtkmm. When a GTK+
widget implements an extra GInterface, we can't just add a base
class to
our existing C++ class, because that would break ABI in C++. So we
just
don't wrap it,
Am Mittwoch, den 14.11.2007, 17:40 +0100 schrieb Murray Cumming:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly to C# interfaces was probably
wrong.
This is totally missing
2007/11/14, Alp Toker [EMAIL PROTECTED]:
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main
deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly to C# interfaces
I have been working on the 2.12 bindings for Gtk# and have noticed a
stability issue for us related to GInterfaces. In Atk and Gtk, it seems
there is no restriction against adding methods to stable GInterfaces.
There have been numerous additions to the Atk interfaces while in
stable mode. A
On Wed, 2007-11-07 at 20:47 -0500, Matthias Clasen wrote:
On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote:
I have been working on the 2.12 bindings for Gtk# and have noticed a
stability issue for us related to GInterfaces. In Atk and Gtk, it seems
there is no restriction
On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote:
I have been working on the 2.12 bindings for Gtk# and have noticed a
stability issue for us related to GInterfaces. In Atk and Gtk, it seems
there is no restriction against adding methods to stable GInterfaces.
There have been
24 matches
Mail list logo
