[webkit-dev] Adding new JS bindings, having "slight" problems

[Nebojša Ćirić]

This API is going to be a separate standard related to EcmaScript, say
something like a library - so implementers of EcmaScript core standard
wouldn't be obligated to implement it. Dual track also enables both groups
to move at their pace and not block each other.
We are also trying to reuse much of ICU functionality for Chromium/Safari
implementation, and I am not sure V8/JSC has dependency on ICU at all, while
WebKit/Chromium do.
Also Darin Fisher hinted we should probably do it in bindings/v8, but maybe
he didn't have enough info at the time.

On Wed, Oct 27, 2010 at 6:20 PM, Adam Barth <abarth at webkit.org> wrote:

> If this is part of ECMAScript, it should be in the JavaScript engine
> proper, not in WebCore.   With respect to missing features of the IDL
> compiler, we add features to the IDL compiler as we need them.
> There's lots of stuff in WebIDL that we haven't needed to implement
> yet.
>
> Adam
>
>
> On Wed, Oct 27, 2010 at 5:35 PM, Nebojša Ćirić <cira at chromium.org> wrote:
> > Hi,
> >  I am working on JavaScript API that implements basic i18n operations,
> like
> > formatting numbers, dates, sorting... We are actually working with
> > EcmaScript committee on standardizing the API.
> >  My goal is to have a prototype to showcase for the next meeting (mid
> > November) and I am making local changes in my chromium checkout (but
> working
> > on WebKit part of the code).
> >  I started with the simplest part, Locale definition and came up with
> simple
> > (not complete) idl for it. What I did:
> > 1. Added new top level WebCore/i18n directory (we can debate that later)
> > 2. Added JSLocale.idl, JSLocale.h and JSLocale.cpp files to it
> > 3. Updated WebCore.gypi and WebCore.gyp files so proper project is
> generated
> > for XCode.
> >
> > module core {
> >
> >     // Construct with browser locale or with user specified one.
> >
> >     interface [Constructor] JSLocale {
> >
> >         readonly attribute DOMString language;
> >
> >         readonly attribute DOMString script;
> >
> >         readonly attribute DOMString region;
> >
> >         readonly attribute DOMString variants;
> >
> >         void availableLocales(out ObjectArray locales);
> >
> >         void maximizedLocale(out JSLocale locale);
> >
> >         void minimizedLocale(out JSLocale locale);
> >
> >     };
> >
> > }
> >
> > Everything (chromium) compiles properly.
> >  I hit couple problems with this:
> > 1. I can't name my new files/interface Locale.{idl, cpp, h} since Mac and
> > Windows have case insensitive file names, and compiler trips on system
> > header locale.h. I am using JSLocale for that reason, but I would like to
> > hear if somebody has a solution for this.
> > 2. What is a proper way to specify a constructor? I've browsed the code
> and
> > it seems nobody uses constructors, or they specify custom ones. I would
> like
> > to be able to do:
> > var loc = new Locale();
> > or
> > var loc = new Locale("en");
> > Specifying interface [Constructor, Constructor(in DOMString locale)]
> > JSLocale doesn't work (script errors). This should work according to the
> > WebIDL spec.
> > 3. I would like some of my functions to be static and some prototypes.
> > WebIDL says that prototype is default for methods. I've heard we added
> > support for static methods recently.
> > 4. How would one decide what parameter goes into static PassRef<JSLocale>
> > create() method? Some put Frame* some put ScriptContent and other random
> > parameters - and this doesn't seem to be idl related.
> >
> > I would like to contribute on improving documentation related to the
> > bindings, once I actually succeed using them :).
> >
> > Regards,
> >   Nebojša Ćirić
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>



-- 
Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101028/9eb0a637/attachment.html>