Why do you say that?
Both of those lines exist for specific purposes relating to the use of the %TypedArray% intrinsic, and primarily come into play when AllocateTypedArray is called from it.
The first line says that you get an exception if you attempt to directly call %TypedArray%
%TypedArray% is intended to only be super new'ed by its subclass constructors.
The second line says that you get an exception if you try to directly invoke 'new' on %TypedArray%
do you have a follow up. If not, I'll close this as invalid.
(In reply to Allen Wirfs-Brock from comment #1)
> The first line says that you get an exception if you attempt to directly
> call %TypedArray%
>
> The second line says that you get an exception if you try to directly invoke
> 'new' on %TypedArray%
Allen, I think steps 5.a-b can do these two things, or am i missing something?
You're technically correct. But, I think the redundancy is good, from a specification perspective as lines 1-2 and 5-5e are actually addressing distinct requirements. The first is that you aren't alled to directly call or new %TypedArray".
Step 5 is saying that valid subclass must have a [[TypedArrayonstructorName]] somewhere on its subclass chain but below %TypedArray%
While the mechanism used to do step 5 also covers 1-2 we could leave out 1-2. But that conflates the separate requirements in a way that may make the 1-2 requirements less obvious.
In fact, I went the other direction. I added a NOTE after step two clarify the purpose of the first two lines.
But implementations, of course, are free to do that sort of optimization.
(In reply to Allen Wirfs-Brock from comment #4)
> You're technically correct. But, I think the redundancy is good, from a
> specification perspective as lines 1-2 and 5-5e are actually addressing
> distinct requirements. The first is that you aren't alled to directly call
> or new %TypedArray".
>
> Step 5 is saying that valid subclass must have a
> [[TypedArrayonstructorName]] somewhere on its subclass chain but below
> %TypedArray%
>
> While the mechanism used to do step 5 also covers 1-2 we could leave out
> 1-2. But that conflates the separate requirements in a way that may make the
> 1-2 requirements less obvious.
>
> In fact, I went the other direction. I added a NOTE after step two clarify
> the purpose of the first two lines.
>
> But implementations, of course, are free to do that sort of optimization.
I see now. Thank you.
fixed in rev33