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} \end{verbatim}
It is apparent that \code{"foo"} is not a function and therefore cannot be used 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 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 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 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" ); var inst = new Foo( "Name" );
\end{verbatim} \end{verbatim}
We can make our code even more concise by eliminating the \keyword{new} keyword We can make our code even more concise by eliminating the \operator{new}
entirely, allowing us to create a new instance as such: operator entirely, allowing us to create a new instance as such:
\begin{verbatim} \begin{verbatim}
var inst = Foo( "Name" ); 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 with awkward precedence rules: \code{Foo( "Name" ).getName()} vs. \code{( new
Foo( "Name" ) ).getName()}. However, those reasons exit more to offer syntactic 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 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 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}, 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 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. properties of \keyword{this} from within the constructor without any problems.
What, then, happens if the constructor is invoked \emph{without} the keyword? What, then, happens if the constructor is invoked \emph{without} the keyword?
\keyword{this} would instead be bound (according to the ECMAScript \keyword{this} would instead be bound (according to the ECMAScript
@ -265,19 +265,19 @@ dangerous:
]{lst/new-global.js} ]{lst/new-global.js}
Consider \jsref{lst:new-global} above. Function \func{Foo()}, if invoked with 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()} 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, 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 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 to either include or omit the \operator{new} operator, we can add a small block
code to our generated constructor \var{ctor} (somewhere around line 23 of of code to our generated constructor \var{ctor} (somewhere around line 23 of
\jsref{lst:ctor-factory}, after the extend check but before \jsref{lst:ctor-factory}, after the extend check but before
\func{\_\_construct()} is invoked): \func{\_\_construct()} is invoked):
\lstinputlisting[% \lstinputlisting[%
label=lst:new-global-fix, 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 firstnumber=24
]{lst/new-global-fix.js} ]{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. instance of itself through a recursive call.
Alternatively, the reader may decide to throw an error instead of automatically 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} returning a new instance. This would require the use of the \operator{new}
keyword, while still ensuring the global scope will not be polluted with 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 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 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 optional for many core ECMAScript constructors, the author recommends the