Re: [Gnash-dev] Static Members - Array

[strk]

I went finding this thread to report I just added
"Static Members" suppor for the Array class.
Doing the same for Date should be pretty easy following
implementation in array.cpp. 

--strk;

On Sun, Mar 12, 2006 at 10:32:57PM +0100, strk wrote:
> 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
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.