On Wed, Aug 8, 2012 at 1:58 PM, Luca Bruno <lethalma...@gmail.com> wrote: > On Wed, Aug 8, 2012 at 12:57 PM, Andrea Del Signore <seje...@gmail.com> > wrote: >> >> can you elaborate a little why the transform branch should be merged >> before? >> What's its purpose? >> >> Anyway we are talking about experimental stuff and we shouldn't be >> worried about compatibility and such, so why not include a simple >> patch like mine and after go for the full solution? > > > I don't think you're able to resurrect posix and dova with only that patch > plus a plugin, am I wrong?
Tecnically yes, we can do just that, but this isn't the real point: with that simple patch we can experiment we specialized backends of which Dova and Posix are just 2 examples. For "specialized backends" I mean a codegen suited for micros with just a few Kb of memory, where memory and processing power is the first constraint. As an example we can have a type system that isn't thread safe just because we will not ever have threads on the target cpu or because we don't have atomics operations available, nor an OS available etc... To be clear I'm not stating that vala should support this model, but that it can be interesting to develop something highly specialized and see how it come. I'm not even sure that vala is suited for this kind of development :) > The point behind the transform branch is to transform the code tree and not > write codegen backends. Thus plugins will be visitors that transform the > code tree, not that add new inconsistent codegen backends. This will fix the "airy" code that I see in the codegen for sure... meanwhile, since we are not committed to any api stability, we can just experiment with yet another inconsistent codegen backend don't you think? Ciao, Andrea _______________________________________________ vala-devel-list mailing list vala-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-devel-list