On Aug 25, 2008, at 4:57 PM, Peter Michaux wrote:
> There needs to be a way(s) to distinguish which variables have which
> lifetimes and visibilities.
We have ways already: explicit blocks containing let-declared
temporaries; your public to make things visible outside their lexical
scope.
Rules to be worked out, I am going fast here (don't slow me down ;-),
but I do not see the point in reinventing wheels or mixing them into
hybrids.
> The following is no good
>
> class Foo() {
BTW, no need for () after the class name -- a bit more sugar.
> var temp = 0;
> var priv = 1;
> var pub = 2;
> }
>
> It could be
>
> class Foo() {
> var temp = 0;
> private priv = 1;
> public pub = 2;
> }
>
> In the above example, "temp" will be garbage collected and there is no
> use in the private "priv" variable and it could be garbage collected
> too.
Why reinvent the wheel with "private"? Functions outside of classes
do not capture any such declared bindings.
class Foo {
var temp = makeBigObjectGraph();
var nontemp = computeSomeResult(temp);
var nontemp2 = computeAnotherResult(temp);
function private_method() {...}
public function public_method() {...}
}
This is bad. Without inventing more syntax, one way out is to write
class Foo {
var nontemp, nontemp2;
{
let temp = makeBigObjectGraph();
nontemp = computeSomeResult(temp);
nontemp2 = computeAnotherResult(temp);
}
function private_method() {...}
public function public_method() {...}
}
There are other ways around the unwanted entraining of the big object
graph. You could ask for a constructor function inside the class, as
AS3 and ES4 support. But it's still possible to entrain too much in
such a function, and you can't initialize the member vars directly in
their declarations (this combined with non-null types led to the
"settings" syntax in ES4).
So really, caveat hacker. Closures can hang onto too much memory if
you are not careful.
> The situation changes when a public method exists.
>
> class Foo() {
> var temp = 0;
> private priv = 1;
> public pub = function() temp + priv;
> }
>
> Now "temp" is captured in the closure of "pub" and so "temp" is
> effectively instance-private. So the "private" keyword isn't necessary
> at least in terms of lifetime as the following is the same.
>
> class Foo() {
> var temp = 0;
> var priv = 1;
> public pub = function() temp + priv;
> }
>
> This last example, no "private" keyword,
(Whew.)
> works if instance-private is
> desired. If class-private is desired (I hope not! as I explained
> before) then the second to last example above would be required. In
> which case "var" works like Ruby's "private" (instance-private),
> "private" works like Ruby's "protected" (class-private)
This reminds me of an idea from Dave Herman and Sam Tobin-Hochstadt
to add private syntax for generating Name objects bound to lexical
names (after define-local-member-name in PLT Scheme):
private var priv = 1;
Not exactly the same syntax as you sketched, but you could also
separate name generation from use:
private priv;
var priv = 1;
and make other uses in the same lexical scope of the (impossible to
forge as a string) Name object mapped to the 'priv' lexical name.
This could be used for class private, C++ "friend", and other such
use-cases.
> and "public" is like everyone's "public".
:-)
> So the issue may not be choosing between instance-private *or*
> class-private.
That's what I was getting at in an earlier message with the generated
Names for class, friend, etc. private.
> JavaScript will have instance-private thanks to
> closures. The question becomes is class-private also desirable, worth
> the extra keyword and complexity both to learn and to debug?
It's a good question.
> I think the ability to have two modules in one file means modules will
> need to name themselves. That is they will need to be declared with a
> name like
>
> module foo {
> // ...
> }
>
> or
>
> var foo = module {
> // ...
> };
>
> The importer could rename things but somehow the importer will have to
> use the name "foo" to at least start importing.
I will let Ibad^H^H^H^HIhab jump in here ;-).
> By cycles you mean module A using module B which uses module A? Late
> "linking" would required to allow cycles, correct?
Yes. Any early linking would mean no cycles allowed, leaving us with
second-class modules of the PLT Scheme kind (PLT Scheme has a first-
class module system too, called "Units", which does allow cycles). At
this point I should summon and defer to Dave Herman (who may be a bit
too busy to respond, but here's hoping).
> Also perhaps the
> "foo" variable may reference different module objects at different
> times.
The var foo could be rebound, but modules by default should have
higher integrity than that.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
