Re: [Vala] The external symbol/code writer nightmare
- From: Jürg Billeter <j bitron ch>
- To: Luca Bruno <lethalman88 gmail com>
- Cc: vala-devel-list gnome org
- Subject: Re: [Vala] The external symbol/code writer nightmare
- Date: Mon, 20 Dec 2010 20:39:50 +0100
On Sun, 2010-12-19 at 22:16 +0100, Luca Bruno wrote:
> So main questions:
> 1) Should vapigen do:
> 1a) Use PACKAGE initially then switch to SOURCE for codewriter, like it is
> now, and do not do the change above, but I feel everything a little
> incoherent
> 1b) Use SOURCE (but really from a Vala pov it's a package, only for vapigen
> is a SOURCE) and make vapigen set .external = true for all symbols
The main reason for the SOURCE and PACKAGE distinction is to
avoid/loosen some checks during semantic analysis for VAPI files as
there is sometimes not enough information available (e.g., overriding
methods). This is also necessary for vapigen, so I don't think 1b) is a
feasible solution.
In general, I'd like to reduce the amount of code where the behavior
between SOURCE and PACKAGE differs. It should rather be a last resort
condition - besides intentional differences in the parser.
> 2) Should add a bool extern; to symbols and make external { get { extern ||
> external_package } }, or keep it like this but then we need some clear
> policy about it.
I don't think we should change this. The `external` property has the
same semantic meaning as the `extern` modifier. In VAPI files `extern`
is implicit but that difference is only relevant during parsing, so we
should not complicate the Symbol class further by adding a separate
property for the `extern` modifier.
> 3) How codewriter should behave? What external stuff should be written? Does
> it make sense to write extern stuff?
extern/external symbols should be and are written by the code writer in
general - although it might not be relevant to many libraries. However,
symbols from VAPI files (external packages) are skipped as those symbols
are not part of the application/library that is being compiled.
> In other words, I don't know for sure the design of external & code writer,
> but I feel there's the need to clear things out. I especially dislike the fact
> that we tune SOURCE/PACKAGE/external to tweak code writer output, I don't
> see a clear type SOURCE/PACKAGE for vapigen usage because there's no
> absolute definition of those types.
Yes, switching to SOURCE for code writing in vapigen is not pretty. It
would probably be better to add a CodeWriter option to not skip symbols
from external packages. Always using SOURCE in vapigen is not possible
as explained above.
I hope this clarifies things a bit.
Jürg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]