Calling Array.splice({}) with no start

[dhtml]

Re: Calling Array.splice({} ) with no start

Thomas 'PointedEars' Lahn wrote:

dhtml wrote:

>Thomas 'PointedEars' Lahn wrote:

>>dhtml wrote:
>>>Thomas 'PointedEars' Lahn wrote:
>>>>dhtml wrote:
>>>>>Thomas 'PointedEars' Lahn wrote:
>>>>>>You don't get it, do you? The language standard makes the first two
>>>>>>argumen ts of the method *mandatory*,
>>>>>Apparent ly I missed the line in the spec that says 'The first two
>>>>>argument s are necessary.' [...]
>>>>*Obviously* .
>>>>>
>>>>| 15.4.4.12 Array.prototype .splice (start, deleteCount [ , item1 [ , item2 [
>>>>| , … ] ] ] )
>>>>>
>>>>Brackets usually mark optional arguments/parameters, and they do so there.
>>>Usually. But the spec has examples of sections that don't seem to follow
>>>that convention. For example:
>>>>
>>>What about slice:
>>>15.4.4.10 Array.prototype .slice(start, end)
>>>>
>>>or sort:
>>>15.4.4.11 Array.prototype .sort(comparefn )
>>>>
>>>These don't have brackets around optional arguments. The arguments are
>>>optional in all modern (non-beta) implementations .
>>Non sequitur.

>Shows that optional arguments are treated as undefined.

>
If anything, it shows that that the specification is worded imprecisely.
Which point are you trying to make here?

Weren't you saying that non-square bracketed arguments were mandatory?

You inferred that 'square brackets means optional'. Then you seemed to
deny the antecedent of that inference with: if a parameter is non-square
bracketed, it is *mandatory* is faulty logic.

1. squares bracket not defined/documented.
2. other methods w/no square brackets around arguments use undefined for
missing arguments.

The square brackets don't have a defined meaning.

It was never debated that formal

parameters for which no value has been passed are treated as undefined *on
call*, that is what is specified. (Why did you reiterate that anyway?)
>
But what that means for the underlying algorithm of the method and therefore
for its return value, is an entirely different matter. If the Specification
does not say how an implementation is supposed to behave in such a case, it
is wrong to say that one implementation is correct and another one is not
just because the outcomes differ.

It sounds like you're still arguing that the underlying algorithm is
allowed to implement unique behavior when non-square bracketed arguments
are omitted. I don't see any grounds for this argument, in practice, or
in the spec.

It seems most reasonable to go with the behavior that is set forth in
10.1.3. Since implementations do this for non-square bracketed arguments
of all other methods, it is safe to say that it is a rule. The value
undefined should be used for a missing parameter, regardless of square
brackets.

Garrett

>

>>Please do not quote signatures unless you refer to them.
>>>
>>PointedEars

^^^^^^^^^^^
Which part of that did you not get?
>
>
PointedEars

[Thomas 'PointedEars' Lahn]

Re: Calling Array.splice({} ) with no start

dhtml wrote:

Thomas 'PointedEars' Lahn wrote:

>dhtml wrote:

>>Thomas 'PointedEars' Lahn wrote:
>>>dhtml wrote:
>>>>Thomas 'PointedEars' Lahn wrote:
>>>>>dhtml wrote:
>>>>>>Thomas 'PointedEars' Lahn wrote:
>>>>>>>You don't get it, do you? The language standard makes the
>>>>>>>first two arguments of the method *mandatory*,
>>>>>>Apparentl y I missed the line in the spec that says 'The first
>>>>>>two arguments are necessary.' [...]
>>>>>*Obviously *.
>>>>>>
>>>>>| 15.4.4.12 Array.prototype .splice (start, deleteCount [ ,
>>>>>item1 [ , item2 [ | , … ] ] ] )
>>>>>>
>>>>>Brackets usually mark optional arguments/parameters, and they
>>>>>do so there.
>>>>Usually. But the spec has examples of sections that don't seem to
>>>>follow that convention. For example:
>>>>>
>>>>What about slice: 15.4.4.10 Array.prototype .slice(start, end)
>>>>>
>>>>or sort: 15.4.4.11 Array.prototype .sort(comparefn )
>>>>>
>>>>These don't have brackets around optional arguments. The
>>>>arguments are optional in all modern (non-beta) implementations .
>>>Non sequitur.
>>Shows that optional arguments are treated as undefined.

>If anything, it shows that that the specification is worded
>imprecisely. Which point are you trying to make here?

>
Weren't you saying that non-square bracketed arguments were mandatory?

Not so, I did not.

The square brackets don't have a defined meaning.

Yes, they have.

>It was never debated that formal parameters for which no value has been
>passed are treated as undefined *on call*, that is what is specified.
>(Why did you reiterate that anyway?)
>>
>But what that means for the underlying algorithm of the method and
>therefore for its return value, is an entirely different matter. If
>the Specification does not say how an implementation is supposed to
>behave in such a case, it is wrong to say that one implementation is
>correct and another one is not just because the outcomes differ.

>
It sounds like you're still arguing that the underlying algorithm is
allowed to implement unique behavior when non-square bracketed arguments
are omitted.

