undefined variables

[yb]

Hi,

Looking for clarification of undefined variables vs. error in
JavaScript code.

e.g.
<script>
alert( z ); // this will be an error, i.e. an exception
</script>

<script>
alert( this.z );
alert( window.z ); // both equivalent, no error, but window.z is
'undefined'
</script>

why is it that 'z' alone without the global object generates an error,
shouldn't it also be undefined? for example if i did

z = 0;

the javascript interpreter knows to create a global variable z

 

[Thomas 'PointedEars' Lahn]

e.g.
<script>

The required `type' attribute is missing.

alert( z ); // this will be an error, i.e. an exception
</script>

<script>

See above.

alert( this.z );
alert( window.z ); // both equivalent, no error, but window.z is
'undefined'

The statements are not equivalent. `window' does not need to refer to
the Global Object. In fact, if the Global Object has a `window' property,
the second expression equals `this.window.z' implicitly.

</script>

why is it that 'z' alone without the global object generates an error,

Because it is specified so. See ECMAScript 3 Final, 8.7.1.

shouldn't it also be undefined?

No, it should not. See above.

for example if i did

z = 0;

the javascript interpreter knows to create a global variable z

That only seems so. You may add a property to the Global Object through
the scope chain with this; in global context the result would be equivalent
to that of `this.z = 0' then. However, the next object in the scope chain
may be a host object instead that does not allow for augmentation (or its
properties to be overwritten). IOW: assignment to undeclared identifiers
without base object are error prone. Always declare such as a variable
with the `var' keyword (a VariableStatement does not use the scope chain)
or use a base object reference.


PointedEars

 

[yb]

Thanks, that clarifies several questions I had.

I'm reading JavaScript 4ed by David Flanagan. On p.55, it indicates
that the scope chain includes the variables declared with 'var'
keywords.

Sorry I'm referencing a text that isn't online, I plan to do a more
thorough study of the official specs but am a bit confused by the
information in Mr. Flanagan's text.

Hope someone can clarify

 

[Richard Cornford]

Looking for clarification of undefined variables vs.
error in JavaScript code.

Given that javascript has a primitive data type called - undefined - it
would be better to talk of undeclared variables rather than undefined
variables, as declared variables may have the value undefined.

e.g.
<script>
alert( z ); // this will be an error, i.e. an exception
</script>

<script>
alert( this.z );
alert( window.z ); // both equivalent, no error, but window.z is
'undefined'
</script>

An unqualified Identifier is evaluated by resolving it against the scope
chain and producing an instance of the internal Reference type as the
result. An Identifier naming an undeclared variable will result in a
Reference type that had - null - as its Base object and the Identifier
as the property name.

The constructs - this.z - and - window.z - are (dot notation) property
accessors. Property accessors also result in a Reference type when
evaluated, but if the part of the property accessor before the dot (or
opening square bracket in a bracket notation property accessor) does not
resolve as an Object type (and cannot be type-converted into an Object
type) an exception is thrown. The object that is the evaluated value of
the part of the property accessor before the dot becomes the Base object
of the Reference type that results from the evaluation of the property
accessor.

It is the difference in the value of the Base object in the two
Reference types that explains the difference in outcome. Any attempt to
recover a value with a Reference type that has a null Base object will
throw an exception. While any attempt to read the value of a
non-existent property with a Reference type that has a non-null base
object results in the - undefined - value.

why is it that 'z' alone without the global object generates
an error, shouldn't it also be undefined? for example if i did

z = 0;

the javascript interpreter knows to create a global variable z

The difference here is that the action is the assignment of a value
rather than its retrieval. Given an attempt to assign a value using a
Reference type that has a null Base object the interpreter uses the
global object in place of the non-existent Base object. Thus assignment
to an undeclared, unqualified Identifier results in the creation of a
property of the global object, and the assignment of a value to that
property.

Strictly this is does not represent the creation of a global variable,
but since declared global variables are created as properties of the
global object there is little practical distinction between a declared
global variable and a property of the global object created by
assignment at runtime. Declared global variable cannot be deleted and
dynamically created properties of the global object can be, but that is
not often a significant distinction.

