A
António Marques
Hi!
I don't think I've ever been here, so I assume I'm addressing a bunch of
nice people. Can you help me? I don't think there's a solution, but who
knows.
The thing is, picture a large project where you want some encapsulation.
But a lot of it being grouping of what would otherwise be static members
of the global namespace. So that instead of
fooEcks(), fooWye, fooZed()
you can have
foo.ecks(), foo.wye(), foo.zed()
with foo being a global variable.
Now this is perfectly possible, that I know, by declaring
var foo={} OR function foo(){}
and then having
foo.ecks=function(args){body}
or then by defining them inline, as in
var foo={ecks: function(args){body}}
However, in all of these, the functions created are anonymous. This may
make no difference, but I don't like it and it impacts debugging, when
you're trying to determine their name.
You can given them a name, as in
foo.ecks=function ecks(args){body}
But this is error prone, since you have to keep the two names in sync,
and that is a sure road to damnation.
It turns out that in IE6, if you do
function foo(){}; // with 'var foo' it won't work
function foo.ecks(args){body};
the browser does create a member of foo, named ecks, which is then your
foo.ecks function. I may be missing something, but this seems great to
me, in absence of alternatives (my preferred would be simply that
internal named functions were public).
But as it is, neither Opera nor Gecko accept this notation. And for the
life of me, I haven't been able to figure out any other way to define a
public static member (though instance members would have the same
problem) that isn't anonymous without referring its name twice. Needless
to say, something like
var foo={ecks: fooEcks};
function fooEcks(args){body};
isn't the solution because it keeps the repetition (though this time it
could be automated to avoid errors - but notice that then we're going
far away from the natural constructs of the language), clutters the
global namespace anyhow, and probably creates all sorts of scope
problems (otherwise, we may just delete all of those references after
reassigning the functions to their namespace, but somehow this doesn't
look like a sensible solution).
So, any ideas? Thanks,
I don't think I've ever been here, so I assume I'm addressing a bunch of
nice people. Can you help me? I don't think there's a solution, but who
knows.
The thing is, picture a large project where you want some encapsulation.
But a lot of it being grouping of what would otherwise be static members
of the global namespace. So that instead of
fooEcks(), fooWye, fooZed()
you can have
foo.ecks(), foo.wye(), foo.zed()
with foo being a global variable.
Now this is perfectly possible, that I know, by declaring
var foo={} OR function foo(){}
and then having
foo.ecks=function(args){body}
or then by defining them inline, as in
var foo={ecks: function(args){body}}
However, in all of these, the functions created are anonymous. This may
make no difference, but I don't like it and it impacts debugging, when
you're trying to determine their name.
You can given them a name, as in
foo.ecks=function ecks(args){body}
But this is error prone, since you have to keep the two names in sync,
and that is a sure road to damnation.
It turns out that in IE6, if you do
function foo(){}; // with 'var foo' it won't work
function foo.ecks(args){body};
the browser does create a member of foo, named ecks, which is then your
foo.ecks function. I may be missing something, but this seems great to
me, in absence of alternatives (my preferred would be simply that
internal named functions were public).
But as it is, neither Opera nor Gecko accept this notation. And for the
life of me, I haven't been able to figure out any other way to define a
public static member (though instance members would have the same
problem) that isn't anonymous without referring its name twice. Needless
to say, something like
var foo={ecks: fooEcks};
function fooEcks(args){body};
isn't the solution because it keeps the repetition (though this time it
could be automated to avoid errors - but notice that then we're going
far away from the natural constructs of the language), clutters the
global namespace anyhow, and probably creates all sorts of scope
problems (otherwise, we may just delete all of those references after
reassigning the functions to their namespace, but somehow this doesn't
look like a sensible solution).
So, any ideas? Thanks,