Hi everyone,
i am pretty new to javascript and this whole Ajax-thingie, but i''m
biting my way through.
Until now, i suppose. Wading through the scripts i found something
scriptacolous controls.js which is going to cost me my last mean rest
of sanity.
...
formClassName: ''inplaceeditor-form'',
highlightcolor: Ajax.InPlaceEditor.defaultHighlightColor,
highlightendcolor: "#FFFFFF",
externalControl: null,
submitOnBlur: false,
ajaxOptions: {},
evalScripts: false,
duration: 0.5
}, options || {});
...
What i really don''t get is the "options || {}" part.
I think i understodd, that the whole part of the script creates an
option object and extends it with another option object, which contains
the paramters given to the function by the user. Puh. Ok. but what does
"options || {}" mean? Is it a logical comparison?
I don''t know and after searching the web for hours, i don''t
know where
to go.
Any help?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
Hey Bastian, Bastian Flinspach a écrit :> What i really don''t get is the "options || {}" part. > I think i understodd, that the whole part of the script creates an > option object and extends it with another option object, which contains > the paramters given to the function by the user. Puh. Ok. but what does > "options || {}" mean? Is it a logical comparison?Nope. It''s a classical way of providing a default value if an argument is undefined (i.e., it was not explicitly provided by the caller). Since undefined bool-evals to false, the || operator will fallback to {}, which is basically an anonymous empty object in this context. It''s pretty pervasive in Prototype/s.a.us code, to allow for default values in arguments, especially "options" arguments, which are "hashes" of sorts (anonymous objects with properties defining any valuable set of specific options). ''HTH -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
This is a shortcut way to declare "if the options object was supplied to me, use it, but if it is null use an empty object because Object.extend() does expect something here" In javascript, if a variable is null it will evaluate as false in a boolean comparison such as the one you are struggling with, and if it is not null (its a valid object with some data in it) it will evaluate to true. So instead of writing an if statement, (if options is null extend with empty object else extend with options"... you can do this check inline. So to summarize... if options are passed in, it will use that, otherwise the empty object as the 2nd argument. I hope that helps :-) On 10/13/06, Bastian Flinspach <bastian.flinspach-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> > > Hi everyone, > > i am pretty new to javascript and this whole Ajax-thingie, but i''m > biting my way through. > Until now, i suppose. Wading through the scripts i found something > scriptacolous controls.js which is going to cost me my last mean rest > of sanity. > > ... > formClassName: ''inplaceeditor-form'', > highlightcolor: Ajax.InPlaceEditor.defaultHighlightColor, > highlightendcolor: "#FFFFFF", > externalControl: null, > submitOnBlur: false, > ajaxOptions: {}, > evalScripts: false, > duration: 0.5 > }, options || {}); > ... > > What i really don''t get is the "options || {}" part. > I think i understodd, that the whole part of the script creates an > option object and extends it with another option object, which contains > the paramters given to the function by the user. Puh. Ok. but what does > "options || {}" mean? Is it a logical comparison? > I don''t know and after searching the web for hours, i don''t know where > to go. > Any help? > > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-954-9798 x2903 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Thank you Guys!
That really saves my day! Although i must admit, i''m still a bit
confused about the subject. I always thought, a logical expression like
this would be evaluated and return true or false. Or is this bevause of
when the interpreter finds the first part to be true, it doesn''t bother
with the rest, so it won''t use the {}?
Ah, anyway, thanks for your help. My sanity is save for the moment and
i got something to puzzle out for the weekend.
best regards
Bastian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
You are correct in that if the first part of the statement is true, the rest
of the statement gets short-circuited (no need to check if the second part
of an OR is true if the first part is definately true). Javascript evaluates
the OR statement first, so if the null gets seen, it takes the second part
of the statement as the argument. I''m not sure about this (never tried
it),
but I would guess that if you had:
...
}, (options || {}) );
...
(notice the extra set of parentheses)
you would pass the VALUE true/false, since the expression would be
evaluated, and the result then would be passed into the function.
Can anyone confirm that for me?
-Jerod
On 10/13/06, Bastian Flinspach
<bastian.flinspach-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:>
>
> Thank you Guys!
>
> That really saves my day! Although i must admit, i''m still a bit
> confused about the subject. I always thought, a logical expression like
> this would be evaluated and return true or false. Or is this bevause of
> when the interpreter finds the first part to be true, it doesn''t
bother
> with the rest, so it won''t use the {}?
> Ah, anyway, thanks for your help. My sanity is save for the moment and
> i got something to puzzle out for the weekend.
>
> best regards
> Bastian
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
Ken Snyder wrote:> Is this "defaulting" behavior found in any other languages besides > JavaScript? I tried it in PHP; PHP seems to always return true or false;Perl does this. Not sure about other languages. -- Michael Peters Developer Plus Three, LP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
AFAIK, JS delays casting values to types until they are needed (for
example, a Boolean context for an if statement''s condition).
The || operator does not return a Boolean value; it returns the first
value if it would evaluate to true in a Boolean context -- otherwise
it returns the second value. These semantics ensure that you can use
|| in this way without breaking any of the assumptions you''d make
about Boolean values. So the extra set of parentheses doesn''t change
the value.
Note that all of the traditional Boolean OR semantics still apply if
you evaluate the resulting expression as Boolean:
{a: 3} || {} // ==> {a: 3} (would evaluate to true in Boolean context)
null || {} // ==> {} (would evaluate to true)
null || 0 // ==> 0 (would evaluate to false)
Someone who knows more about the JS type system can correct me on
some of the finer points.
If you use Firefox, you can grab FireBug (http://www.joehewitt.com/
software/firebug/) for an awesome JS console where you can play
around with expressions like these.
Brad
On Oct 13, 2006, at 11:06 AM, Jerod Venema wrote:
> You are correct in that if the first part of the statement is true,
> the rest of the statement gets short-circuited (no need to check if
> the second part of an OR is true if the first part is definately
> true). Javascript evaluates the OR statement first, so if the null
> gets seen, it takes the second part of the statement as the
> argument. I''m not sure about this (never tried it), but I would
> guess that if you had:
>
> ...
> }, (options || {}) );
> ...
> (notice the extra set of parentheses)
>
> you would pass the VALUE true/false, since the expression would be
> evaluated, and the result then would be passed into the function.
>
> Can anyone confirm that for me?
>
> -Jerod
>
> On 10/13/06, Bastian Flinspach
<bastian.flinspach-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org >
> wrote:
>
> Thank you Guys!
>
> That really saves my day! Although i must admit, i''m still a bit
> confused about the subject. I always thought, a logical expression
> like
> this would be evaluated and return true or false. Or is this
> bevause of
> when the interpreter finds the first part to be true, it doesn''t
> bother
> with the rest, so it won''t use the {}?
> Ah, anyway, thanks for your help. My sanity is save for the moment and
> i got something to puzzle out for the weekend.
>
> best regards
> Bastian
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs
-~----------~----~----~----~------~----~------~--~---
Is this "defaulting" behavior found in any other languages besides JavaScript? I tried it in PHP; PHP seems to always return true or false; --Ken Brad Ediger wrote:> ... > {a: 3} || {} // ==> {a: 3} > null || {} // ==> {} > null || 0 // ==> 0--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Ruby and Perl do this. IIRC, it started off as a Perl idiom. On Oct 13, 2006, at 11:58 AM, Ken Snyder wrote:> Is this "defaulting" behavior found in any other languages besides > JavaScript? I tried it in PHP; PHP seems to always return true or > false; > > --Ken > > > Brad Ediger wrote: >> ... >> {a: 3} || {} // ==> {a: 3} >> null || {} // ==> {} >> null || 0 // ==> 0 > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Is Perl older than javascript or (whatever it was initially called by Netscape, I always forget)? Interesting trivia... anyone know of like a global timeline of languages? ...wonder if wikipedia has one... On 10/13/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote:> > Ruby and Perl do this. IIRC, it started off as a Perl idiom. > > On Oct 13, 2006, at 11:58 AM, Ken Snyder wrote: > > Is this "defaulting" behavior found in any other languages besides > JavaScript? I tried it in PHP; PHP seems to always return true or false; > > --Ken > > > Brad Ediger wrote: > > ... {a: 3} || {} // ==> {a: 3} > null || {} // ==> {} > null || 0 // ==> 0 > > > > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-954-9798 x2903 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
According to Wikipedia, Perl was introduced in 1987; JS was first introduced into Netscape 2.0B3 in 1995. Not sure about that global timeline, though. On Oct 13, 2006, at 12:23 PM, Ryan Gahl wrote:> Is Perl older than javascript or (whatever it was initially called > by Netscape, I always forget)? Interesting trivia... anyone know of > like a global timeline of languages? ...wonder if wikipedia has one... > > On 10/13/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote: > Ruby and Perl do this. IIRC, it started off as a Perl idiom. > > On Oct 13, 2006, at 11:58 AM, Ken Snyder wrote: > >> Is this "defaulting" behavior found in any other languages besides >> JavaScript? I tried it in PHP; PHP seems to always return true or >> false; >> >> --Ken >> >> >> Brad Ediger wrote: >>> ... >>> {a: 3} || {} // ==> {a: 3} >>> null || {} // ==> {} >>> null || 0 // ==> 0 >> >> >> >> > > > > -- > Ryan Gahl > Application Development Consultant > Athena Group, Inc. > Inquire: 1-920-954-9798 x2903 > Blog: http://www.someElement.com > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
Actually, this has dates of introduction for each of the major languages: http://en.wikipedia.org/wiki/Comparison_of_programming_languages On Oct 13, 2006, at 12:35 PM, Brad Ediger wrote:> According to Wikipedia, Perl was introduced in 1987; JS was first > introduced into Netscape 2.0B3 in 1995. > > Not sure about that global timeline, though. > > > On Oct 13, 2006, at 12:23 PM, Ryan Gahl wrote: > >> Is Perl older than javascript or (whatever it was initially called >> by Netscape, I always forget)? Interesting trivia... anyone know >> of like a global timeline of languages? ...wonder if wikipedia has >> one... >> >> On 10/13/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote: >> Ruby and Perl do this. IIRC, it started off as a Perl idiom. >> >> On Oct 13, 2006, at 11:58 AM, Ken Snyder wrote: >> >>> Is this "defaulting" behavior found in any other languages >>> besides JavaScript? I tried it in PHP; PHP seems to always >>> return true or false; >>> >>> --Ken >>> >>> >>> Brad Ediger wrote: >>>> ... >>>> {a: 3} || {} // ==> {a: 3} >>>> null || {} // ==> {} >>>> null || 0 // ==> 0 >>> >>> >>> >>> >> >> >> >> -- >> Ryan Gahl >> Application Development Consultant >> Athena Group, Inc. >> Inquire: 1-920-954-9798 x2903 >> Blog: http://www.someElement.com >> >> >>--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
:-) Thanks, Brad! On 10/13/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote:> > Actually, this has dates of introduction for each of the major languages: > http://en.wikipedia.org/wiki/Comparison_of_programming_languages > > On Oct 13, 2006, at 12:35 PM, Brad Ediger wrote: > > According to Wikipedia, Perl was introduced in 1987; JS was first > introduced into Netscape 2.0B3 in 1995. > Not sure about that global timeline, though. > > > On Oct 13, 2006, at 12:23 PM, Ryan Gahl wrote: > > Is Perl older than javascript or (whatever it was initially called by > Netscape, I always forget)? Interesting trivia... anyone know of like a > global timeline of languages? ...wonder if wikipedia has one... > > On 10/13/06, Brad Ediger <brad-sod+mMc99o6+XT7JhA+gdA@public.gmane.org> wrote: > > > > Ruby and Perl do this. IIRC, it started off as a Perl idiom. > > > > On Oct 13, 2006, at 11:58 AM, Ken Snyder wrote: > > > > Is this "defaulting" behavior found in any other languages besides > > JavaScript? I tried it in PHP; PHP seems to always return true or false; > > > > --Ken > > > > > > Brad Ediger wrote: > > > > ... {a: 3} || {} // ==> {a: 3} > > null || {} // ==> {} > > null || 0 // ==> 0 > > > > > > > > > > > > > > > -- > Ryan Gahl > Application Development Consultant > Athena Group, Inc. > Inquire: 1-920-954-9798 x2903 > Blog: http://www.someElement.com > > > > >-- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---
* Brad Ediger wrote (13/10/06 17:42):> AFAIK, JS delays casting values to types until they are needed (for > example, a Boolean context for an if statement''s condition). > > The || operator does not return a Boolean value; it returns the first > value if it would evaluate to true in a Boolean context -- otherwise it > returns the second value. These semantics ensure that you can use || in > this way without breaking any of the assumptions you''d make about > Boolean values. So the extra set of parentheses doesn''t change the value. > > Note that all of the traditional Boolean OR semantics still apply if you > evaluate the resulting expression as Boolean: > > {a: 3} || {} // ==> {a: 3} (would evaluate to true in Boolean context) > null || {} // ==> {} (would evaluate to true) > null || 0 // ==> 0 (would evaluate to false) > > Someone who knows more about the JS type system can correct me on some > of the finer points.I don''t know more, but the spec is here: http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf Page 58 has the relevant info. In particular, it says this: NOTE The value produced by a && or || operator is not necessarily of type Boolean. The value produced will always be the value of one of the two operand expressions. If you don''t mind reading techy documentation, the spec is the best place to find out about this sort of thing. Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs -~----------~----~----~----~------~----~------~--~---