Re: libseed-list js extensions for native modules

["Alan Knowles" <alan akbkhome com>]

Did I miss something - this works perfectly..


GLib = imports.gi.GLib;

imports.sandbox.Context.prototype.eval_file = function(fn) { 
        var  script = {}; 
        print("load " + fn);
        GLib.file_get_contents(fn,script); 
        return this.eval(script.contents); 
};

c = new imports.sandbox.Context;
c.eval_file("test.js");

#output>>>
load test.js

** (seed:3644): CRITICAL **: Line 10 in /tmp/seedtest.js: GFileError Failed to open file 'test.js': No such file or directory

Regards
Alan



 --- On 29/Jun/2010, Jonatan Liljedahl wrote: 
> > This should be made to work - It's probably going to take a bit of
>  > working out how to support it...
> 
> I'm trying to understand how this works, am I right that native modules 
> create their classes with seed_create_class() (JSClassCreate()), while 
> the Gir importer sets up an object with a 'prototype' property "by hand"?
> 
>  From the JSC API docs:
> 
> "Standard JavaScript practice calls for storing function objects in 
> prototypes, so they can be shared. The default JSClass created by 
> JSClassCreate follows this idiom, instantiating objects with a shared, 
> automatically generating prototype containing the class's function 
> objects. The kJSClassAttributeNoAutomaticPrototype attribute specifies 
> that a JSClass should not automatically generate such a prototype."
> 
> So, the question is why the prototype is not writable and if it can be 
> made to be that. I tried this hackish function on the constructor but it 
> didn't work:
> 
> gboolean
> seed_make_extendable (JSContextRef ctx, JSObjectRef object)
> {
>    JSStringRef jname = JSStringCreateWithUTF8CString ("prototype");
>    JSValueRef exception = NULL;
>    JSValueRef proto = JSObjectGetPrototype(ctx, object);
>    if (proto)
>      {
>        JSObjectSetProperty (ctx, (JSObjectRef) object, jname, proto,
>        kJSPropertyAttributeDontEnum|kJSPropertyAttributeDontDelete,
> 			   &exception);
>      }
> 
>    JSStringRelease (jname);
>    return TRUE;
> }
> 
> Once JSClassCreate has made the prototype, it seems to be fixed and 
> read-only.
> 
> Perhaps one should create classes more "manually" like the Gir importer 
> does instead of using JSClassCreate()?
> 
> > Looking through the code, it's either we have to explicitly overlay
> > the prototype properties in the constructor, or we set the
> > parent_class of Context to a standard object..
> 
> parent_class can only be a JSClassRef, and it says it should be NULL for 
> the normal Object class, which I guess it should be. Seems like 
> JavaScriptCore has classic inherited OOP internally, and that 
> parent_class has nothing to do with prototype. (but that all objects has 
> Object as parent_class)
> 
> I'm not sure I understand what you mean by overlay the prototype 
> properties..
> 
> /Jonatan
> 
> > Regarsd Alan
> > 
> > --- On 21/Jun/2010, Jonatan Liljedahl wrote:
> >> Also, it should work to add methods to SomeClass.prototype in
> >> native modules. Currently it does not:
> >> 
> >> imports.sandbox.Context.prototype.eval_file = function(fn) { var
> >> script = {}; GLib.file_get_contents(fn,script); return
> >> this.eval(script.contents); };
> >> 
> >> c = new imports.sandbox.Context; c.eval_file(foobar);
> >> 
> >> TypeError Result of expression 'ctx.eval_file' [undefined] is not a
> >>  function.
> >> 
> >> It does work for GI modules, as seen in extensions/Gtk.js
> >> 
> >> /Jonatan
> >> 
> >> Jonatan Liljedahl wrote:
> >>> The gi_importer tries to import extensions/name.js by evaluating
> >>>  "imports.extensions.name". It would be nice if this also worked
> >>> for native modules, I imagine it to be quite common that you
> >>> write a module with core parts in C and some high-level stuff in
> >>> js.
> >>> 
> >>> The question is, how should this be handled regarding searchpaths
> >>> etc?
> >>> 
> >>> If your module is installed in /usr/local/lib/seed, then you
> >>> probably installed the extension js in
> >>> /usr/local/share/seed/extensions, and imports.extensions would be
> >>> the right thing.
> >>> 
> >>> But what happens if your module is installed somewhere else? It
> >>> should probably start with the same dir as the native module,
> >>> then go on with imports.searchPath, and if the file is found call
> >>>  seed_importer_handle_file() on it..
> >>> 
> >>> BTW, what happens if you have 'extensions' folder in more than
> >>> one search path? will extensions.foo search for 'foo' in all of
> >>> those or only the first match for 'extensions'? Just doing a
> >>> 'imports.extensions' will of course create only one dir_importer
> >>> for that folder, hiding possible 'extensions' folders later in
> >>> the searchpath. I don't know if this is a good thing...
> >>> 
> >>> /Jonatan _______________________________________________ 
> >>> libseed-list mailing list libseed-list gnome org 
> >>> http://mail.gnome.org/mailman/listinfo/libseed-list
> >> _______________________________________________ libseed-list
> >> mailing list libseed-list gnome org 
> >> http://mail.gnome.org/mailman/listinfo/libseed-list
> > 
> > _______________________________________________ libseed-list mailing
> > list libseed-list gnome org 
> > http://mail.gnome.org/mailman/listinfo/libseed-list