Again, for the intellectually challenged among us: I am arguing instead that
brackets would give an indication as to which arguments are optional and
which are not; however, as the Specification is obviously worded
imprecisely, the Specification prose also counts. If there is nothing in
the prose/algorithm of a method to define what is to be done when certain
arguments are omitted, it is not reasonable to call one return value wrong
and one right. Period.

I don't see any grounds for this argument, in practice, or in the spec.
>
It seems most reasonable to go with the behavior that is set forth in
10.1.3. Since implementations do this for non-square bracketed arguments
of all other methods, it is safe to say that it is a rule. The value
undefined should be used for a missing parameter, regardless of square
brackets.

Non sequitur. You misunderstood completely what I was saying; given your
other luser-like behavior, maybe on purpose:

[quoting unreferred parts including my signature again]

Score adjusted

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Dr J R Stockton]

Re: Calling Array.splice({} ) with no start

In comp.lang.javas cript message <48ADDF73.80002 09@PointedEars. de>, Thu,
21 Aug 2008 23:34:43, Thomas 'PointedEars' Lahn <PointedEars@we b.de>
posted:

>

>>Please do not quote signatures unless you refer to them.
>>>
>>PointedEars

^^^^^^^^^^^
>Which part of that did you not get?
>
>
>PointedEars

It's not a signature. Signatures are preceded by a signature delimiter.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html-Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demo n.co.uk/news-use.htm: about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.

[dhtml]

Re: Calling Array.splice({} ) with no start

Thomas 'PointedEars' Lahn wrote:

dhtml wrote:

>Thomas 'PointedEars' Lahn wrote:

>>dhtml wrote:
>>>Thomas 'PointedEars' Lahn wrote:
>>>>dhtml wrote:
>>>>>Thomas 'PointedEars' Lahn wrote:
>>>>>>dhtml wrote:
>>>>>>>Thomas 'PointedEars' Lahn wrote:
>>>>>>>>You don't get it, do you? The language standard makes the
>>>>>>>>first two arguments of the method *mandatory*,
>>>>>>>Apparent ly I missed the line in the spec that says 'The first
>>>>>>>two arguments are necessary.' [...]
>>>>>>*Obviousl y*.
>>>>>>>
>>>>>>| 15.4.4.12 Array.prototype .splice (start, deleteCount [ ,
>>>>>>item1 [ , item2 [ | , … ] ] ] )
>>>>>>>
>>>>>>Bracket s usually mark optional arguments/parameters, and they
>>>>>>do so there.
>>>>>Usually. But the spec has examples of sections that don't seem to
>>>>>follow that convention. For example:
>>>>>>
>>>>>What about slice: 15.4.4.10 Array.prototype .slice(start, end)
>>>>>>
>>>>>or sort: 15.4.4.11 Array.prototype .sort(comparefn )
>>>>>>
>>>>>These don't have brackets around optional arguments. The
>>>>>argument s are optional in all modern (non-beta) implementations .
>>>>Non sequitur.
>>>Shows that optional arguments are treated as undefined.
>>If anything, it shows that that the specification is worded
>>imprecisely . Which point are you trying to make here?

>Weren't you saying that non-square bracketed arguments were mandatory?

>
Not so, I did not.
>

>The square brackets don't have a defined meaning.

>
Yes, they have.

So what is clearly defined meaning?

>

>>It was never debated that formal parameters for which no value has been
>>passed are treated as undefined *on call*, that is what is specified.
>>(Why did you reiterate that anyway?)
>>>
>>But what that means for the underlying algorithm of the method and
>>therefore for its return value, is an entirely different matter. If
>>the Specification does not say how an implementation is supposed to
>>behave in such a case, it is wrong to say that one implementation is
>>correct and another one is not just because the outcomes differ.

>It sounds like you're still arguing that the underlying algorithm is
>allowed to implement unique behavior when non-square bracketed arguments
> are omitted.

>
Again, for the intellectually challenged among us: I am arguing instead that
brackets would give an indication as to which arguments are optional and
which are not;

So the "clearly defined meaning" is the argument of Thomas 'PointedEars'
Lahn.

however, as the Specification is obviously worded
imprecisely, the Specification prose also counts. If there is nothing in
the prose/algorithm of a method to define what is to be done when certain
arguments are omitted, it is not reasonable to call one return value wrong
and one right. Period.
>

>I don't see any grounds for this argument, in practice, or in the spec.
>>
>It seems most reasonable to go with the behavior that is set forth in
>10.1.3. Since implementations do this for non-square bracketed arguments
> of all other methods, it is safe to say that it is a rule. The value
>undefined should be used for a missing parameter, regardless of square
>brackets.

>
Non sequitur. You misunderstood completely what I was saying;

I'm not sure that anyone understood completely what you were saying.
Sprinkling your argument with put downs doesn't exactly make it clearer.

given your
other luser-like behavior, maybe on purpose:
>

>[quoting unreferred parts including my signature again]

>
Score adjusted
>

Uh oh. not that again. Thomas, I am trying to engage in a normal
conversation with you. But you seem to be resisting that. I think that's
a bad choice. I thought you wanted to be FAQ maintainer. What happened?

Garrett

PointedEars