"strict mode" becomes "use subset cautious"
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: "strict mode" becomes "use subset cautious"
by Maciej Stachowiak
::
Rate this Message:
|
|
|
RE: "strict mode" becomes "use subset cautious"
by Lars Hansen-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
There has been no discussion in the ES4 WG about adopting the ES3.1
convention in this matter. I don't think that a list of subset violations
exists. The closest thing we have is probably my response to the 11 June
draft of ES3.1, in which I pointed out all the problems I could see at the
time. (A bit of a rant this, but speaking for myself, I object to the strongly
ideological slant of some of the ideas that have gone into the current ES3.1
strict mode, such as disallowing semicolon insertion in strict mode, and I see the
inclusions of features like that as another real problem with the subset relation.
In the past the ES4 WG has tried to avoid cosmetic changes to the language, and
we've also been skeptical of changes that increase the tax of moving to strict
mode. We want strict mode to be used, which means striking a balance
between safety and convenience. It is possible that 3 programs out there
have bugs caused by optional semicolon insertion. But it also likely that
3 million programs will not be ported to (or written to) strict mode if
semicolon insertion is disallowed.) --lars From:
es3.x-discuss-bounces@... [mailto:es3.x-discuss-bounces@...] On
Behalf Of Maciej Stachowiak On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote:
At today’s ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed to adopt the
essence of the proposal below and to use the subset name “cautious”
to referred to the set of restrictions formerly known as “strict
mode” Will ES4 also be making this change? If not, we need to add
it to the list of subset rule violations. Is anyone keeping such a list? Does
the ES3.1 committee intend to address all such issues by the July timeframe
that ES3.1 is apparently targetting? Regards, Maciej
_____________________________________________ Following up on the “Strict Mode” discussion… As I advocated on the call, I think that by selecting
“strict mode” a developer is really choosing to restrict themselves
to using a subset of the complete language. The future-proofing
issues of this relate to the possibility that there might be multiple
such subsets that a developer might need to choose among. Should there be
multiple named “strict modes” to choose among, how should they be
named, can “strictness” of a mode increase in future versions, etc? I think some of the controversy could be eliminated if we simply
eliminate the term “Strict Mode”. Instead I propose we have a
“Use Subset” directive and that we name specific subsets in a
meaningful and generally positive manner. For example, since the
motivation of most of the proposed restrictions in ES3.1 strict mode is to
provide a safer subset language I suggest that we call this subset
“safety” (or perhaps “safety1” or
“safetyA” or “safety2008” implying that in the
future different safe subsets might be defined and we don’t want to give
undo importance to this initial one). So, the first line of a “strict mode” compilation unit
would now look like” “use subset
safety” I would suggest that we actually define “use subset”
such that a comma separated list of subsets is allowed. So, if somebody
decided to define a subset that only contained the features of ES3 you might
see something like this: “use subset
safety,ES3” Since subsets are sets of restrictions, listing multiple subsets
means to take the union of the restrictions imposed by all of the listed
subsets. So “use subset safty,ES3” means that this compilation
unit may only use those features defined by ECMA 262-3 and which are not
excluded by the “safety” subset. So, assuming that
“safety” excludes use of the with statement, such a compilation
unit could not include use of the with statement nor could it include any use
of a feature that is new in ES3.1 or ES4. Future versions of ECMAScript may add exclusions to a subset
defined by an earlier version as long as the added exclusions only restrict
capabilities that didn’t exist in the earlier version. For example, ES 4
in supporting the ES3.1 “safety” subset but add to it any features
that are added in ES 4 but which are considered to be unsafe. A future version may not add exclusion to an pre-existing
subset that restricts features that existed when the original subset was
defined. For example if ES3.14 or ES5 decided that the for-in statement
was unsafe, it could not add that restriction to the “safety” subset.
However, it could define a new subset named perhaps “safety2010”
that includes all the restrictions of the “safety” subset and in
addition disallows use of the “for” statement. If a compilation unit specifies a subset that is not known to
the implementation that is processing it, that subset restriction is simply
ignored. The code in the unit is still either valid or invalid on its own merit
just like is the case when no subset had been specified. _____________________________________________ Here are brief minutes from our call. Please take a look, and let me know if you want any changes by
your EOD. I’ll upload it to the wiki and send a copy to Patrick
Charollais (ECMA) for posting on the ECMA site tomorrow night (Redmond time). Attendees Adam Peller (IBM) Sam Ruby (IBM) Mark Miller (Google) Allen Wirfs-Brock (Microsoft) Agenda On posting the latest draft to the wiki Getters/Setters Decimal Setting up a review based on Lars' feedback on the 11 June draft Minutes Would like to add a couple more items to agenda that we can get
to if we have the time (1) inconsistence language like "as if by the
expression …" pervasive in ES3 (e.g. section 11.1.4 Array
Initializer: "create a new array as if by the expression new
Array()"; needs to be fixed in ES3.1 (2) ES3/ES4 based review. On posting the latest draft to the wiki The latest draft has been uploaded to the wiki. This the draft
as of 24 June 2008 - it has all the edits related to the statics on Object, the
introduction of the [[Extensible]] property, the revised notation for JSON, and
placeholders for Decimal - by next week we should try to have a technically
complete draft - the draft may still have some place holders but it should
still be enough to get circulated within TC39 as an artifact that can be
reviewed - by the time we meet in Oslo, each place holder must have a
supplementary doc that can be discussed F2F. 'const' needs to be introduced into the grammar - what does it
mean to be a reserved word? - you cannot use it as a variable name - note that
we have introduced the ability to use is as the name of a property though
– const has letrec like scoping – not subject to hoisting. reformed scoping needs to be introduced - but for doing that we
may want to introduce the notion of a 'block activation' as an expository
device ‘abc’[i] is using the ES3 like algorithm convention
– can we use the new convention that eliminates the need for writing
gotos – pratapL to investigate – also, for all new functionality we
need to worry about argument conditioning – for e.g. if an algorithm
expects to be handed an object, make sure we call toObject on the argument that
is passed in. Getters/Setters Surface syntax spec from Kris looked Ok - need to ensure it is
using the Meta APIs - Allen to check surface syntax integration. Decimal Decimal changes are isolated and can be done without impacting
content in the rest of the doc - Sam can use the latest draft from the wiki as
a starting point. Strict mode 2 controversies coupled to each other – proposed ES4 wants
to keep ‘with’ in their strict mode; ES3.1 wants to remove
‘with’ in its strict mode – need to be clear about the
purpose of strict mode – the other is “what do we mean by
subset?” – there was one formal definition from Lars, and Doug had
called out a less formal notion – we may end up using Doug’s less
formal notion (especially if we cannot resolve the ‘with’ issue). Binary strict mode is naively limiting – each version may
want to allow/limit specific features – strict mode allows users to say
‘I am subscribing to this particular subset, and I am aware of all its limitations’
– but if the subset is a moving target how do they do that? - sure, we
can introduce a more elaborate mechanism – it would make it easier for us
to not have to resolve arguments – but it would open up a larger combinatorial
space of possibilities – the SunOS vs. MacOS problem; the former was
highly customizable, however you invariably got it wrong; the latter was not
customizable, but what you got was good enough to get the job done – more
knobs need not mean better. An elaborate mechanism enables chaos at the composability
boundary – but how does it matter if you are opaquely including a module?
– Caja will use ES3.1 strict mode for all uncajoled code – OTOH an
elaborate mechanism can enforce a subsetting profile – languages can now
more directly enforce Caja like semantics. ‘use strict 3.1’ could be a potential syntax to turn
on 3.1 level strict mode – with the possibility that the 3.1 may be
replaced with a list – instead of tying it to the language version
number, we can also just say something like ‘use strict a’ or
‘use strict 1’ – can also use Perl-style ‘use strict no
with’ (where we mention the specific restriction we want to enable)
– that seems a good idea too – in any case, named restriction sets
for ES3.1 and proposed ES4 will be useful to discuss this proposal further. Meeting adjourned. pratap _____________________________________________ Agenda: (1) On posting the latest draft to the wiki (2) Getters/Setters (3) Decimal (4) setting up a review based on Lars' feedback on the 11 June
draft Let me know if you want to add any items to the agenda Here is the dial-in information for our phone conference at 08:00
AM (PT): Tel: 866 500 6738 (US); 203 480 8000 (intl) Participant code: 885535 pratap _______________________________________________ _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
RE: "strict mode" becomes "use subset cautious"
by Allen Wirfs-Brock-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I believe that identification of such a list is
something that we (ES3.1 and ES4) are going to have to work on together. Getting
the 3.1 draft. largely complete should be an enabler to get that started.
Resolution is also a two way street that is also going to require joint work. We’re working to get a technically complete draft out by
the middle of next week so people can start reviewing it in preparation for
Oslo. There is a fair chance that we won’t get the “formal”
specification work done for a couple for features by then. If that proves
to be the case we intend to include a summary description of the missing
features and then follow that up with spec. supplements covering those features
as quickly as we can. From: Maciej Stachowiak
[mailto:mjs@...] On Jun 26, 2008, at 1:34 PM, Allen Wirfs-Brock wrote:
At today’s ES 3.1 conference call (see http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_24_2008) we agreed to adopt the
essence of the proposal below and to use the subset name “cautious”
to referred to the set of restrictions formerly known as “strict
mode” Will ES4 also be making this change? If not, we need to add
it to the list of subset rule violations. Is anyone keeping such a list? Does
the ES3.1 committee intend to address all such issues by the July timeframe
that ES3.1 is apparently targetting? Regards, Maciej
_____________________________________________ Following up on the “Strict Mode” discussion… As I advocated on the call, I think that by selecting
“strict mode” a developer is really choosing to restrict themselves
to using a subset of the complete language. The future-proofing
issues of this relate to the possibility that there might be multiple
such subsets that a developer might need to choose among. Should there be
multiple named “strict modes” to choose among, how should they be
named, can “strictness” of a mode increase in future versions, etc? I think some of the controversy could be eliminated if we simply
eliminate the term “Strict Mode”. Instead I propose we have a
“Use Subset” directive and that we name specific subsets in a
meaningful and generally positive manner. For example, since the
motivation of most of the proposed restrictions in ES3.1 strict mode is to
provide a safer subset language I suggest that we call this subset
“safety” (or perhaps “safety1” or
“safetyA” or “safety2008” implying that in the
future different safe subsets might be defined and we don’t want to give
undo importance to this initial one). So, the first line of a “strict mode” compilation
unit would now look like” “use subset
safety” I would suggest that we actually define “use subset”
such that a comma separated list of subsets is allowed. So, if somebody
decided to define a subset that only contained the features of ES3 you might
see something like this: “use subset
safety,ES3” Since subsets are sets of restrictions, listing multiple subsets
means to take the union of the restrictions imposed by all of the listed
subsets. So “use subset safty,ES3” means that this
compilation unit may only use those features defined by ECMA 262-3 and which
are not excluded by the “safety” subset. So, assuming that
“safety” excludes use of the with statement, such a compilation
unit could not include use of the with statement nor could it include any use
of a feature that is new in ES3.1 or ES4. Future versions of ECMAScript may add exclusions to a subset
defined by an earlier version as long as the added exclusions only restrict
capabilities that didn’t exist in the earlier version. For example, ES 4
in supporting the ES3.1 “safety” subset but add to it any features
that are added in ES 4 but which are considered to be unsafe. A future version may not add exclusion to an pre-existing
subset that restricts features that existed when the original subset was
defined. For example if ES3.14 or ES5 decided that the for-in statement
was unsafe, it could not add that restriction to the “safety”
subset. However, it could define a new subset named perhaps
“safety2010” that includes all the restrictions of the “safety”
subset and in addition disallows use of the “for” statement. If a compilation unit specifies a subset that is not known to
the implementation that is processing it, that subset restriction is simply
ignored. The code in the unit is still either valid or invalid on its own merit
just like is the case when no subset had been specified. _____________________________________________ Here are brief minutes from our call. Please take a look, and let me know if you want any changes by
your EOD. I’ll upload it to the wiki and send a copy to Patrick
Charollais (ECMA) for posting on the ECMA site tomorrow night (Redmond time). Attendees Adam Peller (IBM) Sam Ruby (IBM) Mark Miller (Google) Allen Wirfs-Brock (Microsoft) Agenda On posting the latest draft to the wiki Getters/Setters |
