Ruby Forum Rails Spinoffs (closed, excessive spam) > static private and multi-inherit

/*author:csf178@gmail.com*/
function Class(Initalizer,SuperClasses)
{
  if(!SuperClasses)SuperClasses=[];
  var ret=function(){
    for(var i=0;i<SuperClasses.length;i++)
    {
      SuperClasses[i].call(this);
    }

    var $private={};
    var $public=this;
    var $static=ret;

    with($static){
      with($private){
        with($public){
          eval("("+Initalizer+").apply(this,arguments)");
        }
      }
    }
    return this;
  }

  ret.prototype=Initalizer.prototype;

  for(var p in
Initalizer.prototype)ret.prototype[p]=Initalizer.prototype[p];
  for(var p in Initalizer)ret[p]=Initalizer[p];
  for(var i=0;i<SuperClasses.length;i++)
  {
    for(var p in SuperClasses[i].prototype)
    {
      ret.prototype[p]=SuperClasses[i].prototype[p]
    }
  }
  return ret;
}

/*
function alert(s)
{
  WScript.echo(s);
}
*/

/***********************************************
Example$B!'(Bpublic static private
************************************************/

var test1=new Class(function(){

  //v1 is public
  $public.v1=1;

  //v2 is private
  $private.v2=2;

  //define public variable with this
  this.vv1=2;

  //public function member
  $public.show=function(){
    //visit public and private variable
    alert(v1);
    alert(v2);
  }
  $public.set_static=function(v){
    $static.v3=v;
  }
});

var obj=new test1();

//visit public variable
alert(obj.v1);
alert(obj.vv1);

//try to visit private variable
alert(obj.v2);

//call public member function
obj.show();

//set static variable
obj.set_static(10);
//visit static variable from class
alert(test1.v3);

/***********************************************
Example:multi-inherit
************************************************/
var parent=function(){this.v4=6};
parent.prototype.v5=1000;

var test2=new Class(function(){
  $public.show2=function(){
    alert(this.v1);
    alert(v4);
    alert(v5);
  }
},[test1,parent]);

var obj=new test2();
obj.show2();

>                 with($static){
>                         with($private){
>                                 with($public){
>                                         eval("("+Initalizer+").apply(this,arguments)");
>                                 }
>                         }
>                 }
>                 return this;
>         }

Wonderful... : )

>                 with($static){
>                         with($private){
>                                 with($public){
>                                         eval("("+Initalizer+").apply(this,arguments)");
>                                 }
>                         }
>                 }

I think I just heard Crockford explode.

-- T.J. ;-)

Actually, Firebug does something similar (double or triple "with"
wrapping, I'm guessing to have proper precedence), but "eval" seems
unnecessary here.

- kangax

"eval" is necessary and it will not cost as much as you think.

Hi,

It's certainly an interesting approach. :-)  Some observations:

1. It works; kudos.  It's a bit like a dog riding a bicycle, but
still...

2. You'd have to document like *crazy* the fact that the code passed
to the Class function *isn't* evaluated in the apparent lexical scope,
but rather in the really very special lexical scope created within the
Class function.  (Well, actually, it's evaluated in both, but the
second is the one that will get used.)  Users failing to appreciate
the subtleties related to that would tend to run into difficult-to-
track-down bugs, particularly related to closures.  And *they'd* have
to document it like crazy in their own code, as well, so anyone
picking it up is forewarned.  Maintenance nightmares loom.

3. Debugging would tend to be fairly difficult, what with the class
and all of its member functions being within the eval, not (again)
actually where they appear to be.  I expect over time that JavaScript
debuggers will handle debugging eval'd code more and more elegantly
(certainly there is effort being made there), but for the moment...

4. The code for classes defined in this way is evaluated twice, once
in the course of the main script being evaluated, and then again when
Class is called.  Given that page load times are king, this isn't
ideal although I'm sure it happens fairly quickly.

5. Regarding this:

>         ret.prototype=Initalizer.prototype;
>
>         for(var p in
> Initalizer.prototype)ret.prototype[p]=Initalizer.prototype[p];

Given the assignment in the first line, what is the purpose of the
loop following it?  Genuine question, not a dig -- am I missing a
subtlety?  Seems likely I am.

6. Style point:  You declare 'p' at least three times, which various
lint tools may complain about although it's allowed by the ECMA spec.
(It Really Shouldn't Be, but it is.)

Thanks for the post -- it's interesting.  Very much about tradeoffs,
cost/benefit.  For me, most of the time, I think the cost would tend
to be too high, but it's still an interesting approach to the old
problem.
--
T.J. Crowder
tj / crowder software / com

Thank you for reading it so carefully.
I'm not good at English but I will try my best to describe it clearly.

1. It's a bit like a dog riding a bicycle.
I completely agree with you.
But don't you think it is a bit like "Class.create" in prototype?
I will never use it in my program myself.
It is just "a interesting code" for me.
I prefer to use functional programming(Later I may show you a
interesting implement of currying) or the following:
function class1()
{
    class2.call(this)//inherit
    class3.call(this)//multi-inherit
    this.v1=1;//public
    var v2=2;//private
}
class1.prototype.v3//do not use


2.It is used to create js class like class in java or c#
So member functions can only visit global variables no matter where
Initalizer is defined.

3.Eval cost much and is not friendly to debugger but it is the only
way to point [[scope]] to a normal object in scope chain.

4.I think we can ignore the cost in main script.
But in fact it is even worse, the code for classes defined in this way
is evaluated more than twice.
It is evaluated every time when creating a object from the class.


5. Sorry,I forget to delete "ret.prototype=Initalizer.prototype;"

6.I don't think it is a bad style.In fact I like it very much......
:-)

Hi,

(Your English seems very good indeed, FWIW.)

On #2:  Accessing members or globals aren't the only things people
might do with initializers.  Hence the comment about closures.

On #6:  Well, it's your call, as I say the spec does allow repeated
var declarations, although (again) if you use any lint tools, there's
a warning you're going to have to disable. :-)  But probably best not
to have style discussions here (or indeed at all, really, I shouldn't
have brought it up).
--
T.J. Crowder
tj / crowder software / com

Thanks. :-)

On #2
I'm trying to make it closer to Java or C# than JavaScript.
So I think "Initalizer" should be considered as a class instead of a
function.

On #6
JavaScript is really a interesting language.