Re: [Vala] valac can read a typelib in place of a vapi binding
On 04/02/2011 07:21 AM, Jürg Billeter wrote: Hi Adam, ... 2. Is there a long-term plan to deprecate .vapi files in favor of type libraries? Can type libraries express everything that .vapi files can? GIR files (vala doesn't read typelibs, it reads the xml versions) cannot express everything that .vapi files can and probably never will. They are focused on GObject-based libraries while .vapi can also handle quite a few other libraries reasonably well. Aha - now I see this was my mistake. When I compiled with '--pkg PeasGtk-1.0', I thought Vala was reading /usr/lib/girepository-1.0/PeasGtk-1.0.typelib But actually it was reading this .gir file: /usr/share/gir-1.0/PeasGtk-1.0.gir The plan is to replace our .gi files (old gobject-introspection) by .gir files (new gobject-introspection) as soon as possible, while still shipping generated .vapi files. Good to know. adam ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] 'using' importing too many symbols
'using' seems problematic to me. I think we need finer control. For
example, this bit of code:
using Gee;
public void main() {
var queue = new Queue();
}
gives the build error: "`Queue' is an ambiguous reference between
`GLib.Queue' and `Gee.Queue'.
I want to resolve the ambiguity in my code -- either stop it importing
GLib.Queue, or tell it that when I say 'Queue' I mean "Gee.Queue".
Really 'using GLib' is equivalent to 'import GLib.*' in Java. This
invites problems with symbol clashes, especially as packages are
expanded with new classes -- something that built once might not build
later when the packages are upgraded.
Java's solution is to allow importing symbols one by one, e.g. 'import
GLib.Queue'. This means a lot more typing, but with support from the
IDE (e.g. Eclipse) it becomes very easy because you can ask the IDE to
fixup the imports. It can guess most of them, and where there is
ambiguity, it asks you to choose. The Vala compiler could perhaps do
a similar thing, suggesting import/using statements in the error
message.
Alternatively, someone posted about 'aliases'. Would this solve the
problem? I'm not sure it would, unless the alias overrides all other
matches and resolves the ambiguity: e.g. would 'using Queue =
Gee.Queue' solve my problem?
Jim
--
Jim Peters (_)/=\~/_(_) j...@uazu.net
(_) /=\ ~/_ (_)
Uazú (_)/=\~/_(_)http://
in Peru(_) /=\ ~/_ (_)uazu.net
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] valac can read a typelib in place of a vapi binding
Hi Adam, On Fri, 2011-04-01 at 13:07 -0700, Adam Dingle wrote: > I realized to my surprise today that valac (0.11.7) can read a GObject > introspection type library in place of a VAPI file! For example, I can > specify '--pkg PeasGtk-1.0' on the command line and valac will read > types from /usr/lib/girepository-1.0/PeasGtk-1.0.typelib, which lets me > use libpeas types even though there is no libpeas.vapi anywhere. > > 1. Is this documented somewhere? How long has this cool feature existed > without my knowing about it? :) It was added a long time ago. In the beginning there were lots of issues and it is still a work in progress. However, it is usable nowadays for certain libraries and more improvements are waiting in a branch. > 2. Is there a long-term plan to deprecate .vapi files in favor of type > libraries? Can type libraries express everything that .vapi files can? GIR files (vala doesn't read typelibs, it reads the xml versions) cannot express everything that .vapi files can and probably never will. They are focused on GObject-based libraries while .vapi can also handle quite a few other libraries reasonably well. The plan is to replace our .gi files (old gobject-introspection) by .gir files (new gobject-introspection) as soon as possible, while still shipping generated .vapi files. Jürg ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
