Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #7983 > unrolled thread

calling function within (function() {...})();

Back to article view | Back to comp.lang.javascript

Contents

  calling function within (function() {...})(); Andrew Poulos <ap_prog@hotmail.com> - 2011-11-04 23:18 +1100
    Re: calling function within (function() {...})(); Gregor Kofler <usenet@gregorkofler.com> - 2011-11-04 14:06 +0100
      Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-04 14:13 +0100
        Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 15:49 +0100
          Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-04 16:35 +0100
            Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 20:44 +0100
              Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-04 21:16 +0100
                Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 21:24 +0100
                  Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-04 21:46 +0100
                  Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-04 23:29 +0100
          Re: calling function within (function() {...})(); Scott Sauyet <scott.sauyet@gmail.com> - 2011-11-04 10:29 -0700
            Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-09 15:17 +0100
              Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-09 20:13 +0100
                Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-11 23:26 +0100
                  Re: calling function within (function() {...})(); Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2011-11-11 23:31 +0100
                    Re: calling function within (function() {...})(); Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-12 00:38 +0100

#7983 — calling function within (function() {...})();

If I have this

var x = (function(){
              return {
                a : function(){},
                b : function(){}
              };
           })();

how do I call 'b' from within 'a'? I thought that this

a : function(){ this.b(); },

should work but I get "TypeError: 'undefined' is not a function".

Andrew Poulos

[toc] | [next] | [standalone]

#7986

Am 2011-11-04 13:18, Andrew Poulos meinte:
> If I have this
> 
> var x = (function(){
>              return {
>                a : function(){},
>                b : function(){}
>              };
>           })();
> 
> how do I call 'b' from within 'a'? I thought that this
> 
> a : function(){ this.b(); },
> 
> should work but I get "TypeError: 'undefined' is not a function".

Works as expected.

var x = (function(){
  return {
    a : function(){this.b();},
    b : function(){window.alert("hooray!"); console.log(this); }
  };
})();

x.a();

// -> alert dialog
// Object { a=function(), b=function() }

HTH, Gregor


-- 
http://vxweb.net

[toc] | [prev] | [next] | [standalone]

#7987

Gregor Kofler <usenet@gregorkofler.com> writes:

> Am 2011-11-04 13:18, Andrew Poulos meinte:
>> If I have this
>> 
>> var x = (function(){
>>              return {
>>                a : function(){},
>>                b : function(){}
>>              };
>>           })();
>> 
>> how do I call 'b' from within 'a'?

x.b();

but I'd rather have something like

var x = (function () {
    function a() {
        b();
    }
    function b() {

    }
    return {
        a: a,
        b: b
    };
}());

And descriptive identifiers.

> I thought that this
>> 
>> a : function(){ this.b(); },
>> 
>> should work

It depends.

> Works as expected.
>
> var x = (function(){
>   return {
>     a : function(){this.b();},
>     b : function(){window.alert("hooray!"); console.log(this); }
>   };
> })();
>
> x.a();
>
> // -> alert dialog
> // Object { a=function(), b=function() }

window.setTimeout(x.a, 0);

-- 
λ

[toc] | [prev] | [next] | [standalone]

#7988

Eric Bednarz wrote:

> Gregor Kofler <usenet@gregorkofler.com> writes:
>> Am 2011-11-04 13:18, Andrew Poulos meinte:
>>> If I have this
>>> 
>>> var x = (function(){
>>>              return {
>>>                a : function(){},
>>>                b : function(){}
>>>              };
>>>           })();
>>> 
>>> how do I call 'b' from within 'a'?
> 
> x.b();
> 
> but I'd rather have something like
> 
> var x = (function () {
>     function a() {
>         b();
>     }
>     function b() {
> 
>     }
>     return {
>         a: a,
>         b: b
>     };
> }());

There is no inherent advantage in that.  In fact, it is slightly less 
efficient than the original code because the `a' and `b' identifiers need to 
be resolved first, and it requires more maintenance effort because one needs 
to need track the identifiers.

> And descriptive identifiers.

ACK

>> Works as expected.
>>
>> var x = (function(){
>>   return {
>>     a : function(){this.b();},
>>     b : function(){window.alert("hooray!"); console.log(this); }
>>   };
>> })();
>>
>> x.a();
>>
>> // -> alert dialog
>> // Object { a=function(), b=function() }
> 
> window.setTimeout(x.a, 0);

 window.setTimeout(function() { x.a(); }, 10);

The asynchronous call is unnecessary here, though.

 
PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#7990

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:
>
>> Gregor Kofler <usenet@gregorkofler.com> writes:
>>> Am 2011-11-04 13:18, Andrew Poulos meinte:

>>>> var x = (function(){
>>>>              return {
>>>>                a : function(){},
>>>>                b : function(){}
>>>>              };
>>>>           })();

>> var x = (function () {
>>     function a() {
>>         b();
>>     }
>>     function b() {
>> 
>>     }
>>     return {
>>         a: a,
>>         b: b
>>     };
>> }());
>
> There is no inherent advantage in that.  In fact, it is slightly less 
> efficient than the original code because the `a' and `b' identifiers need to 
> be resolved first,

