Re: [Vala] R: Re: R: POSIX and Dova profiles

[Andrea Del Signore <sejerpz gmail com>]

On Fri, Aug 3, 2012 at 5:26 PM, Jürg Billeter <j bitron ch> wrote:

> On Fri, 2012-08-03 at 16:12 +0200, sejerpz tin it wrote:
> > But I think having classes and some more oop machinery will
> > be also useful in micros with very low resources (32-64Kb of memory),
> > where of course a full framework doesn't make any sense (nor a rich
> > string class etc...)
> >
> > > In my opinion, the continuation of the Dova experiment will be better
> > > suited for embedded hardware (where you can't or don't want to use
> > > GLib). It will support interfaces and it will allow embedding the
> needed
> > > bits of the runtime library into the executable without making the
> > > executable larger than necessary.
> >
> > I agree, but taking Dova as a reference I think that should be usable
> > with the bare minimum.
> >
> > For example why Uri, Node, ArrayList, List are member of the dova-base
> lib?
> > One hypothetical library should include just the minimum to implement
> > classes, interfaces and signal, leaving all the rest, and I mean also
> > rich string classes or other enanched datatypes, to the upper layers.
>
> Unused parts of the library will not have any impact on the size of the
> binary in the current plan.

How will this be achieved? Dead function elimination by the C compiler and
multiple static libraries like in Dova?


> > > The syntax won't be identical to Vala
> > > but as code typically cannot be reused between Vala/GObject and
> >
> > > Vala/POSIX either, I don't expect this to be a big issue.
> >
> > Will still
> > be a C based language? A lot of people are used to C in micro land ;)
>
> Are you referring to a C backend or to C-like syntax?

C-like syntax ;) , but I think that the C backend will remain right?


> > (On a side note I'm not sure that I like the result = blah of the dova
> > profile, it reminds me vb6 when you have to write funcion_name = blah,
> > and I think that return blah is still better and more clear)
>
> The current plan is to move back to return statements, although possibly
> with a caveat that the return will not be allowed to act as an arbitrary
> jump.

Cool, what will substitute the arbitrary jump then?


> Jürg

Thanks for the info.

Regards,
Andrea