After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 540661 - GLib.MemoryInputStream.from_data() returns InputStream
GLib.MemoryInputStream.from_data() returns InputStream
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings
0.3.x
Other All
: Normal minor
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-28 18:59 UTC by Stef Walter
Modified: 2008-07-09 09:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
possible idea of how to fix (4.41 KB, patch)
2008-06-29 03:21 UTC, Jared Moore
rejected Details | Review
use cast to prevent warning in C code (490 bytes, patch)
2008-06-30 07:20 UTC, Jared Moore
rejected Details | Review

Description Stef Walter 2008-06-28 18:59:04 UTC
The underlying C function g_memory_input_stream_new_from_data returns a GInputStream. However the bindings assume that it returns GMemoryInputStream causing warnings when building:

/* 
 * valac --pkg gio-2.0 test.vala
 */

using GLib;

public class Test : GLib.Object {
	public static void on_destroy(void *data) {
		// Needed to allow compilation
	}
	public static void main(string[] args) {
		MemoryInputStream input = new MemoryInputStream.from_data ("test", 4, on_destroy);
	}
}
Comment 1 Jared Moore 2008-06-29 03:21:08 UTC
Created attachment 113591 [details] [review]
possible idea of how to fix

Problem is that the constructors return different types than the classes that they are supposed to construct.

Solution - for methods that are "constructor" in the .gi, but the return type is different from the enclosing object, vapigen should make that method a static factory method rather than a constructor.

Attached is a basic idea of one way to fix this. There is probably a better way to check that the types are the same that doesn't rely on getting the class' cname, but I'm not sufficiently familiar with the type/symbol code.

Note that this change to Vapigen would probably require regeneration of more than just the gio bindings.
Comment 2 Jürg Billeter 2008-06-29 10:15:34 UTC
Thanks for the patch, however, I don't think this is the right way to fix this. Semantically, it's a normal constructor. The only reason it returns a base class is to make it more convenient to use in C.

I have an experimental patch in a local branch to support this:

    [CCode (type = "GInputStream*")]
    public MemoryInputStream () {
        ...
    }

The same applies to Gtk Widgets.
Comment 3 Jared Moore 2008-06-30 03:12:53 UTC
You're right, doing it the way I suggest is stupid. 

Since the real problem is just the warning in the C compilation, why not just treat it as a normal constructor, and then just put a cast in the C code? e.g.

GMemoryInputStream* _tmp0 = (GMemoryInputStream*) g_memory_input_stream_new_from_data (blah);

Since we know for sure that the constructor will definitely return the type that we want.
Comment 4 Jared Moore 2008-06-30 07:20:06 UTC
Created attachment 113671 [details] [review]
use cast to prevent warning in C code
Comment 5 Raffaele Sandrini 2008-07-09 09:18:36 UTC
Fixed in SVN trunk revision 1688.

2008-07-09  Raffaele Sandrini  <raffaele@sandrini.ch>

	* gobject/valaccodegenerator.vala:
	* gobject/valaccodemethodbinding.vala:
	* vala/valacreationmethod.vala:
	* vala/valainterfacewriter.vala:
	* vapigen/valagidlparser.vala:

	Add support for creation methods with a different (mostly super) type
	than the type of the object it creates. Add a `type' parameter to the
	CCode attribute which will be used to get the casts right for such
	creation methods.

	* vapi/gio-2.0.vapi:
	* vapi/gtk+-2.0.vapi:

	Regenerated, fixes bug 540661