Get Function name when prototyping
Laser Lips
When I wish to dynamically get the name of a function I can use
arguments.callee.toString() to work out the function name.
But when prototyping functions like in the following example, the
function name is emitted.
<script tyle='text/javascript'>
function hello()
{
alert(arguments.callee.toString());
}
hello();
function DCS(){}
DCS.prototype.hello=function()
{
alert(arguments.callee.toString());
}
var DCS=new DCS();
DCS.hello();
</script>
I guess this has been asked before but I can't find anything.
Thank you,
Graham Vincent
Laser Lips
prototyped function?
Thank you.
Graham
Jorge
javascript:alert((function f () {}).name);
--
Jorge.
John G Harris
wrote:
>Hi All,
>When I wish to dynamically get the name of a function I can use
>arguments.callee.toString() to work out the function name.
>
>But when prototyping functions like in the following example, the
>function name is emitted.
>
><script tyle='text/javascript'>
>function hello()
>{
> alert(arguments.callee.toString());
>}
>hello();
>
>function DCS(){}
>DCS.prototype.hello=function()
>{
> alert(arguments.callee.toString());
>}
>var DCS=new DCS();
>DCS.hello();
></script>
John
--
John Harris
Garrett Smith
> Hi All,
> When I wish to dynamically get the name of a function I can use
> arguments.callee.toString() to work out the function name.
>
> But when prototyping functions like in the following example, the
> function name is emitted.
>
There is a big difference between "omitted" and "emitted".
A FunctionExpression may have an optional identifier.
However in some engines, it fails. The engine in Safari <= 2 and JScript
have problems. Otherwise, we could write:-
function DCS() {}
DCS.prototype.hello = function hello() {
alert("hello");
};
- and it would work consistently in more than a few browsers. Safari 2
is dying out, but unfortunately, we have a lot of IE users to contend with.
> <script tyle='text/javascript'>
> function hello()
> {
> alert(arguments.callee.toString());
> }
> hello();
>
> function DCS(){}
> DCS.prototype.hello=function()
> {
> alert(arguments.callee.toString());
> }
> var DCS=new DCS();
> DCS.hello();
> </script>
>
If you want to use an identifier, use a function declaration in the same
scope. Don't use global scope, as that will create an irrelevant method
of the global object. Instead, try:-
var pkg = {};
(function() {
pkg.DCS = DCS;
function DCS() {
}
DCS.prototype = {
hello : hello,
type : 1
};
/** Instance Method */
function hello(){
alert("mmm " + this.type);
}
})();
new pkg.DCS().hello();
>
> I guess this has been asked before but I can't find anything.
The topic has been discussed a lot. Search for FunctionExpression and
FunctionDeclaration and FunctionStatement in the archives.
See also:
http://yura.thinkweb2.com/named-function-expressions/
> Thank you,
> Graham Vincent
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> A FunctionExpression may have an optional identifier.
>
> However in some engines, it fails. The engine in Safari <= 2 and JScript
> have problems. Otherwise, we could write:-
>
> function DCS() {}
> DCS.prototype.hello = function hello() {
> alert("hello");
> };
>
> - and it would work consistently in more than a few browsers. Safari 2
> is dying out, but unfortunately, we have a lot of IE users to contend with.
It does _not_ fail in JScript, but it works like an out-of-place (global?)
function declaration; after this statement, `hello' is available as a
reference to the function when it shouldn't be.
First time that I heard it failed in Safari 2.
> [...]
> The topic has been discussed a lot. Search for FunctionExpression and
> FunctionDeclaration and FunctionStatement in the archives.
And how named FunctionExpressions are really working in JScript has also
been discussed several times. You seem to have missed it.
> See also:
> http://yura.thinkweb2.com/named-function-expressions/
I haven't read that (maybe later), but if what you said above is any
indication, you should dump it.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Jorge
wrote:
> (...)
> It does _not_ fail in JScript, but it works like an out-of-place (global?)
> function declaration;
No, not global.
--
Jorge.
kangax
> Garrett Smith wrote:
>> A FunctionExpression may have an optional identifier.
>>
>> However in some engines, it fails. The engine in Safari <= 2 and JScript
>> have problems. Otherwise, we could write:-
>>
>> function DCS() {}
>> DCS.prototype.hello = function hello() {
>> alert("hello");
>> };
>>
>> - and it would work consistently in more than a few browsers. Safari 2
>> is dying out, but unfortunately, we have a lot of IE users to contend with.
>
> It does _not_ fail in JScript, but it works like an out-of-place (global?)
Identifier leaks into an enclosing scope, not global one. See example #1
<http://yura.thinkweb2.com/named-function-expressions/#jscript-bugs>
> function declaration; after this statement, `hello' is available as a
> reference to the function when it shouldn't be.
>
> First time that I heard it failed in Safari 2.
Just read an article. I described Safari 2 situation in details there.
<http://yura.thinkweb2.com/named-function-expressions/#safari-bug>
And no, it doesn't *always* "fail" in Safari; at least not in this
particular example that Garrett gave (`DCS.prototype.hello = function
hello(){ ... }`).
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> A FunctionExpression may have an optional identifier.
>>>
>>> However in some engines, it fails. The engine in Safari <= 2 and JScript
>>> have problems. Otherwise, we could write:-
>>>
>>> function DCS() {}
>>> DCS.prototype.hello = function hello() {
>>> alert("hello");
>>> };
>>>
>>> - and it would work consistently in more than a few browsers. Safari 2
>>> is dying out, but unfortunately, we have a lot of IE users to contend with.
>> It does _not_ fail in JScript, but it works like an out-of-place (global?)
>
> Identifier leaks into an enclosing scope, not global one. See example #1
> <http://yura.thinkweb2.com/named-function-expressions/#jscript-bugs>
Thanks.
>> function declaration; after this statement, `hello' is available as a
>> reference to the function when it shouldn't be.
>>
>> First time that I heard it failed in Safari 2.
>
> Just read an article. I described Safari 2 situation in details there.
>
> <http://yura.thinkweb2.com/named-function-expressions/#safari-bug>
>
> And no, it doesn't *always* "fail" in Safari; at least not in this
> particular example that Garrett gave (`DCS.prototype.hello = function
> hello(){ ... }`).
That's in fact the old (3.5.1) KJS bug I mentioned some time ago (also
documented in line 281 of current object.js 0.1.3.2006100822). Konqueror
uses KJS as script engine, as does WebKit. This bug has been fixed, see
<http://bugs.kde.org/show_bug.cgi?id=123529>.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
JR
wrote:
Hey, 'Kangax' is a Prototype.js core developer and he does know
Javascript a lot.
--
JR
Jorge
> (...)
> Konqueror uses KJS as script engine, as does WebKit.
LOL, that's not true. KHTML was forked into WebCore and KJS into
JavaScriptCore many years ago. Both evolved independently ever since...
until a day came in 2007 -after years of split- when KDE's team came
back wanting to undo the forking in order to benefit of Apple's now much
superior rendering engine and JS VM. If this has ever finally
materialised (which I don't think so), all that you could properly say
is that Konqueror now uses Apple's (webkit's) rendering engine and/or JS
VM, but of course not the other way around.
Because after so many years of evolution, any similarities that may
exist between KDE's KJS and Apple's NITRO are pure coincidence, ISTM.
--
Jorge
kangax
> kangax wrote:
[...]
>> <http://yura.thinkweb2.com/named-function-expressions/#safari-bug>
>>
>> And no, it doesn't *always* "fail" in Safari; at least not in this
>> particular example that Garrett gave (`DCS.prototype.hello = function
>> hello(){ ... }`).
>
> That's in fact the old (3.5.1) KJS bug I mentioned some time ago (also
> documented in line 281 of current object.js 0.1.3.2006100822). Konqueror
> uses KJS as script engine, as does WebKit. This bug has been fixed, see
> <http://bugs.kde.org/show_bug.cgi?id=123529>.
Actually, Konqueror bug looks like a subset of Safari one's, but I don't
think they are related. Safari fails with named fun. expr. in object
literals for a different reason. In Safari, named fun. expr. only
"works" when it is an /AssignmentExpression/, so something like -
`var o = { foo: function bar(){} }`
- will fail, while something like -
`var f; var o = { foo: (f = function bar(){}) }`
- will work.
--
kangax
David Mark
And yet, Prototype is still a lost cause. Go figure.
Thomas 'PointedEars' Lahn
I cannot test that particular case in KJS 3.5.1 because I don't have the old
Konqueror anymore. However, the connection between KJS and WebKit is most
obvious. RTSL.
Thomas 'PointedEars' Lahn
JFTR: It was a random signature.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Richard Cornford
> On Jul 5, 6:41 am, Thomas 'PointedEars' Lahn wrote:
<snip>
>> PointedEars
<snip>
>> Prototype.js was written by people who don't know javascript
>> for people who don't know javascript. People who don't know
>> javascript are not the best source of advice on designing
>> systems that use javascript.
>> -- Richard Cornford, cljs,
>
> Hey, 'Kangax' is a Prototype.js core developer and he
> does know Javascript a lot.
Prototype.js was written well before Kangax's involvement, and
the knowledge/understanding of the people currently working on
it says nothing about the knowledge/understanding of the people
who created it. Unfortunately the knowledge/understanding of the
people who created it, at the time they created it, has its legacy
in the design of Prototype.js. It was, after all, all the
knowledge/understanding available to inform the design decisions,
and so determined the overall architecture, the public API and
the strategies that would be taken towards addressing the issues
that its authors were aware of.
It is a problem that dogs almost all of the "big" libraries that
they were products of the first efforts at creating such a thing
made by their authors, and usually before those authors had a
good handle on the language they were using or the issues that
apply to browser scripting. Making novice mistakes while designing
javascript 'libraries' is not a bad thing in itself; if things
aren't tried out, and mistakes made (and recognised), then they
won't be learnt form. The problems start when the authors of these
things are sufficiently overconfident in their abilities that they
push them in front of an audience that is so far short of
even the library authors that they are desperate to adopt anything
that may make them look (in some sense) worthwhile to their
employers. With the widespread adoption of such a library comes a
'fixing' of its public API (and architecture, usage patters and
styles) and that is a 'fixing' of (the majority of) the thing that
was first designed/released. So to some degree it does not matter
how much the library's authors subsequently learn, or how many
more knowledgeable individuals may be recurred into the project.
Many of the initial design mistakes cannot ever be addressed
because totally abandoning back-compatibility will destroy a
library's reputation.
If you ask Kangax, 'given the time, resources and motivation;
designing a javascript/browser scripting library from the ground
up today, how much would the outcome resemble (especially the
original release of) Prototype.js?', and I bet that any response
would highlight significant fundamental design flaws in
Protoytpe.js. Some of which will never be addressable by any
amount of internal tinkering.
My experience suggests that when it comes to things like 'frameworks' it
is the individual's third effort that will be the first that will be
conceded 'good' in retrospect. The third because the mistakes of the
first will tend to be so bad as to prevent the anticipation of the
mistakes in the second.
I also observe that the people who have gone through that learning
process tend to work with systems/structures that are so different from
the novice's first efforts at creating a 'javascript library' that the
novice cannot even recognise them. Hence, the recurrent cries of "where
is your general purpose javascript library?".
Richard.