Re: [Vala] Roadmap for extending Vala's reach

[Michael Gratton <mike vee net>]

Hey Guillaume,

I think this is a generally good idea - didn't vala already have some 
notion of profiles already though?

In particular I like getting rid of the implicit "using GLib" - explcit 
is always better. It's especially annoying given every single symbol 
from all of of GLib, GObject and GIO is crammed into that one namespace.

WRT --nostdpkg, I kind of wonder if it's a better idea to instead 
simply bump the major version number and drop backwards compat, so we 
know that existing projects will continue to compile fine with the old 
0.x series, at no additional development overhead cost. Once projects 
have migrated to having an explicit --pkg=glib-2.0 and "using GLib" 
then they can just cut over to 1.x of the compiler.

This would also be a good opportunity to split GLib, GObject and GIO up 
into separate namespaces, which would be more consistent with this 
suggested approach of using --pkg to enable compiler-specific features.

//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>


On Sun, May 7, 2017 at 5:26 AM, Guillaume Poirier-Morency 
<guillaumepoiriermorency gmail com> wrote:
> Hello all!
>
> We currently have a very promiscous relationship with GLib and I would
> like to propose some changes to make this more explicit.
>
> Each --pkg argument would consist of a VAPI and a compiler plugin 
> (from
> wip/transform) for generating specific code and extending the language
> syntax. One optional plugin per package seems sane to me.
>
> No --pkg arguments at all:
>
>  * basic Vala syntax
>  * basic C codegen
>  * standard C types (int, uint -> unsigned int, char, uchar, ...)
>  * no API
>
> At this point, one could introduce a different set of definitions for
> supporting, let's say, a micro-controller C standard library in just a
> matter of a --pkg flag.
>
> With --pkg=posix
>
>  * posix C API
>
> With --pkg=glib-2.0
>
>  * shadowed standard C types in GLib.* namespace, which would become 
> in
>    default with a 'using GLib;' declaration
>  * GLib C API
>  * support for basic introspection (--gir and the like)
>
> No more imlicit 'using GLib;'. However, including it would shadow all
> the numerical types and produce a nice GLib-friendly API.
>
> With --pkg=gobject-2.0
>
>  * GObject API
>  * typeof
>  * signals
>  * support for advanced introspection
>
> With --pkg=gio-2.0
>
>  * GIO API
>  * asynchronous primitives
>  * DBus code generator
>
> With --pkg=gtk-3.0
>
>  * GTK API
>  * [GtkBuilder] annotations
>
> We can have a pure Posix C backend and compile anything with:
>
>     valac --ccode --pkg=posix main.vala
>
>     public int main () {} => int main (void) {}
>
> Or if one would like to target Emscripten platform:
>
>     valac --ccode --pkg=emscripten main.vala
>
>     public int main () {} => #include<emscripten.h> int main (void) {}
>
> For usual GLib code:
>
>     valac --ccode --pkg=glib-2.0 main.vala
>
>     using GLib;
>
>     public int main () {} => gint main (void) {}
>
> It would be breaking stuff that is not explicitly using --pkg=glib-2.0
> and 'using GLib'. We could actually use the '--nostdpkg' switch to 
> sort
> of reset the compiler down to it's most basic feature set and wait
> until 1.0 to drop it and have some good defaults.
>
> At first, it would be to make --nostdpkg work flawlessly while
> preserving entire backward-compatibility. That'll be good for a minor
> release.
>
> Tell me what you think about this!
>
> --
> Guillaume Poirier-Morency <guillaumepoiriermorency gmail com>
>
> Étudiant au baccalauréat en informatique à l'Université de 
> Montréal
> Stagiaire de recherche à l'IRIC
>
> Mon blog: https://arteymix.github.io/
> Clé PGP: B1AD6EA5
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list