Hi Smith,
if it's a util , it's better not to count on anthing , or at least only
Constant class only.
If in your case , app is kind of constant object , I could agree with you.
But at least it's more clear when you wrote a doSomething.call(app),
that means doSomething() need a "app" , that's the benefit I see.
If you are calling doSomething in other js file or other place , you might
lost where exist the app.
If what you want if apply it a shorter code, there's still a lot of ways to
do that.
var doSomething = function(){ return app.doSomething(); }; //won't it be
more clear ?
And for me again, if my concern is talking about shorter code ,
i will not use or writing anything that will have the long package struct
like "MyApp.utils.isWhoozit".
That's the reason why I don't like YUI/ dojo. (I think they are good , but I
don't like the styling.)
But still , the one most important thing is "doSomthing" is totally
different with "app.doSomething" ,
you change the behavior and only for a shorter code, it's not a best
practice for me.
That's the key point and I want to point it out again.
2011/3/23 Luke Smith <[email protected]>
>
> On Mar 23, 2011, at 8:33 AM, Tony Wang wrote:
>
> Hi Smith ,
>
> for my opinion , in your case
> var doSomething = app.doSomething;
> doSomething(); // boom if the 'this' references are left in tact.
>
>
> I think it's a fault for invoker, If I am developing with it ,
> I will not forget to use call or apply to the app when you are plan to do
> something like that.
>
> Like
> var doSomething = app.doSomething;
> doSomething.call(app);
>
>
> I don't see a benefit to this. Storing a function reference that must be
> call()ed from the host context is wasteful. app.doSomething() is less code.
>
>
> It's hard to design the function if you assume the invoker do KNOW NOTHING
> but they want to DO ANYTHING.
>
> And it do totally has different meaning for me between app.doSomething()
> and doSomething().
>
>
> My point is about 'this'. If there is one app object in the system,
> there's no benefit in using 'this'. 'this' should always be the same. So
> you can use 'this' for the sake of possibly creating another app object in
> the future (in which case, it should be a prototype), or you can use app and
> allow implementation code to use the methods via local vars.
>
> For example:
> if (MyApp.utils.isWhoozit( someObject )) { ... }
>
> vs
> var isWhoozit = MyApp.utils.isWhoozit;
>
> if (isWhoozit( someObject )) {
> }
>
> readability is not lost, and the code is shorter. There are tradeoffs,
> sure. If readability is impacted, the namespaced function can be referenced
> as though it required 'this'. That said, it's been my experience that
> methods on static objects do not benefit from 'this'.
>
> L
>
>
> Best Regards,
> Tony
>
> 2011/3/23 Luke Smith <[email protected]>
>
>>
>> On Mar 23, 2011, at 6:43 AM, Poetro wrote:
>>
>> 2011/3/23 pnbv <[email protected]>:
>>>
>>>> Considering a single instance object:
>>>> app = {
>>>> foo: 'afoo',
>>>> bar: 'abar',
>>>>
>>>> callbackLib: {
>>>> replyFoo: function () {
>>>> console.log(this.foo);
>>>> },
>>>> replyBar: function () {
>>>> console.log(app.bar);
>>>> }
>>>> },
>>>>
>>>> doSomeThing: function (){
>>>> this.callbackLib.replyFoo.call(this);
>>>> this.callbackLib.replyBar();
>>>> }
>>>> }
>>>>
>>>> app.doSomeThing();
>>>>
>>>> What would be the preferred way of doing this (if there really is a
>>>> need for nested objects:)?
>>>> Thanks,
>>>> pedro
>>>>
>>> If you just want to get rid of the reference to this, you could do:
>>>
>>> app = {
>>> foo: 'afoo',
>>> bar: 'abar',
>>>
>>> callbackLib: {
>>> replyFoo: function () {
>>> console.log(app.foo);
>>> },
>>> replyBar: function () {
>>> console.log(app.bar);
>>> }
>>> },
>>>
>>> doSomeThing: function (){
>>> app.callbackLib.replyFoo();
>>> app.callbackLib.replyBar();
>>> }
>>> }
>>> app.doSomeThing();
>>>
>>> Although this would trigger errors in the following case:
>>>
>>> bar = app;
>>> app = {};
>>> bar.doSomeThing();
>>>
>>> As app is now no more.
>>>
>>
>> There's a failure case either way.
>> var doSomething = app.doSomething;
>>
>> doSomething(); // boom if the 'this' references are left in tact.
>>
>> I find it preferable for non-instance collections of functions (i.e.
>> object literals with methods as shown) to reference the object rather than
>> 'this' as they are often utility functions or apply to the application as a
>> whole, and are therefore more useful as function refs that can be passed
>> around or assigned to shortcut vars. Shortcut vars can be compressed better
>> as well.
>>
>> Short form: use 'this' in prototype methods, the containing var name in
>> "static" methods. As with most things, this is a guide, not a rule.
>>
>>
>> L
>>
>> --
>>> Poetro
>>>
>>> --
>>> To view archived discussions from the original JSMentors Mailman list:
>>> http://www.mail-archive.com/[email protected]/
>>>
>>> To search via a non-Google archive, visit here:
>>> http://www.mail-archive.com/[email protected]/
>>>
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>>
>>
>> --
>> To view archived discussions from the original JSMentors Mailman list:
>> http://www.mail-archive.com/[email protected]/
>>
>> To search via a non-Google archive, visit here:
>> http://www.mail-archive.com/[email protected]/
>>
>> To unsubscribe from this group, send email to
>> [email protected]
>>
>
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
>
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