However, it is good practice to never use an Identifier that refers to a
property of the global object without first declaring that Identifier as
a global variable. This 'best practice' helps to avoid and identify
scripting errors as it becomes obvious which Identifiers are intended to
refer to global variables, and which may just be leaking out of their
intended scope. It also avoids naming collision issues with properties
of the global object created by IE to represent DOM Elements that have
ID attributes, and are resistant to assignment in their natural state.

Richard.

 

[Richard Cornford]

Richard Cornford wrote:

However, it is good practice to never use an Identifier that
refers to a property of the global object without first
declaring that Identifier as a global variable.

<snip>

That is not well worded as it suggests declaring Identifiers such as -
document - or - Array - prior to using them. The above only applies to
Identifiers of properties that are added to the global object by the
programmer. Native and Host properties of the global objects should not
be declared.

Richard.

 

[yb]

In rereading responses here (thanks Richard as well), it looks like the
variable declared with 'var' does become part of the scope chain but is
useful since we don't need to reference a call object in the scope
chain explicitly?

 

[Thomas 'PointedEars' Lahn]

In rereading responses here (thanks Richard as well), it looks like the
variable declared with 'var' does become part of the scope chain but is
useful since we don't need to reference a call object in the scope
chain explicitly?

Declared variables are properties of the Variable Object of the execution
context. So they are part of the scope chain of this context. However,
for their declaration the scope chain is not used: it does not matter if
you have declared the same variable before, especially not if it was
declared before in an outer execution context. A VariableDeclaration
always creates a new property of the Variable Object of the context and
recreates it if such a property existed already.

var x = 0;
this.y = 23;
window.alert([x, y]); // 0,23

function foo()
{
// despite x is a global variable (and you would expect it to yield 0),
// x refers to the local variable in this context that was declared
// (see below) but not yet defined at this line
window.alert([x, y]); // [undefined],23
(function() { window.alert([x, y]); })(); // [undefined],23

var x = 42;
window.alert([x, y]); // 42,23
(function() { window.alert([x, y]); })(); // 42,23

// only a VariableStatement;
// variable instantiation comes before execution
var x;
window.alert([x, y]); // 42,23

// The local y variable is accessed instead of the global property;
// x refers to the local variable of the outer context instead of
// the global variable
(function() { var y = 11; window.alert([x, y]); })(); // 42,11

// a VariableDeclaration replaces the previous value,
// `this' refers to the caller which is the Global Object;
// since either it has no property named `undefined' or it has
// a property named `undefined' with the `undefined' value
// (the latter conforms to ECMAScript), x is assigned the
// `undefined' value either way (provided nobody changed the
// value of the property before)
var x = this.undefined;

// modifies (or creates) a global property using the scope chain
y = 0;

// "[undefined],0" because x refers to the local variable and y
// to the modified global property
window.alert([x, y]);

// "[undefined],[undefined]" because y is declared as a local variable
// in the inner context even though there is a global property with
// that identifier already
(function() { var y; window.alert([x, y]); })();

}

foo();

// the global property can be deleted
delete y;

// the global variable cannot be deleted (has the DontDelete attribute)
delete x;

window.alert([x, this.y]); // 0,[undefined]
window.alert([x, y]); // ReferenceError: y is not defined


HTH

PointedEars

 

[VK]

In rereading responses here (thanks Richard as well), it looks like the
variable declared with 'var' does become part of the scope chain but is
useful since we don't need to reference a call object in the scope
chain explicitly?

Declared variables are properties of the Variable Object of the execution
context. So they are part of the scope chain of this context. However,
for their declaration the scope chain is not used: it does not matter if
you have declared the same variable before, especially not if it was
declared before in an outer execution context. A VariableDeclaration
always creates a new property of the Variable Object of the context and
recreates it if such a property existed already.

var x = 0;
this.y = 23;
window.alert([x, y]); // 0,23

Anyone will finally pronounce the right word or not? I'm tired to wait.


var x = 0;
// and
this.y = 23;

if taken outside of function declaration (like in the samples)
addressing completely different namespaces.

var x = 0; creates new variable in the namespace of Global Object
(script execution context).

