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

[Daniel Espinosa <esodan gmail com>]

I agree to move Vala to a modular design.

Vala now should be splitted into:

a) Core
b) Plugin System

*CORE*

Code Parser and AST. This is the one we can push first to a 1.0 release.

*PLUGIN SYSTEM*

Any thing able to use AST, like code generators, documentation generation,
language server for Syntax Highlighting, Code Navigation, Code Completion
an so on.

Some plugins already exists, just need to define a Plugin API and implement
it with existing modules.

This will open to create any CogeGenerator plugin. The already present
CCode is a GObject oriented, maybe to be renamed to GLibCode and splited to
add a GObjectCode and GIOCode all C code generators. This will open
oportunity to create other like PoxisCode and any other one like Rust code.
As pointed out enable using --pkg switches.

Current C Code generator should mature at its own pace, in order to reach a
1.0 in the future.

I really would like to see any other creating plugins for Vala to add Code
generators and Language Servers.




2017-05-19 14:01 GMT-05:00 Guillaume Poirier-Morency <
guillaumepoiriermorency gmail com>:

> Le dimanche 07 mai 2017 à 14:05 +1000, Michael Gratton a écrit :
> > Hey Guillaume,
> >
> > I think this is a generally good idea - didn't vala already have
> > some
> > notion of profiles already though?
>
> The notion of profiles has been dropped for maintainability. What I'm
> proposing here is not profiles per-se, but more a modular design with a
> core Vala compiler.
>
> It will also be the basis for general compiler plugins once the libvala
> API will be stabilized.
>
> > 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.
>
> Same here, I always put "using GLib" to make things clearer.
>
> > 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.
>
> Personally, I think it would be more efficient to make thoses changes
> incrementally and release them continuously to get some solid feedback.
>
> I don't really want to have a pending wip/transform again for years and
> if we decide to make all those in the perspective of a 1.x, it will
> never release.
>
> Let's do what we can do now and make it usable with --nostdpkg and in a
> 1.x, we'll just drop explicit stuff.
>
> > 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.
>
> I'm not so sure about all this. These three already use the same C
> namespace 'g_', so it's already consistent to have them under the same
> Vala namespace.
>
> > //Mike
> --
> 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


-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)