inheriting statics

zwetan zwetan at gmail.com
Tue Jan 9 10:05:34 PST 2007


On 1/9/07, Peter Hall <peterjoel at gmail.com> wrote:
> Right. So to access a static method of a super-class, where you have
> shadowed it with another method, you must access it via the class
> name..
>
> I could see this leading to errors, since the override attribute would
> not be used in this context. The same errors could equally happen with
> the existing ES3 scoping rules.
>
> Is that an argument against inheriting?
>

yep :)

basically I see inheriting acting more at the instance scope
even if off course defined in the class scope

accessing member
  |_ instance scope
          |_ traits chain
               |_ prototype chain
                        |_ not found

to over simplify it

if you consider static as just slot added to an object,
the class Object

inheriting static
it would be like being able to inherit from a litteral object

var obj = {}
     obj.mystatic = "foobar";

class A extend obj
    {
    ...
    public function test():String
        {
        return mystatic;
        }
    ...
    }


after if your concern is mainly about API access,
so you could actually move thestatic without breaking anything
you can combine static and getter/setter :)

------------------------------------------------------------
package test
    {

    class A
        {

        //public access
        static function get mystatic():String
               {
               return __mystatic;
               }
        }

    }

//internal access
var __mystatic:String = "foobar";
------------------------------------------------------------

and the nif you wantto change the public access
you can just redirect to it



On 1/9/07, Peter Hall <peterjoel at gmail.com> wrote:
> Right. So to access a static method of a super-class, where you have
> shadowed it with another method, you must access it via the class
> name..
>
> I could see this leading to errors, since the override attribute would
> not be used in this context. The same errors could equally happen with
> the existing ES3 scoping rules.
>
> Is that an argument against inheriting?
>

yep :)


after if your concern is mainly about API access,
you already have it :)

about
> But it also would make refactoring easier if I could move a static
> property to a different superclass and not have to update all uses of
> it in subclasses.


------------------------------------------------------------
package test
    {

    class A
        {
        public static var mystatic:String = "foobar";

        }

    class B extend A
        {

        public function test():String
               {
               return mystatic;
               }
        }

    }
------------------------------------------------------------


if you change the superclass where is defined the static

------------------------------------------------------------
package test
    {

    class A
        {
        //removed
        //public static var mystatic:String = "foobar";

        }

    class C
        {
        public static var mystatic:String = "foobar";

        }

    class B extend C
        {

        public function test():String
               {
               return mystatic; //you don't need to change the access
               }
        }

    }
------------------------------------------------------------

also if you want you can also combine getter/setter in a static definition :)


class X
     {
     public static function get mystatic():String
           {
           //your real acces here that you can change anytime
           }
     }


zwetan



More information about the Es4-discuss mailing list