this.y = 23; adds new property to the Host Object (which is in the most
common case window object).

Most people used to look at this as one object, and most of the time it
doesn't produce big problems. Still one should remember that Global
Object and Host Object are very different. In the particular (OP's
case) an attempt to address undefined identifier in Global Objects
leads to runtime error
5009, "Undefined identifier" (JScript notation)
and
undefined (? keep forgetting to report), "... is not defined" (Firefox
notation)

Nevertheless an attempt to address undefined identifier in Host Object
simply returns undefined value.

 

[Thomas 'PointedEars' Lahn]

In rereading responses here (thanks Richard as well), it looks like the
variable declared with 'var' does become part of the scope chain but is
useful since we don't need to reference a call object in the scope
chain explicitly?

Declared variables are properties of the Variable Object of the execution
context. So they are part of the scope chain of this context. However,
for their declaration the scope chain is not used: it does not matter if
you have declared the same variable before, especially not if it was
declared before in an outer execution context. A VariableDeclaration
always creates a new property of the Variable Object of the context and
recreates it if such a property existed already.

var x = 0;
this.y = 23;
window.alert([x, y]); // 0,23

Anyone will finally pronounce the right word or not? [...]

The right word has been pronounced already but your judgment is probably
too clouded with notions of (inexistent) "dark secrets" to recognize that.

var x = 0;
// and
this.y = 23;

if taken outside of function declaration (like in the samples)
addressing completely different namespaces.

There are no namespaces in the discussed implementation (namespaces are
going to be introduced with ECMAScript Edition 4). There are execution
contexts (ECMAScript Edition 3 Final[1], section 10).

var x = 0; creates new variable in the namespace of Global Object
(script execution context).

When control enters the execution context (10.2), a variable x is created
as a property of the Variable Object of the execution context, with the
DontDelete attribute, before execution, through variable instantiation
(10.1.3).

Since the execution context is the global context here, it creates a
property of the Variable Object of the global context, which is is the
Global Object (10.2.1). When this VariableDeclaration is eventually
executed, the AssignmentExpression `0' initializes the variable (12.2).

this.y = 23; adds new property to the Host Object (which is in the most
common case window object).

Nonsense. It adds a new property to the object referred to with `this'.
In the global execution context, `this' is the Global Object (10.2.1).

The Global Object is _not_ a host object (4.3.8), it is a native object, and
a built-in object (4.3.6/7 and 15). It may have host-defined properties
that refer to itself. Its `window' property refers to the Global Object
itself in many HTML document object models (10.1.5). That a reference to
`window' cannot be identified per se with a reference to the Global Object
has been demonstrated already in the SVG DOM and in the Internet Explorer
HTML DOM.


PointedEars
___________
[1] <URL:http://www.mozilla.org/js/language/>

 

[VK]

The right word has been pronounced already but your judgment is probably
too clouded with notions of (inexistent) "dark secrets" to recognize that.

Search results for "Host Object" /i : zero entries (besides mine)

Nonsense. It adds a new property to the object referred to with `this'.
In the global execution context, `this' is the Global Object (10.2.1).

Nonsense.

<script type="text/javascript">
alert(this.navigator); // [Navigator object]
</script>

Outside of function "this" always refers to the Host Object which is in
the most common case is window object. If Books of ECMA indeed say
something else, it is plain wrong in that part.

 

[Thomas 'PointedEars' Lahn]

Search results for "Host Object" /i : zero entries (besides mine)

Because you are the only one to believe that the Global Object is a host
object.

Nonsense.

No, the above is correct.

<script type="text/javascript">
alert(this.navigator); // [Navigator object]

| 10.1.5 Global Object
|
| There is a unique global object (section 15.1), which is created before
| control enters any execution context. Initially the global object has the
| following properties:
|
| · Built-in objects such as Math, String, Date, parseInt, etc. These have
| attributes { DontEnum }.
| · Additional host defined properties. This may include a property whose
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| value is the global object itself; for example, in the HTML document
| object model the window property of the global object is the global
| object itself.
|
| As control enters execution contexts, and as ECMAScript code is executed,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| additional properties may be added to the global object and the initial
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| properties may be changed.

</script>

Outside of function "this" always refers to the Host Object [...]

There is no such thing as "the Host Object"; there are native objects,
built-in objects and host objects. And no, `this' does not refer to a
host object in that case.


PointedEars

 

[VK]

| 10.1.5 Global Object
|
| There is a unique global object (section 15.1), which is created before
| control enters any execution context. Initially the global object has the
| following properties:
|
| · Built-in objects such as Math, String, Date, parseInt, etc. These have
| attributes { DontEnum }.
| · Additional host defined properties. This may include a property whose
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| value is the global object itself; for example, in the HTML document
| object model the window property of the global object is the global
| object itself.
|
| As control enters execution contexts, and as ECMAScript code is executed,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| additional properties may be added to the global object and the initial
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| properties may be changed.

Oh my... And *this* you were reading for so many years?! I really
should sit down one day and read ECMA-262 throughout: this may answer
many strange comments I'm getting.

No, [this] doesn't refer to the Global object, it refers to the Host
object which is in OP's case current window object. There is a simless
tunnelling mechanics between Global and Host objects so they mainly act
as one unit. But sometimes they don't - like in OP's case:

<script type="text/javascript">
alert(undefinedVar); // error
alert(this.undefinedVar) // 'undefined'
</script>

MSDN in this case much better:

"this" statement
For client versions of JScript, this refers to the window object if
used outside of the context of any other object.

You can apply any window property, method, or collection to any
variable or expression that evaluates to a window object, regardless of
how that window was created. Additionally, you can access all window
properties, methods, and collections in the current window by using the
property, method, or collection name directly-that is, without
prefixing it with an expression that evaluates to the current window
object. However, to help make more readable code and to avoid potential
ambiguities, many authors use the window keyword when accessing window
properties, methods, and collections for the current window. This
keyword always refers to the current window.

Note The window's properties, methods, and collection names are
reserved keywords and cannot be used as the names of variables or
routines.

 

[Thomas 'PointedEars' Lahn]

Oh my... And *this* you were reading for so many years?!

It took me only a few minutes to find this (a text search for "Global
Object" is not really that hard), whereas you most certainly would have
never found it as you obviously lack any minimum clue about the
understanding of formal language specifications. Instead you trust your
fantasies about how things really are, most certainly induced by simplified
explanations for language newbies from Microsoft or elsewhere, and you are
disproven by specification definitions _and_ implementation reality each
and every time. Still you continue to trust them. There is a word for
that; the most polite substitute is "self-delusion".

I really should sit down one day and read ECMA-262 throughout:

If you only would.

this may answer many strange comments I'm getting.

Those "strange comments" describe specified and _implemented_ reality.
Your comments merely describe your fantasies.

No, [this] doesn't refer to the Global object,

Yes, it does, in global execution context.

it refers to the Host object which is in OP's case current window object.

Will you eventually recognize that there is not "the Host object"?
(There are a number of host objects. All DOM objects are host objects,
for example.)

There is a simless tunnelling mechanics

There is no "seamless tunneling mechanics"! It is so plain and simple that
even you should be able to recognize it: `window' is a property of the
_native_ Global Object that refers to its owner. It is a host-defined
property of the Global Object, one added by the host environment when
control enters the global execution context, as are other properties (like
navigator, location etc.). Using the `window' property of the Global
Object as base object reference in a modifying property access usually _has
to_ modify the corresponding property of the Global Object in that case.
That does not make the Global Object itself _a_ host object at all.

between Global and Host objects so they mainly act as one unit.
Nonsense.

But sometimes they don't - like in OP's case:

<script type="text/javascript">
alert(undefinedVar); // error

Once again you are providing code and its outcome, but you do not say what
you expect from it instead. So one can only guess what was meant, and I
for one are not particularly inclined to do so, given your continuous
display of your misconceptions about almost(?) everything discussed here,
and therefore your ultimate failure of being able to be considered a
competent developer and a reasonable discussion partner.

But JFTR: It has already been said that the above is a scope chain issue,
specified plain mechanical logic, and I have explained it now in very much
detail in (probably, if you read it
very slowly, you will be able to understand it one day). The bottom line
is: Exactly /because/ the native Global Object is the last object in every
scope chain, and it has no such property here, the ReferenceError exception
is thrown here.

alert(this.undefinedVar) // 'undefined'

This is a property access and not an Identifier evaluation, therefore it
follows different rules. Those rules are defined in ECMAScript Edition 3
Final, subsection 11.2.1, while Identifier evaluation is defined in
subsection 10.1.4. Even you should be able to recognize the difference
between the algorithms, and therefore the difference between their possible
outcome.

BTW: ECMAScript Edition 3 is what JavaScript 1.5/6 (Gecko-based UAs),
JScript 5.5+ (IE-based UAs), Opera 6+-based UAs, and KHTML-based UAs
(Konqueror, Safari) implement. Your mere notion elsewhere that this
edition of the specification has anything to do with NN 4.5 (October
1998) is ridiculous; NN 4.5 supported JavaScript 1.3 (NN 4.06 to 4.8),
which did implement ECMAScript Edition _1_ (without supporting the
`instanceof' operator introduced in Edition 3, for example).


PointedEars

 

[VK]

But JFTR: It has already been said that the above is a scope chain issue,
specified plain mechanical logic, and I have explained it now in very much
detail in (probably, if you read it
very slowly, you will be able to understand it one day). The bottom line
is: Exactly /because/ the native Global Object is the last object in every
scope chain, and it has no such property here, the ReferenceError exception
is thrown here.


This is a property access and not an Identifier evaluation, therefore it
follows different rules. Those rules are defined in ECMAScript Edition 3
Final, subsection 11.2.1, while Identifier evaluation is defined in
subsection 10.1.4. Even you should be able to recognize the difference
between the algorithms, and therefore the difference between their possible
outcome.

BTW: ECMAScript Edition 3 is what JavaScript 1.5/6 (Gecko-based UAs),
JScript 5.5+ (IE-based UAs), Opera 6+-based UAs, and KHTML-based UAs
(Konqueror, Safari) implement. Your mere notion elsewhere that this
edition of the specification has anything to do with NN 4.5 (October
1998) is ridiculous; NN 4.5 supported JavaScript 1.3 (NN 4.06 to 4.8),
which did implement ECMAScript Edition _1_ (without supporting the
`instanceof' operator introduced in Edition 3, for example).

Stop thinking in ECMAScript terms, start thinking in JavaScript /
JScript terms.

I never had to express it in writing before (just used it as given), so
it may be a bit (or a lot) sketchy.

Window is Host object, script execution context is Global object. By
hierarchy Global object stays below Host object, which is natural
because script is running in window, not window is running in script.
Therefore visibility scope of Global object shadows Host object which
is by design. Say is you declare function open(), it will shadow the
open() method of the Host object (window). Same with global variables.

FF seems the only browser (didn't check Safari/Konqueror) mimicing
exactly the relevant part of specification. I say "mimicing" because of
new Object(this) test.

I'm sorry but IMHighlyHO it has much more sense than one Global object
acting differently depending on amount of brakets and quotes around.

I did not place extensive comments for each test, but I'm reffering you
to
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/1d67f0e7b79fa9b7>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>Global and Host</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<style type="text/css">
body { background-color: #FFFFFF}
</style>

<script type="text/javascript">

var foobar1 = 'foobar1';

function init() {
try {
alert(delete foo); // false
alert(delete this['foo']); //
/* IE 6.0
* false
* 445, Object doesn't support this action
*
* FF 1.5.0.1
* false
* false
*
* Opera 8.51
* false
* false
*/

alert(this['var']);
eval('alert(var)');
/* IE 6.0
* [object]
* 1002, Syntax error
*
* FF 1.5.0.1
* undefined
* , syntax error
*
* Opera 8.51
* [object HTMLDivElement]
* , Syntax error
*/

alert(new Object(this));
/* IE 6.0
* [object]
*
* FF 1.5.0.1
* [object Window]
*
* Opera 8.51
* [object Window]
*/

var foobar2 = 'foobar2'
alert(this['foobar1']);
alert(foobar1);
alert(this['foobar2']);
alert(foobar2);
/* IE 6.0
* foobar1
* foobar1
* [object]
* foobar2
*
* FF 1.5.0.1
* foobar1
* foobar1
* undefined
* foobar2
*
* Opera 8.51
* foobar1
* foobar1
* [object HTMLDivElement]
* foobar2
*/
}
catch(e) {
var num = (typeof e.number == 'number')? e.number&0xFFFF:'';
alert(num+', '+e.message);
}
}

window.onload = init;
</script>

</head>

<body>

<div id="var">var</div>
<div id="foobar1">foobar1</div>
<div id="foobar2">foobar2</div>
</body>
</html>

 

[Thomas 'PointedEars' Lahn]

Stop thinking in ECMAScript terms, start thinking in JavaScript /
JScript terms.

Do not impose your self-delusion on others. JavaScript and JScript /are/
ECMAScript implementations, and they /do/ follow the algorithms defined
there, whether you accept that or not.

I never had to express it in writing before (just used it as given), so
it may be a bit (or a lot) sketchy.

Window is Host object,

Window _objects_ are _host objects_, one of the many host objects available,
including Location, Image, DOM element objects, implementations of
IXMLHTTPRequest aso. Windows objects are created explicitly by
window.open(), and implicitly with every global execution context, in the
HTML Document Object Model.

script execution context is Global object.

An execution context is no object at all. The Global Object is a native
object, it has a host-defined `window' property that refers to the Global
Object _in certain host environments_.

[I know everything better, even though I am not able to get a grasp of
or can properly explain the basics blah]

You are an ignorant troll, plain and simple.


PointedEars

 

[VK]

You are an ignorant troll, plain and simple.

Run the tests I posted, read the thread I linked.

Or just grab your copy of Books of ECMA and read your beloved pages - I
guess it always brings peace and consolation into your soul.

 

[Thomas 'PointedEars' Lahn]

Stop thinking in ECMAScript terms, start thinking in JavaScript /
JScript terms.

Do not impose your self-delusion on others. JavaScript and JScript /are/
ECMAScript implementations, and they /do/ follow the algorithms defined
there, whether you accept that or not.

I never had to express it in writing before (just used it as given), so
it may be a bit (or a lot) sketchy.

Window is Host object,

Window _objects_ are _host objects_, one of the many host objects available,
including Location, Image, DOM element objects, implementations of
IXMLHTTPRequest aso. Windows objects are created explicitly by
window.open(), and implicitly with every global execution context, in the
HTML Document Object Model.

script execution context is Global object.

An execution context is no object at all. The Global Object is a native
object, it has a host-defined `window' property that refers to the Global
Object _in certain host environments_.

By hierarchy Global object stays below Host object, [...]

No, it does not, as there is no Host object.

Therefore visibility scope of Global object shadows Host object which
is by design.
Nonsense.

Say is you declare function open(), it will shadow the open() method of
the Host object (window).

There is no "the Host object".

open() is a host-defined property added to the Global Object.
The Global Object's `window' property refers to the Global Object
in the corresponding host environment.

FF seems the only browser (didn't check Safari/Konqueror) mimicing
exactly the relevant part of specification.

It is not the only browser, let alone the only user agent.

I'm sorry but IMHighlyHO

Yes, in your foolish fantasy-opinion which is not based on any facts.
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/1d67f0e7b79fa9b7

I expected from you that you had not even got a glimpse of understanding
about what was discussed there.

[/QUOTE]

Are you trying to prove anything?


PointedEars

 

[Thomas 'PointedEars' Lahn]

Run the tests I posted, read the thread I linked.

I have read it and understood. If you even had understood it.

It does not say at all the Global Object is a host object, or
fulfills your delusional notion that it was "the Host object".

Or just grab your copy of Books of ECMA and read your beloved pages - I
guess it always brings peace and consolation into your soul.

The example in the thread you linked to (and I was already aware of),
and the example you posted, is completely in accordance with ECMAScript.
In fact, the behavior displayed can be explained only with strict
conformance to ECMAScript, and the scope chain definition therein.
But, to be blunt, you are far too stupid to recognize that.


PointedEars