Re: [Gnash-dev] Static Members

[strk]

On Mon, Mar 13, 2006 at 01:38:14AM +0800, Michael Carlson wrote:
> Ah, this is really helpful, and although I need to digest some of the
> concepts you talked about a little further, I think that is the right
> idea for case 2 of the 2 original cases I gave. As far case 1 - say
> calling, for example, Date.UTC() - Do you have a solution for this?
> 
> The way I understand it, when gnash is asked to find "Date.UTC", it's
> going to get the Date object (which currently is an as_value of type
> function - the constructor for the Date object, which is defined in
> date_new in Date.cpp), and try to get a member of this object called
> "UTC" (which it won't be able to find, because the constructor is an
> as_value which is not derived from as_object and has no child
> members).

The 'Date' object should be threated as an as_object.
If 'Date' is currently a c_function (most likely) it should
be changed to an function_as_object instead.
This will expose as_object interface (function_as_object
derives from it).
One of the interface is get_member, this will be given "UTC".
UTC is seeked for (by as_object::get_member) in either
the local members list or in the inherited members (Date.__proto__
which is as_object::m_prototype).

If you want

        var a = new Date();
        a.UTC();

To work, then 'UTC' should be 'exported', which is:

        Date.prototype.UTC != undefined;

But you also want

        Date.UTC();

To be available.
These will likely be two entries in two different hashes:

        s_global['Date'].m_properties['UTC'] // the 'exported' one
        s_global['Date']['UTC']; // the 'local' one

Both version will likely point to the same as_value, being
the c_function, so that the following should evaulate to true:

        Date.prototype.UTC == Date.UTC


--strk;




> 
> - Mike
> 
> On 3/12/06, strk <address@hidden> wrote:
> > Hello Mike, nice to hear you're working on this.
> > I'm not sure I understand your questions, anyway they look
> > like something I worked on already for Function.cpp.
> >
> > Basically we need to model ActionScript inheritance as
> > a whole.
> >
> > I started with assumption from AS1, which are as follows:
> >
> >  1. Every function has a 'prototype' member which
> >     contains 'exported' (virtual, I'd say) members.
> >
> >  2. Every object has a __proto__ member pointing
> >     to it's constructor's 'prototype' member.
> >
> >  3. The 'prototype' member of a function has a 'constructor'
> >     element pointing to the function itself.
> >
> > Following this, I made as_object::get_member always look,
> > recuring, into the __proto__ element when a member is not
> > found locally.
> >
> > To make a simple example, consider the Object class.
> > In Gnash this is currently NOT a class, but somtething hard-coded.
> > It it has to be a class it would ba an as_function_object
> > member of the s_global (Actionscript's _global) object and
> > named 'Object'.
> >
> > When following actionscript code is found:
> >
> >         var a = new Object();
> >
> > The variable 'a' would be constructed by the s_global['Object']
> > as_function_object, which would be Object class' constructor.
> >
> > a['__proto__'] would then point to s_global['Object']['prototype']
> >
> > When calling a.toString() ( current handling being hard-coded)
> > Gnash should look at a['toString'], when not finding it (this
> > is already implented in as_object::get_member) it will look
> > into a['__proto__']['toString'] and will find it.
> > The found member would really be Object.toString().
> >
> > The code I used for Function is not surely the best one, but
> > works fine as far as I tested it.
> >
> > The point is to be able to do, in actionscript, something like
> > this:
> >
> >         var d = new Date();
> >         Date.prototype.sayHello = function() { trace("Hello"); }
> >         d.sayHello();
> >
> > This is *known* to be expected to work, and it is commonly used
> > with the MovieClip class, adding functions to the drawing API.
> >
> > I'm interested in discussing this further, and please let
> > me know if I completely missed your point :)
> >
> > --strk;
> >
> > On Sun, Mar 12, 2006 at 02:50:33AM +0800, Michael Carlson wrote:
> > > Hey Everyone,
> > >
> > > I'm going through and implementing some of the basic actionscript
> > > classes, and ran into a problem - I don't know how to create static
> > > members with the current code.
> > > The first idea to come to my head was
> > > to add static members to the constructor object itself (to cover case
> > > 1 below), as well as adding the member to each instance of the class
> > > when created (in the normal non-static way) using the constructor (to
> > > cover case 2 below).
> > >
> > > For reference, examples of the two basic cases (that I can think of)
> > > using Date's UTC function (which is static):
> > >
> > > case 1) Date.UTC(params);
> > > case 2) var x = new Date(); x.UTC(params);
> > >
> > > However, if the static member is a variable which is non-constant
> > > (which fortunately none I've encountered so far are - maybe none are -
> > > but can the user define a variable like this that is?), this would
> > > cause problems as each instance of the class would have its own
> > > separate version of the variable. Furthermore, at the moment the
> > > constructors are all created as an as_value (of type function), which
> > > seems to be unable to have arbitrarily named "members" like objects do
> > > anyways.
> > >
> > > Should we add a new as_value type of "constructor", which has the
> > > ability to hold named members like normal objects? Or should we make
> > > the constructor and the uninstantiated object definition separate
> > > entities in code, in which the static variables would exist in the
> > > uninstantiated object definition (this seems to solve all the problems
> > > I thought of, but it might be overkill and overcomplicate the code)?
> > >
> > > What is the proper solution here?
> > >
> > > - Mike
> > >
> > >
> > > _______________________________________________
> > > Gnash-dev mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/gnash-dev
> >
> > --
> > ----------------------------------------------------------------------
> > State-collected Geographic Data is public property !
> > Reject the INSPIRE directive.
> > Sign the petition: http://petition.publicgeodata.org
> >
> >
> > _______________________________________________
> > Gnash-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnash-dev
> >
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 
----------------------------------------------------------------------
State-collected Geographic Data is public property !
Reject the INSPIRE directive.
Sign the petition: http://petition.publicgeodata.org