If a, b[, n] are used a lot in a context where they need not be methods
of an object, it would seem futile (and – depending on the number of
calls – quite inefficient) to me to call them as methods of an object
nevertheless.

>> window.setTimeout(x.a, 0);
>
>  window.setTimeout(function() { x.a(); }, 10);

You don’t say (I suppose creating a superfluous function object is
justified by not resolving those pesky identifiers first :^)

> The asynchronous call is unnecessary here, though.

That’s the problem of all artificial example code. In the origignal
code, calling a function expression that does nothing but returning an
object was unnecessary, too.

-- 
λ

[toc] | [prev] | [next] | [standalone]

#8001

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>> Gregor Kofler <usenet@gregorkofler.com> writes:
>>>> Am 2011-11-04 13:18, Andrew Poulos meinte:
>>>>> var x = (function(){
>>>>>              return {
>>>>>                a : function(){},
>>>>>                b : function(){}
>>>>>              };
>>>>>           })();
>>> 
>>> var x = (function () {
>>>     function a() {
>>>         b();
>>>     }
>>>     function b() {
>>> 
>>>     }
>>>     return {
>>>         a: a,
>>>         b: b
>>>     };
>>> }());
>>
>> There is no inherent advantage in that.  In fact, it is slightly less
>> efficient than the original code because the `a' and `b' identifiers need
>> to be resolved first,
> 
> If a, b[, n] are used a lot in a context where they need not be methods
> of an object, it would seem futile (and – depending on the number of
> calls – quite inefficient) to me to call them as methods of an object
> nevertheless.

The sole purpose of this code is to return a reference to a newly created 
object and assign that reference to `x'.  By contrast to a simple Object 
literal, though, this pattern provides the possibility of "private 
properties" (local variables of the created execution context) that can only 
be accessed from the object's initial methods through the closure.

You have provided code that adds no inherent value to that but, in addition 
to the drawbacks already mentioned, in `b', which is called by the a() 
method of the object, `this' does not refer to that object.  I fail to see 
the logic in that.

You might also want to take note of the fact that at least one object is 
always involved when a function is called in an ECMAScript implementation.

>>> window.setTimeout(x.a, 0);
>>
>>  window.setTimeout(function() { x.a(); }, 10);
> 
> You don’t say (I suppose creating a superfluous function object is
> justified by not resolving those pesky identifiers first :^)

The Function instance is not superfluous.  If you do not use the function 
expression here, then only the reference to `x.a' will be called, which 
means that `x.a' will be called as a method of the object that `window' 
refers to, or if you will, the global object.  As a result, `this' in `x.a' 
would not refer to the same object as `x', but to the other object.  We have 
been over this ad nauseam.

>> The asynchronous call is unnecessary here, though.
> 
> That’s the problem of all artificial example code. In the origignal
> code, calling a function expression that does nothing but returning an
> object was unnecessary, too.

Your logic is flawed.  *You* have introduced the unnecessary asynchronous 
call for no good reason.


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> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#8008

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Eric Bednarz wrote:

>>>> window.setTimeout(x.a, 0);
>>>
>>>  window.setTimeout(function() { x.a(); }, 10);
>> 
>> You don’t say (I suppose creating a superfluous function object is
>> justified by not resolving those pesky identifiers first :^)
>
> The Function instance is not superfluous.  If you do not use the function 
> expression here, then only the reference to `x.a' will be called, which 
> means that `x.a' will be called as a method of the object that `window' 
> refers to, or if you will, the global object.  As a result, `this' in `x.a' 
> would not refer to the same object as `x', but to the other object.

That’s why I provided that example. I don’t know what makes you think
that you have to explain that (or what the ‘module pattern’ is) to me.

[toc] | [prev] | [next] | [standalone]

#8009

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Eric Bednarz wrote:
>>>>> window.setTimeout(x.a, 0);
>>>>  window.setTimeout(function() { x.a(); }, 10);
>>> You don’t say (I suppose creating a superfluous function object is
>>> justified by not resolving those pesky identifiers first :^)
>> The Function instance is not superfluous.  If you do not use the function
>> expression here, then only the reference to `x.a' will be called, which
>> means that `x.a' will be called as a method of the object that `window'
>> refers to, or if you will, the global object.  As a result, `this' in
>> `x.a' would not refer to the same object as `x', but to the other object.
> 
> That’s why I provided that example. I don’t know what makes you think
> that you have to explain that (or what the ‘module pattern’ is) to me.

Your example does not make any sense.  Why call a method of a user-defined 
object as a method of the window/global object?


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#8011

Thomas 'PointedEars' Lahn wrote:

