Dimitry Golubovsky:
I just think that this is a problem separate (although related) from
the forward declarations that we started with, so let's discuss
#include's as well.
In fact, (maybe I didn't make myself clear) I am for keeping
#include's and therefore having all dependent idl files in a single
stream that compiler consumes just by using a standard preprocessor. I
was annoyed at #include's too at the very first sight (I worked on an
IDL to Haskell compiler back in 2007 and used it in my Haskell to
Javascript compilation project to produce proper type signatures for
DOM methods), but later I realized that they bring more benefits than
inconveniences. IDL files are basically alternative/abstracted syntax
of .h files, and the same principles (#include's and #if/#endif
guards) of handling them IMHO apply.
I don’t want to have to require IDL processors to implement a whole C
preprocessor.
For the import statement proposed: how is it better than #include*?
Well, only slightly. It would allow referencing a URL, to avoid hard
coding relative local filenames. It would also not need the #ifdef
guards.
Besides, one either has to hardcode paths to imported files**, and/or
to implement the same functionality that CPP already has (-I option
for path to include files). Plus, probably every IDL file existing
will have to be rewritten/patched.
There are not yet many existing Web IDL files.
So, to my belief, advantages of using #include's are (sorry if this is
too well known):
* File dependency tree is created automagically. gcc -M will create a
Makefile if needed
The author of the IDL fragment needs to be careful about including files
correctly at the appropriate place, and preventing files from being
included twice. That’s a disadvantage to me. An import statement would
just as easily allow dependency analysis. (You couldn’t use gcc -M
exactly, though, which I guess is your point.)
* Design of a compiler is simplified because it can just read
everything from stdin: CPP would take care of integration of the
dependent IDL files in a single stream.
I don’t want to rely on the CPP.
* Existing files rely upon using #include's, and also do not have
strict rules of sectioning (one file per module, or one per interface,
many modules in a single file are possible).
Most existing IDL files aren’t Web IDL files, though. My suggested
import statement wouldn’t have strict rules of sectioning either.
* All other advantages CPP gives (that is, macros/conditional
compilation)
To me, this seems like complexity that is out of scope for the IDL
language. I’d say that you’d be free to use the CPP to process IDL
files before handing them off to the IDL processor if you want, but that
CPP syntax shouldn’t be part of the IDL language itself.
May I ask you what are the advantages of not using #include's?
* Not having to make spec writers publish IDL fragments with hard coded
local filenames for dependencies.
* Not having to make spec writers be careful about multiple inclusions
by using #ifdef guards.
* Not requiring the use of an external program (the CPP), or making IDL
processor implementors interpret CPP directives.
You wrote on the list:
-
I don’t think it would be good to require a C preprocessor to get the
same kind of inclusion behavior for Web IDL. But I do think we need to
make sure that names resolve, so we need some kind of mechanism.
-
But why not?
If I am writing an IDL processor it may not be convenient to invoke an
external program to perform the CPP processing.
--
* E. g. a compiler might ignore #ifdef guards and treat #include's as
import statements, that is taking functionality of CPP on itself.
I would find it a bit strange, though, if Web IDL defined syntax that
looked like C preprocessor directives but which are to be handled like
import statements instead.
** You have URLs in your example; was this the goal to reference
directly to the W3C-stored files, and so would the compiler fetch them
from the Internet (thus requiring a working connection) every time an
IDL file is compiled?
I imagined that fetching them would be required only once (or no times
at all, if the IDL processor knew about certain common IDL URLs, and had
a cache of them).
I made a counter-proposal at the end of
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1376.html,
which removes import statements (and #includes) and instead relies on
some specification outside of the IDL fragments themselves to state what
the dependencies are.
--
Cameron McCormack ≝ http://mcc.id.au/
