#gnome-hackers discussion about http://stackoverflow.com/questions/25149386/what-if-ginterface-methods-signatures-dont-match-with-the-virtualtable-struct

gistfile1.txt

00:43 <knocte> any gobject expert kind enough to answer this? http://stackoverflow.com/questions/25149386/what-if-ginterface-methods-signatures-dont-match-with-the-virtualtable-struct thanks :)
00:46 -!- giselle [~giselle@88-117-74-214.adsl.highway.telekom.at] has quit [Ping timeout: 600 seconds]
00:46 -!- cfoch [~cfoch@190.236.214.177] has joined #gnome-hackers
00:48 <ebassi> knocte: you're never supposed to call the function pointer directly; in this particular case, the cancellable argument is pushed on a stack of cancellables, so it's not needed in the arguments of the vfunc
00:48 <ebassi> the API is a bit unfortunate
00:49 -!- pecisk [~peteris@78.84.232.97] has quit [Ex-Chat]
00:49 <ebassi> honestly don't know why the cancellable wasn't included in the vfunc; probably need to ask danw
00:50 <knocte> so maybe it's actually something that should be fixed in gio, therefore, signatures of vfuncs should always match?
00:50 <ebassi> it cannot be fixed without breaking API
00:50 <ebassi> or ABI
00:50 <knocte> yikes
00:50 <ebassi> but, in general, there's no actual convention
00:51 <ebassi> you're supposed to implement the vfunc; callers will always go through the actual function, which may or may not take different arguments
00:51 <knocte> if there was a convention, I think these things would be easier to bind :)
00:51 <ebassi> is this because vala has issues?
00:51 <ebassi> and specific expectations
00:52 <knocte> not issues, I was just trying to improve the API that gtk-sharp exposes
00:53 <knocte> so when overriding the vfunc, that method overriden is private, right?
00:53 <ebassi> yes
00:53 <ebassi> the public counterpart is always the method on the actual interface
00:53 <knocte> mmm
00:55 <knocte> most OO languages (C# for example) have way different approach to interface inheritance (if some interface Foo has a Baz method, and you override it, then that Baz method is public; otherwise you couldn't have overriden it in the first place)
00:55 <knocte> that's why it's tricky to bind...
00:56 <ebassi> yeah, the interface in gobject does not match to the c# notion of interface in various ways
00:57 <ebassi> this case is bizarre, tho; read_nonblocking() stacks the cancellable then, by default, calls read_fn on an input stream, which takes a cancellable
00:57 <ebassi> it would have been easier to have a cancellable argument and passing it along, instead of stacking it
00:57 <ebassi> the code has been submitted in the current way, but I honestly don't understand why danw wrote it in such a way
00:58 <ebassi> we could add a new vfunc/func couple, and deprecate those, but it wouldn't solve the problem at hand
00:58 <knocte> I see
00:58 <knocte> well, doing that at least would make it easier to bind
00:59 <ebassi> anyway, if having matching vfunc/wrappers makes it easier to bind in c#, we could just document it that way
00:59 <knocte> sounds good
00:59 <knocte> should I open a bug about this?
01:00 <ebassi> knocte: yup; product glib, component documentation
01:00 <knocte> will do, thanks
01:00 <ebassi> tho I have no idea where to fix this in our API ref
01:00 <ebassi> desrt may have an idea
01:00 <knocte> k