> Eric Bednarz wrote:
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Eric Bednarz wrote:
>>>>>> window.setTimeout(x.a, 0);
>>>>>  window.setTimeout(function() { x.a(); }, 10);
>>>> You don’t say (I suppose creating a superfluous function object is
>>>> justified by not resolving those pesky identifiers first :^)
>>> The Function instance is not superfluous.  If you do not use the
>>> function expression here, then only the reference to `x.a' will be
>>> called, which means that `x.a' will be called as a method of the object
>>> that `window'
>>> refers to, or if you will, the global object.  As a result, `this' in
>>> `x.a' would not refer to the same object as `x', but to the other
>>> object.
>> 
>> That’s why I provided that example. I don’t know what makes you think
>> that you have to explain that (or what the ‘module pattern’ is) to me.
> 
> Your example does not make any sense.  Why call a method of a user-defined
> object as a method of the window/global object?

For that matter, why call it asynchronously on top of that?

-- 
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> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#8022

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Your example does not make any sense.

I can live with that.

> Why call a method of a user-defined 
> object as a method of the window/global object?

Sigh.

[toc] | [prev] | [next] | [standalone]

#7995

Thomas 'PointedEars' Lahn  wrote:
> Eric Bednarz wrote:
>> Gregor Kofler  wrote:
>>> Andrew Poulos wrote:
>>>> If I have this
>
>>>> var x = (function(){
>>>>              return {
>>>>                a : function(){},
>>>>                b : function(){}
>>>>              };
>>>>           })();
>
>>>> how do I call 'b' from within 'a'?
>
>> x.b();
>
>> but I'd rather have something like
>
>> var x = (function () {
>>     function a() {
>>         b();
>>     }
>>     function b() {
>
>>     }
>>     return {
>>         a: a,
>>         b: b
>>     };
>> }());
>
> There is no inherent advantage in that.  In fact, it is slightly less
> efficient than the original code because the `a' and `b' identifiers need to
> be resolved first, and it requires more maintenance effort because one needs
> to need track the identifiers.

There is an advantage of some sort of safety.  Follow either one of
those snippets by

    y = x;
    y.a(); // works correctly

    x = false;
    y.a(); // throws TypeError only in the first approach

In the original, this throws an error after x was redefined.  In
Eric's reformulation, it works as (presumably) intended.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#8170

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn  wrote:
>> Eric Bednarz wrote:
>>> Gregor Kofler  wrote:
>>>> Andrew Poulos wrote:
>>>>> If I have this
>>>>> 
>>>>> var x = (function(){
>>>>> return {
>>>>> a : function(){},
>>>>> b : function(){}
>>>>> };
>>>>> })();
>>>
>>>>> how do I call 'b' from within 'a'?
>>>
>>> x.b();
>>>
>>> but I'd rather have something like
>>> 
>>> var x = (function () {
>>> function a() {
>>> b();
>>> }
>>> function b() {
>>
>>> }
>>> return {
>>> a: a,
>>> b: b
>>> };
>>> }());
>>
>> There is no inherent advantage in that.  In fact, it is slightly less
>> efficient than the original code because the `a' and `b' identifiers need
>> to be resolved first, and it requires more maintenance effort because one
>> needs to need track the identifiers.
> 
> There is an advantage of some sort of safety.  Follow either one of
> those snippets by
> 
>     y = x;
>     y.a(); // works correctly
> 
>     x = false;
>     y.a(); // throws TypeError only in the first approach

Any potential safety gained this way only mitigates the unnecessary, 
potentially harmful dependency introduced by Eric with the closure (by 
contrast to the rather clean, original code).  It should be this.b(),
not x.b().


PointedEars
-- 
When all you know is jQuery, every problem looks $olvable.

[toc] | [prev] | [next] | [standalone]

#8177

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

[function declarations vs. methods in ‘private’ scope]

> Any potential safety gained this way only mitigates the unnecessary, 
> potentially harmful dependency introduced by Eric with the closure (by 
> contrast to the rather clean, original code).

The whole purpose of the clean, original code was to introduce closures
at some point. Well, either that, or there was a useless – albeit
refreshingly clean – function expression.

> It should be this.b(),
> not x.b().

It must be exhausting, having all those opinions. :-)

[toc] | [prev] | [next] | [standalone]

#8243

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> [function declarations vs. methods in ‘private’ scope]
>> Any potential safety gained this way only mitigates the unnecessary,
>> potentially harmful dependency introduced by Eric with the closure (by
>> contrast to the rather clean, original code).
> 
> The whole purpose of the clean, original code was to introduce closures
> at some point.

Apparently you have either not read or not understood the FAQ notes.  Yes, 
introducing a closure was the intent of the original code.  A useful one.  
*One*.

> Well, either that, or there was a useless – albeit refreshingly clean –
> function expression.

You are still missing the point.
 
>> It should be this.b(),
>> not x.b().
> 
> It must be exhausting, having all those opinions. :-)

Ignorance must be bliss.


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> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#8244

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ignorance must be bliss.

You are the expert :-)

[toc] | [prev] | [next] | [standalone]

#8246

Eric Bednarz wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ignorance must be bliss.
> 
> You are the expert :-)

For crying out loud, it is very obviously a Really Bad Idea to have an 
object have a inherent dependency on its creation context.  If you cannot 
see that, you are beyond help.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web