new keyword => operator
parent
5f6919bfcb
commit
fb1a4b8012
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue