Cookie problem! Getting error when passing the expire date.

[Richard Cornford]

Not the Number only, but the whole language itself, welcome
to the JavaScript world.

Yet another example of your stringing words together and producing a
result that says nothing.

Are we aware of runtime typezation? ;-)

Are 'we' making up our own terminology agian?

alert("" == 0); // true

That is the specified (and so expected) result. The type-converting
comparison will tend to do numeric comparisons so (as Lasse stated) the
fact that the empty string type-converts to numeric zero makes this
comparison true.

btw and AFAIK Number is supposed to be used as constructor,
not as a method.

One of the main things you would benefit from learning is an
appreciation of how very little you actually do know. See ECMA 262, 3rd
Ed. Section 15.7.1 "The Number Constructor Called as a Function", and
appreciate that a function should not be spoken of as a 'method' unless
it is called as a member of an object.

Richard.

 

[Michael Winter]

Not the Number only, but the whole language itself, welcome to the
JavaScript world. Are we aware of runtime typezation? ;-)

Do you mean implicit type conversion, or the status of ECMAScript as a
dynamically-typed language?

alert("" == 0); // true

The above is a product of the former.

When strings are compared to numbers, the string is type-converted to a
number. In fact, type conversion, in general, is typically biased
towards numbers. Probably because, as far as comparison is concerned, a
number is the most simple and efficient.

btw and AFAIK Number is supposed to be used as constructor, not as a
method.

Not really. All of the constructor functions that are analogous to
primitive types (String, Boolean, and Number), and the Object
constructor function, perform type conversion when called as functions.
The other constructor functions typically act as though they were called
with use of the new operator (though Date is an odd exception).

The Number and Boolean constructor functions are typically less
efficient than the equivalent operator sequences (unary plus [+] and
logical NOT [!], respectively).

Mike

 

[Thomas 'PointedEars' Lahn]

One of the main things you would benefit from learning is an
appreciation of how very little you actually do know. See ECMA 262, 3rd
Ed. Section 15.7.1 "The Number Constructor Called as a Function", and
appreciate that a function should not be spoken of as a 'method' unless
it is called as a member of an object.

As for the former, I concur. As for the latter, one should keep in mind
that every function is indeed a method (ES3 Final, 4.3.3) in ECMAScript
implementations -- if its owner is (and therefore the function is called as
a member of) only the Variable Object of the execution context (the Global
Object for globally declared functions, and built-in top-level functions
such as Number(); see ES3 Final, subsection 10.1.5). However, to
distinguish between constructors and methods is typically VK again; every
constructor is a function, hence it is also a method.


Regards,
PointedEars

 

[Lasse Reichstein Nielsen]

As for the latter, one should keep in mind that every function is
indeed a method (ES3 Final, 4.3.3) in ECMAScript implementations --
if its owner is (and therefore the function is called as a member
of) only the Variable Object of the execution context (the Global
Object for globally declared functions, and built-in top-level
functions such as Number(); see ES3 Final, subsection 10.1.5).

Not all functions are methods, although there isn't really a lot
you can do about function without them becoming methods (which
also proves that the official terminology is not very good, if
all functions are also methods, we don't need two words).

Witnes:
var x = ((function(){}).prototype={}),42);

The function created here has no other object property referring to it
than it's own prototype.constructor, so when we override this, it's no
longer a method. We also have no reference to it, since all variables
are also properties of objects (global, arguments or activation
object), and we dare not call it, or it will become the method
arguments.callee, so it's completely useless


A more relevant distinction would be whether a function is *called* as
a method or not (i.e., called through a Reference value, setting
the value of the "this" operator in the method body during the call,
instead of it defaulting to the global object).

/L

 

[Lasse Reichstein Nielsen]

The Number and Boolean constructor functions are typically less
efficient than the equivalent operator sequences (unary plus [+] and
logical NOT [!], respectively).

(that would be double-not [!!])
The performance might be very slightly better for operators that doesn't
do anything except type convert their arguments, than for function calls
that then do the same.

On the other hand, a large number of type conversions inside a tight
loop does sound like something that should be recoded, and outside
of such a loop, the performance difference is too small to measure.

I personally find the conversion functions easier to read than the
operators, which is another measure to choose by

/L

 

[Richard Cornford]

As for the former, I concur. As for the latter, one should
keep in mind that every function is indeed a method (ES3
Final, 4.3.3) in ECMAScript implementations -

Every function?

(function(){;})();

- a function that is never assigned as a property of any object.

- if its owner is (and therefore the function is called as a
member of) only the Variable Object of the execution context
(the Global Object for globally declared functions, and
built-in top-level functions such as Number(); see ES3 Final,
subsection 10.1.5).

So is that supposed to paraphrase as: every function is a method in
ECMAScript implementations - if its owner is only the Variable Object of
the execution context? Because that does not rally make sense.

However, to distinguish between constructors and methods is
typically VK again; every constructor is a function, hence
it is also a method.

No, the 'every function is a method' part of that is not true.

However, taking an overly tolerant attitude towards the meaning of
'method', where any function that is in some sense a property of an
(any) object just acts to render the term redundant, as we can say
'function' in its place and be expressing no less.

'Method' really needs to be used and understood in its object-oriented
sense, where a method is a member of an object. However, in javascript a
function being a member of an object is not sufficient; the function's
relationship with the object is not significantly influenced by its
being just a member of the object, it is how the function is called that
gives a function the special relationship with the object to the extent
that it would be meaningful to call it a 'method'. In short the
categorisation 'method' only meaningfully applies to functions in which
the - this - keyword can be used to refer to the object on which the
function is a member.

This means that the telling discriminator between a function and a
method should be in section 11.2.3; and only circumstances where the -
MemberExpression - resulted in a Reference type that had a non-null base
object that is not an activation object (the global object is never an
activation object), and so will result in a non-null value being passed
into the [[Call]] as the - this - value, would justify labelling a
function a 'method'. For practical purposes the sub-category of
functions that could be labelled 'methods' would be those intended to be
called in this way, otherwise the distinction is meaningless and the
term 'method' is redundant.

Richard.

 

[Thomas 'PointedEars' Lahn]

Every function?

(function(){;})();

- a function that is never assigned as a property of any object.

True, I misread section 13.2 here.

So is that supposed to paraphrase as: every function is a method in
ECMAScript implementations - if its owner is only the Variable Object of
the execution context? Because that does not rally make sense.

I meant to say that the fact that a function can be referred to as a
property of the Variable Object of an execution context is already
sufficient for it to become a method. There is no explicit mentioning
of the owner object required in the reference.

However, taking an overly tolerant attitude towards the meaning of
'method', where any function that is in some sense a property of an
(any) object just acts to render the term redundant, as we can say
'function' in its place and be expressing no less.

You have disproven that yourself already. Standalone FunctionExpressions
create Function( object)s that are functions, but not methods, as they have
no defined owner object.


PointedEars

 

[RobG]

Richard Cornford said on 01/05/2006 8:17 AM AEST:
[...]

This means that the telling discriminator between a function and a
method should be in section 11.2.3; and only circumstances where the -
MemberExpression - resulted in a Reference type that had a non-null base
object that is not an activation object (the global object is never an
activation object)

Does that mean that there is no activation object associated with the
global object? That is, only function code creates an activation
object? That appears to be inferred by 10.1.6:

"When control enters an execution context for function code, an
object called the activation object is created and associated
with the execution context."

Similarly for the arguments object. There seems to be a clear
difference to constructors and no mention specifically of the global object.


, and so will result in a non-null value being passed

into the [[Call]] as the - this - value, would justify labelling a
function a 'method'. For practical purposes the sub-category of
functions that could be labelled 'methods' would be those intended to be
called in this way, otherwise the distinction is meaningless and the
term 'method' is redundant.

I paraphrased this as 'wherever an activation object has a -this- value
of an object other than the global object, the function is a method'.

Is that correct?

 

[VK]

That is the specified (and so expected) result. The type-converting
comparison will tend to do numeric comparisons so (as Lasse stated) the
fact that the empty string type-converts to numeric zero makes this
comparison true.

Right. And this is whay I posted it in reference to the OP's evident
surprise that in JavaScript empty string may result in 0, 0 in empty
string and both to false.

Thank you for your explanations, but actually I did not need them

One of the main things you would benefit from learning is an
appreciation of how very little you actually do know. See ECMA 262, 3rd
Ed. Section 15.7.1 "The Number Constructor Called as a Function", and
appreciate that a function should not be spoken of as a 'method' unless
it is called as a member of an object.

You may benefit from reading specs once over again Every
conventional JavaScript function (thus pre-defined by the engine or
defined on the top level in <script> block) is a method of the Global
object. The fact that you don't have to type this.myFunction() or
window.myFunction() in the global context is just a convenience
shortcut, same way as say in Perl $foo = 'bar'; actually means
main::$foo = 'bar';

JavaScript doesn't have at all "functions" in the sense on QBasic or
other pre-OOP languages. Yet for the simplicity it is normal to call
functions declared in the global context and not appertaining to any
explicit object as "functions", not as "methods of Global object".

On the conventional level of JavaScript programming it is all to say I
guess. On a higher level (XBL/ IE Behaviors) you can have N amount of
Global objects created for the given document. The first one is the
regular Global from <script>, others are created for each declared
behavior type and not directly accessible from the <script> Global.
Respectively their functions are members of the relevant Global, but
not of the <script> Global.

But ECMA Books do not go so far, and it must be out of your interests.

 

[Richard Cornford]

True, I misread section 13.2 here.


I meant to say that the fact that a function can be referred to
as a property of the Variable Object of an execution context is
already sufficient for it to become a method. There is no
explicit mentioning of the owner object required in the reference.

But when an unqualified Identifier is used to reference a function that
is a property of a Variable object that object is still the base
property of the resulting Reference type. That object does not get
passed into the function call as the - this - value because a Variable
object is also its Activation object (if it was created for a function's
execution context)) so step 7 in the algorithm for section 11.2.3
substitutes null as the - this - value.

You have disproven that yourself already.

Shown that there is a distinction maybe.

Standalone FunctionExpressions create Function( object)s that are
functions, but not methods, as they have no defined owner object.

Well, I had not taken into account the fact that Lasse pointed out; that
even the result of an anonymous function expression will be a property
of its own prototype, so all functions are properties of some object
when created. Though Lasse also pointed out that they do not need to
remain so, so it remains possible for a function not to be a property of
any object (if often less than useful when it is). So it would be
possible to use 'method' as opposed to 'function' to express a tangible
difference, but such a minor one that it seems ridiculous to squander a
term as loaded and expressive as 'method' in order to draw such a minor
distinction.

I am also reminded that all functions have a [[Construct]] method, and
so it would be as reasonable to label all functions 'constructors', at
which point we have three terms that could be used to express
significant aspects of the use of functions being reduced the virtually
synonymous terms for functions, just because an overly pedantic attitude
could justify that application of the terms.

I will stand by my original statement; that functions should not be
labelled methods unless they are _called_ as properties of objects. We
should consistently use the diversity of terminology to convey useful
concepts.

Richard.

 

[Richard Cornford]

Richard Cornford said on 01/05/2006 8:17 AM AEST:
[...]

This means that the telling discriminator between a function
and a method should be in section 11.2.3; and only
circumstances where the - MemberExpression - resulted in
a Reference type that had a non-null base object that is
not an activation object (the global object is never an
activation object)

Does that mean that there is no activation object associated
with the global object? That is, only function code creates
an activation object? That appears to be inferred by 10.1.6:

"When control enters an execution context for function code,
an object called the activation object is created and
associated with the execution context."

Similarly for the arguments object.

Yes, the global execution context doesn't need an Activation object, and
it has no arguments so it doesn't need and arguments object either.

There seems to be a clear difference to constructors and
no mention specifically of the global object.

I am not sure what you are getting at there.

, and so will result in a non-null value being passed

into the [[Call]] as the - this - value, would justify
labelling a function a 'method'. For practical purposes
the sub-category of functions that could be labelled
'methods' would be those intended to be called in this
way, otherwise the distinction is meaningless and the
term 'method' is redundant.

I paraphrased this as 'wherever an activation object has
a -this- value of an object other than the global object,
the function is a method'.

Is that correct?

Pretty much. I would accept that there is a grey area when the - this -
value passed into a function call is the global object, rather than
being null. Something like - window.globalFunction()- - is a method call
but the - this - value will be the global object, and so the result will
be indistinguishable from - (x = globalFunction)(); - (apart from the
side-effect assignment).

Richard.

 

[Richard Cornford]

VK wrote:

... .The fact that you don't have to type this.myFunction() or
window.myFunction() in the global context is just a convenience
shortcut, same way as say in Perl $foo = 'bar'; actually means
main::$foo = 'bar';

Bullshit. It is the fact that the Reference type that results form the
evaluation of the property accessors - this.myFunction - and -
window.myFunction - is indistinguishable from the Reference type that
results from the scope chain resolution of - myFunction - (when -
myFunction - is defined in the global execution context, and not defined
in a intervening scope) that allows the latter to be used in the pace of
the former. There is no "convenience shortcut" here, just alternative
ways of achieving he same outcome.

JavaScript doesn't have at all "functions" in the sense on
QBasic or other pre-OOP languages.

QBasic is not a pre OOP language, it is quite a recent language.

Yet for the simplicity it is normal to call functions declared
in the global context and not appertaining to any explicit
object as "functions", not as "methods of Global object".

It is normal to call any and all instances of javascript's function
objects a "function".

On the conventional level of JavaScript programming it is
all to say I guess.

That does not make sense.

On a higher level (XBL/ IE Behaviors) ...

<snip>

Irrelevant to your inappropriate (and so potentially misleading) use of
terminology.

But ECMA Books do not go so far, and it must be out of
your interests.

That isn't quite a sentence either.

Richard.

 

[Thomas 'PointedEars' Lahn]

But when an unqualified Identifier is used to reference a function that
is a property of a Variable object that object is still the base
property of the resulting Reference type. That object does not get
passed into the function call as the - this - value because a Variable
object is also its Activation object (if it was created for a function's
execution context)) so step 7 in the algorithm for section 11.2.3
substitutes null as the - this - value.

True. However, section 10.2.3 (Function Code) states:

| [...]
| * The caller provides the `this' value. If the `this' value provided by
| the caller is not an object (including the case where it is `null'),
| then the `this' value is the global object.

I am also reminded that all functions have a [[Construct]] method, and
so it would be as reasonable to label all functions 'constructors',

I don't think so. The reason why I think it is acceptable to call all
functions methods is that they are actually [[Call]]ed. Therefore, I
find it acceptable to call those methods/functions constructors that are
actually [[Construct]]ed, or are intended to be [[Construct]] by the
developer; not all functions/methods.


PointedEars