Automatically generate most constructors

This CL generates factory provider classes for any interface with a [Constructor] or [NamedConstructor] extended attribute.

The factory provider is generated from a template, using the pattern of an IDL interface specific template for the exceptional cases and a general template for the other cases.  I used the special case to adjust the number of arguments in the JavaScript call - longer term I think we might want to be a bit more intelligent about default argument values.

This CL generates for frog and dummy, the others need to be added.  Once the others have been added we might see an opportunity for abstracting out some of the mechanism but I it might turn out they are all slightly different.


BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=4560

[sra1, 2012-02-23 07:08:06]

Hi Pavel, Anton

This is what I am thinking for the constructors.

Since many new interfaces have 'default' clause naming a factory provider class,
the factory provider classes must be defined.

For dummy, they also had to contain the correct factory constructor as dartc
checks that.

For native, I started making changes but stopped half way through when I
realized that an empty factory provider class is enough to get Dartium to
compile and pass existing test.
I stopped making changes since it was clear that you probably want to do
something similar to this CL, but I'm not sure why the static native methods are
in their own class - perhaps with templates it would be easier to move them to
the _XXXFactoryProvider classes.

[vsm, 2012-02-23 23:04:28]

LGTM

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
File client/dom/scripts/generator.py (right):

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
client/dom/scripts/generator.py:245: """Returns an OperationInfo object for the
constructor, or None if no COnstructor
nit: line wrap, COnstructor -> Constructor

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
client/dom/scripts/generator.py:255: args = GetArgs(func_value)  #
nit: extra # at eol

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/templates...
File
client/dom/templates/dom/frog/factoryprovider_HTMLOptionElement.darttemplate
(right):

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/templates...
client/dom/templates/dom/frog/factoryprovider_HTMLOptionElement.darttemplate:6:
factory HTMLOptionElement([String data = null, String value = null,
Can these arguments be pulled out of IDL?  Seems like all the info is there.

[sra1, 2012-02-24 00:35:05]

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
File client/dom/scripts/generator.py (right):

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
client/dom/scripts/generator.py:245: """Returns an OperationInfo object for the
constructor, or None if no COnstructor
On 2012/02/23 23:04:28, vsm wrote:
> nit: line wrap, COnstructor -> Constructor

Done.

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/scripts/g...
client/dom/scripts/generator.py:255: args = GetArgs(func_value)  #
On 2012/02/23 23:04:28, vsm wrote:
> nit: extra # at eol

Done.

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/templates...
File
client/dom/templates/dom/frog/factoryprovider_HTMLOptionElement.darttemplate
(right):

https://chromiumcodereview.appspot.com/9428050/diff/2029/client/dom/templates...
client/dom/templates/dom/frog/factoryprovider_HTMLOptionElement.darttemplate:6:
factory HTMLOptionElement([String data = null, String value = null,
On 2012/02/23 23:04:28, vsm wrote:
> Can these arguments be pulled out of IDL?  Seems like all the info is there.

It is slightly safer this way.
If the IDL changes the signature there is a chance the compiler will be
displeased with the mismatch.  If we just use a signature derived from the IDL,
the body would become silently incorrect.

[podivilov, 2012-02-24 12:16:29]

On 2012/02/23 07:08:06, sra1 wrote:
> Hi Pavel, Anton
> 
> This is what I am thinking for the constructors.
> 
> Since many new interfaces have 'default' clause naming a factory provider
class,
> the factory provider classes must be defined.
> 
> For dummy, they also had to contain the correct factory constructor as dartc
> checks that.
> 
> For native, I started making changes but stopped half way through when I
> realized that an empty factory provider class is enough to get Dartium to
> compile and pass existing test.
> I stopped making changes since it was clear that you probably want to do
> something similar to this CL, but I'm not sure why the static native methods
are
> in their own class - perhaps with templates it would be easier to move them to
> the _XXXFactoryProvider classes.

In Dartium we have two dom libs: dart:dom and dart:domimpl. Native callbacks
could be used in dart:domimpl only, but if we define _XXXFactoryProvider in
dart:domimpl, it would not be visible from dart:dom because it's private. That's
why we need this additional level of indirection.

I think it would be very nice to split frog dom into two tiers as well, and make
sure that Dartium uses exactly the same public dart:dom. I could take this, if
there is no objections.

[sra1, 2012-02-24 22:43:07]

On 2012/02/24 12:16:29, podivilov wrote:
> On 2012/02/23 07:08:06, sra1 wrote:
> > Hi Pavel, Anton
> > 
> > This is what I am thinking for the constructors.
> > 
> > Since many new interfaces have 'default' clause naming a factory provider
> class,
> > the factory provider classes must be defined.
> > 
> > For dummy, they also had to contain the correct factory constructor as dartc
> > checks that.
> > 
> > For native, I started making changes but stopped half way through when I
> > realized that an empty factory provider class is enough to get Dartium to
> > compile and pass existing test.
> > I stopped making changes since it was clear that you probably want to do
> > something similar to this CL, but I'm not sure why the static native methods
> are
> > in their own class - perhaps with templates it would be easier to move them
to
> > the _XXXFactoryProvider classes.
> 
> In Dartium we have two dom libs: dart:dom and dart:domimpl. Native callbacks
> could be used in dart:domimpl only, but if we define _XXXFactoryProvider in
> dart:domimpl, it would not be visible from dart:dom because it's private.
That's
> why we need this additional level of indirection.
> 
> I think it would be very nice to split frog dom into two tiers as well, and
make
> sure that Dartium uses exactly the same public dart:dom. I could take this, if
> there is no objections.

I don't want to split frog dart:dom at this time.
The timing is not right: we are still fixing things in the new frog dart:html
which has the same one-lib structure.
Lets revisit this after we switch to the new dart:html - splitting is not on our
critical path.

A disadvantage of splitting the lib is that the impl types are now public in the
impl lib
This has some bad side effects:
(1) Users can import the impl lib, which contains native classes which have many
strange restrictions with no checking.
(2) Lots of irrelevant classes show up at http://api.dartlang.org/index.html
(3) I want to avoid the extra call for the factory constructors that you have -
people can see the generated JS.