Namespaces, or getting function foo.bar() declarations to work

[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=functi on(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=functi on 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){b ody};

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,
--
am

laurus : rhodophyta : brezoneg : smalltalk : stargate

[António Marques]

Richard Cornford wrote:

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.

This assumption appears to be the crux of your issue, but
you have not explained or justified it. Most javascript
error reports output line numbers (at minimum) so I don't
see any need to have a name associated with the function
for debugging.

It's not an assumption, they really are anonymous. ...

That was not the assumption. The assumption was that using anonymous
functions would impact debugging. It is an assumption as anonymous
functions are common on non-trivial javascript and if their use really
was a problem when debugging that would have been noticed by now.

I said why it impacts debugging, if no one else is bothered by that is
another matter. For all I know, people are tearing their hair off for
the short supply of great javascript IDEs. I don't think it would hurt
that a name could be determined for every function (if not their own,
that of the variable they are assigned to, or that of the scope object).

function foo()
{
function bar()
{
debug('hello', 1, 'a')
}
}

And function debug would output something like

'10:04:55 [foo] hello, 1, a'

The 'hello' got into that output because you put it there, why not put
in the information that tells you what you need in the output, like
something that tells you the context of the debug call?

Only because it would have to be done every time. Given the dynamic
nature of javascript, it's even possible that 'bar' is bound to other
scope, so maybe something like

'10:04:55 [foo > bar] hello, 1, a'
'10:04:57 [dif > bar] hello, 1, a'

would be even more interesting. The next version of ECMAScript could
surely define some more meta- functionality for functions, something
that could be put to good use by IDEs.
--
am

laurus : rhodophyta : brezoneg : smalltalk : stargate

[Lasse Reichstein Nielsen]

António Marques <m.**@sapo.pt > writes:

Hey, this looks great! But will the final code behave just in the same
way as if it were defined with

var ns = {accumulator:[]};
ns.add = function add(n) { ... };
ns.sum = function add(n) { ... };

It should, yes. There are no other scopes involved.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

António Marques wrote:

RobG wrote:

It turns out that in IE6, if you do

function foo(){}; // with 'var foo' it won't work
This line should work with `var foo' as well, but the next line should
not work anyway.
function foo.ecks(args){ body};

the browser does create a member of foo, named ecks, which is then
your foo.ecks function.
It works only in IE6 this way because it uses a proprietary extension of
ECMAScript (or an implementation flaw). The FunctionDeclara tion production
requires the `function' keyword to be followed by whitespace, followed by
an _identifier_ (not by a property accessor in dot notation), followed by
the parameter list followed by the function body. Therefore, the standards
compliant way is

function foo() {}

or a FunctionExpress ion, where the identifier after the `function' keyword
is optional:

var foo = function() {};

And then:

foo.ecks = function(args){ /* body */ };

Because `foo' is always a reference to a Function object that can be
augmented, like any native object:

var foo = {}; // or `= new Object()'
foo.ecks = function(args){ /* body */ };

or

var foo = {
ecks: function(args){ /* body */ };
};
I may be missing something, but this seems great to me,
Even if written standards compliant, it has its drawbacks. One is that
you need another function object. Another one, that I have pointed out
recently, is that if you use the Function object as a constructor,
objects created with it will not inherit the ecks() method; you have to
augment the constructors prototype object to achieve that.
in absence of
alternatives (my preferred would be simply that internal named functions
were public).

Do you mean:

function foo(){
function bar(){}
}
bar(); // Error: bar is not defined.

( Actually foo.bar() )

foo.bar() in this context works only in JavaScript 1.5 due to a proprietary
extension of ECMAScript (or an implementation flaw). With the advent of
Gecko 1.8b2+ based UAs, like Firefox 1.5, that use JavaScript 1.6, it has
become not only a deprecated practice but also an obsolete one.
PointedEars

P.S.
Please don't remove attribution lines for quoted text that related to them.
--
A man who works with his hands is a laborer; a man who works with his
hands and his brain is a craftsman; but a man who works with his hands
and his brain and his heart is an artist.
-- Louis Nizer, lawyer (1902-1994)

[Thomas 'PointedEars' Lahn]

pe**********@gm ail.com wrote:

António Marques wrote:

you can have

foo.ecks(), foo.wye(), foo.zed()
Richard explained to me just yesterday that this is a bad idea because
JavaScript is not compiled but rather interpreted.

Probably you misunderstood, since JavaScript is (JIT-)compiled, then
interpreted. Compiled vs. interpreted language is not the issue, but
the moment of evaluation of identifiers is:
He wrote

"Simulated namespaces are a very questionable notion. In other language
the namespaces are resolved when the code is compiled. Javascript must
resolve those long property accessors each and every time they are
used."

PointedEars
--
This is Usenet. It is a discussion group, not a helpdesk. You post
something, we discuss it. If you have a question and that happens to get
answered in the course of the discussion, then great. If not, you can
have a full refund of your membership fees. -- Mark Parnell in alt.html

[António Marques]

Hi,

Thank you all for your help on this matter.
--
am

laurus : rhodophyta : brezoneg : smalltalk : stargate