new keyword => operator

master
Mike Gerwitz 2012-02-18 20:04:06 -05:00
parent 5f6919bfcb
commit fb1a4b8012
1 changed files with 13 additions and 13 deletions

View File

@ -154,7 +154,7 @@ Class.extend( "foo", {} );
\end{verbatim}
It is apparent that \code{"foo"} is not a function and therefore cannot be used
with the \keyword{new} keyword. Given that, consider line 31, which blindly
with the \operator{new} operator. Given that, consider line 31, which blindly
invokes \code{base()} without consideration for the very probable scenario that
the user mistakenly (due to their own unfamiliarity or a simple bug) provided us
with a non-constructor for \var{base}. The user would then be presented with a
@ -229,8 +229,8 @@ Now consider the instantiation of our class-like objects, as was demonstrated in
var inst = new Foo( "Name" );
\end{verbatim}
We can make our code even more concise by eliminating the \keyword{new} keyword
entirely, allowing us to create a new instance as such:
We can make our code even more concise by eliminating the \operator{new}
operator entirely, allowing us to create a new instance as such:
\begin{verbatim}
var inst = Foo( "Name" );
@ -244,13 +244,13 @@ allow us to jump immediately into calling a method on an object without dealing
with awkward precedence rules: \code{Foo( "Name" ).getName()} vs. \code{( new
Foo( "Name" ) ).getName()}. However, those reasons exit more to offer syntactic
sugar; they do little to persuade those who do want or not mind the
\keyword{new} keyword.
\operator{new} operator.
The stronger argument against the \keyword{new} keyword is what happens should
The stronger argument against the \operator{new} operator is what happens should
someone \emph{omit} it, which would not be at all uncommon since the keyword is
not required for the core ECMAScript constructors. Recall that \keyword{this},
from within the constructor, is bound to the new instance when invoked with the
\keyword{new} keyword. As such, we expect to be able to make assignments to
\operator{new} operator. As such, we expect to be able to make assignments to
properties of \keyword{this} from within the constructor without any problems.
What, then, happens if the constructor is invoked \emph{without} the keyword?
\keyword{this} would instead be bound (according to the ECMAScript
@ -265,19 +265,19 @@ dangerous:
]{lst/new-global.js}
Consider \jsref{lst:new-global} above. Function \func{Foo()}, if invoked with
the \keyword{new} keyword, results in an object with a \var{Boolean} property
the \operator{new} operator, results in an object with a \var{Boolean} property
equal to \keyword{true}. However, if we were to invoke \func{Foo()}
\emph{without} the \keyword{new} keyword, this would end up \emph{overwriting
\emph{without} the \operator{new} operator, this would end up \emph{overwriting
the built-in global \var{Boolean} object reference}. To solve this problem,
while at the same time providing the consistency and convenience of being able
to either include or omit the \keyword{new} keyword, we can add a small block of
code to our generated constructor \var{ctor} (somewhere around line 23 of
to either include or omit the \operator{new} operator, we can add a small block
of code to our generated constructor \var{ctor} (somewhere around line 23 of
\jsref{lst:ctor-factory}, after the extend check but before
\func{\_\_construct()} is invoked):
\lstinputlisting[%
label=lst:new-global-fix,
caption=Allowing for omission of the \keyword{new} keyword,
caption=Allowing for omission of the \operator{new} operator,
firstnumber=24
]{lst/new-global-fix.js}
@ -287,8 +287,8 @@ constructor \var{ctor}}. If not, the constructor can simply return a new
instance of itself through a recursive call.
Alternatively, the reader may decide to throw an error instead of automatically
returning a new instance. This would require the use of the \keyword{new}
keyword, while still ensuring the global scope will not be polluted with
returning a new instance. This would require the use of the \operator{new}
operator, while still ensuring the global scope will not be polluted with
unnecessary values. If the constructor is in strict mode, then the error would
help to point out bugs in the code. However, for the reason that the keyword is
optional for many core ECMAScript constructors, the author recommends the