, ...' notation could be misinterpreted as saying that
the previous 'props' list is the first element of the new list. It should be
something like 'props ++ [...'.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
On 2010-12-23 06:01, David-Sarah Hopwood wrote:
On 2010-12-23 05:08, Brendan Eich wrote:
You seem to have problem owning up to mistakes.
*I* have a problem owning up to mistakes?
https://secure.wikimedia.org/wikipedia/en/wiki/Psychological_projection
I'm sorry, that was uncalled for. I
and/or non-writable.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
from '.')
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
and as a range operator in other languages is
sufficient reason not to use it here.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https
[] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https
-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed
at all. (In the proposal to add a @ or .# operator, it isn't.)
Hm, this looks like a pretty serious misunderstanding of the private names
proposal.
I
properties as non-Configurable, and
marking all data properties as non-Writable.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https
On 2010-12-24 00:11, David Herman wrote:
On Dec 23, 2010, at 5:03 PM, David-Sarah Hopwood wrote:
On 2010-12-23 23:55, David Herman wrote:
On Dec 23, 2010, at 4:27 PM, David-Sarah Hopwood wrote:
We don't know whether [] will be changed at all. (In the proposal to
add a @ or .# operator
On 2010-12-24 00:39, Brendan Eich wrote:
On Dec 23, 2010, at 3:27 PM, David-Sarah Hopwood wrote:
On 2010-12-23 21:02, Brendan Eich wrote:
On Dec 23, 2010, at 12:11 PM, Mark S. Miller wrote:
You've said this apples to oranges thing many times. I just don't
get it.
You've read the recent
On 2010-12-22 07:57, Brendan Eich wrote:
On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote:
On 2010-12-21 22:12, Brendan Eich wrote:
It's tiresome to argue by special pleading that one extension or
transformation (including generated symbols) is more complex, and
less explanatory
taste.
You have willfully assumed bad faith, despite clear explanations. That
certainly does leave a bad taste.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing
On 2010-12-23 00:40, Brendan Eich wrote:
On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:
What I said, paraphrasing, is that weak encapsulation favours code that
doesn't work reliably in cases where the encapsulation is bypassed.
Also, that if the encapsulation is never bypassed
On 2010-12-23 01:11, Brendan Eich wrote:
On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote:
In arguing about this, I have this bait-and-switch sense that I'm
being told A+B, then when I argue in reply against B, I'm told no, no!
only A!. (Cheat sheet: A is soft fields, B is transposed
On 2010-12-23 02:48, Brendan Eich wrote:
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field strong
encapsulation?
I meant, obviously, that inspectors
On 2010-12-23 05:14, Brendan Eich wrote:
On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote:
The constraint that the inspector be written in ES5 seems to be a purely
artificial one. All of the commonly used browsers have debugger extensions.
Nope, our little startup (mine, MonkeyBob's
On 2010-12-23 05:08, Brendan Eich wrote:
On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote:
As far as I can see, MarkM has not (at least, not on the wiki) proposed
any new syntax in this discussion that had not already been proposed in
one of Allen's proposals.
Wrong again. Allen did
.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 2010-12-21 08:27, David-Sarah Hopwood wrote:
The private names and soft field proposals are similar in the
visibility mechanisms they can simulate, but soft fields are slightly
more general. In either proposal, visibility can be restricted to a
particular lexical scope. In the soft fields
only
need one, for example:
function Point(x, y) {
var x = SoftField(), y = SoftField();
this.#x = x;
this.#x = y;
}
(i.e. 'MemberExpression .# PrimaryExpression' or alternatively
'MemberExpression [ # Expression ]')
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all relevant attribution lines.
Brendan Eich wrote:
The new equivalence under private names would be x[#.id] === x.id.
You said under private names here, but it should actually
such as
private fields.
I think it is a mistake to emphasize that, since it overspecifies the
mechanism. In the soft fields proposal, the fields are not properties,
but that makes little or no visible difference to their use.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
On 2010-12-17 06:44, Brendan Eich wrote:
On Dec 16, 2010, at 9:11 PM, David-Sarah Hopwood wrote:
On 2010-12-17 01:24, David Herman wrote:
Mark Miller wrote:
Ok, I open it for discussion. Given soft fields, why do we need private
names?
I believe that the syntax is a big part of the private
feature cannot be specified by a fairly simple desugaring
to lower-level features, then it's probably not a good feature.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss
/EvalBreaksClosureEncapsulation
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
From SecureEcmaScript proposal:
6. The top level binding of this in an evaled Program is not the
global object
David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
For many current applications, the frozen |this| object is not necessary
or desirable in global code. The essential characteristic of modules
of adding unilateral language extensions without consulting anyone,
and in particular without consulting this list.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing
Brendan Eich wrote:
On Jan 11, 2010, at 4:37 PM, David-Sarah Hopwood wrote:
Kevin Curtis wrote:
So, FF3.5 has resurrected the sandboxed eval with the second 'global'
object parameter - as the closure peeking issue has been fixed. (The second
param is a live object rather than a string).
I
Brendan Eich wrote:
On Jan 11, 2010, at 10:53 AM, David-Sarah Hopwood wrote:
Who said primordial objects are shared between modules?
Having separate copies of primordial objects for each module is not
sufficient to ensure isolation. If one module has access to some object
obj of another
scratch, not based on what a
poorly thought-out vendor extension happens to do.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https
mean that. If you can mutate
primordial objects, then there is no isolation of any module. There
may be a reduction in the possibilities for accidental interference
between modules, but that should be distinguished from isolation.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
memo...@googlemail.com wrote:
David-Sarah Hopwood wrote at 25th December:
and there is no need for a 'link' convenience function to be standardized
given that it is a 5-liner in terms of Object.defineProperty
Just have a look at the following programming code with *sweet* 5-liners:
var
I forgot the commas in the object literal:
David-Sarah Hopwood wrote:
function makeGui(doc) {
/*const*/ var title = doc.getElementById(title),
url = doc.getElementById(url),
input = doc.getElementById(input);
return Object.freeze({
get title
of Object.defineProperty.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
lookup; I don't know where you got that idea.
As for implementation, [[Class]] could be derived from some other type tag
that gives sufficient information to do such lookup, but [[Class]] by
itself is not sufficient.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
language names are very often acronyms, this looks perfectly
natural (and I think it looks fine even when the name is not an acronym).
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
Brendan Eich wrote:
On Dec 15, 2009, at 11:18 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
In ES specs and real implementations, internal methods and various
corresponding implementation hooks are called based on [[Class]] of the
directly referenced object, in contrast.
[...]
Sorry, I
be
# • The result of calling the [[GetOwnProperty]] internal method of
# proto with argument ToString(j) is not *undefined*.
(Incidentally, I don't see any errata for the published standard at
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft.)
--
David-Sarah Hopwood
that is not an array index. How and why would that happen?
And yes, I'm aware that this usage of Object.prototype.propertyIsEnumerable
implies that catchalls must virtualize it in order for a proxy to be able to
pass this test :(.
Same with Object.getPropertyDescriptor in the above.
--
David-Sarah Hopwood
to the next element), it shouldn't
be a getter.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
) is the main motivation for standardizing the format, AFAICS.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
Breton Slivka wrote:
On Tue, Dec 8, 2009 at 3:57 PM, David-Sarah Hopwood
david-sa...@jacaranda.org wrote:
snip
That would however depend on an assessment of whether browser
implementors had succeeded in implementing secure and correct
ES5-AST parsers (with a mode that accepts exactly ES5
this is validation, not parsing.
That's not entirely accurate. In implementing Jacaranda, I estimate
the split of effort between validation/parsing has been about 60/40.
ECMAScript is really quite difficult to lex+parse if you absolutely
need to do so correctly.
--
David-Sarah Hopwood ⚥ http
for such
applications and for parsers/emitters.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Environment Records.
/pedantry
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Message-
From: es5-discuss-boun...@mozilla.org
[mailto:es5-discuss-boun...@mozilla.org] On Behalf Of David-Sarah Hopwood
Sent: Friday, November 20, 2009 7:18 PM
To: es5-disc...@mozilla.org
Subject: Re: ES5 left-to-right evaluation order issues
Allen Wirfs-Brock wrote:
So, the main point
-frozen. For Data object's already
frozen can return this
Data.prototype.frozen - true when frozen, false otherwise.
I don't know why we wouldn't just use Object.freeze. It is not unreasonable
to require support for the ES5 APIs as a prerequisite for the Data type.
--
David-Sarah Hopwood
Oliver Hunt wrote:
On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
Charles Jolley wrote:
This looks like a good approach. I wonder if the Data/DataBuilder
distinction could be handled better by using the Object.freeze()
semantics. Even if the browser does not support freezing
Oliver Hunt wrote:
On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote:
Oliver Hunt wrote:
I disagree here -- i believe mutable vs. immutable data is different
from unfrozen and frozen objects [...]
Why? What would the hypothetical Data.prototype.freeze do that would be
different
ugly solutions, because the others are nasty?
Yes. Here ugly just means verbose and inelegant, whereas nasty
means having poorly understood and subtly error-prone consequences.
So ugly beats nasty every time :-)
- --
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-BEGIN PGP SIGNATURE
}
]
]
]
],
[ExpressionStatement,
[Call,
[VariableProxy,
{name:print}
],
[VariableProxy,
{name:y}
]
]
]
],
[EmptyStatement]
]
]
3
--
David-Sarah Hopwood ⚥ http
arbitrary additional
inputs depending on the context in which they are used.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
that it has, such as the get/set object literal syntax,
are taken unchanged from existing implementation precedent). I hope
that such a syntax will be included in Harmony, though, along with
more comprehensive Unicode library support.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
an implementation
were to exploit any internal optimizations it has for recognizing objects
of the same shape [*], it would indeed have to sort the keys of every
instance.
[*] Do any common implementations actually do that, other than for
packed arrays?
--
David-Sarah Hopwood ⚥ http
.)
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
...
}
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
]], are relatively
safe to override, but for others the invariants that the ES spec depends
on are quite delicate.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does allow [[Construct]] without
[[Call
://www.w3.org/Mail/Request, bounced with error 550 Unrouteable
address (state 14).
Mark, please forward this.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
Maciej Stachowiak wrote:
On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript
.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
interface for implementations
that do want to support this, but I don't think it requires changes to
language syntax. A 'runWithMoreDebugInfo(someFunction)' API would suffice.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss
-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
details (particularly memory management), and are not
suitable for wider use.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
the check that the lambda is called from the body
of the generator function is applied *after* expansion.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
. But if (0)
yield; sets a new record affecting the nature of the whole function.
A more explicit alternative is to require some kind of decoration on the
function definition, e.g. (just a straw man):
function generator foo() { ... }
--
David-Sarah Hopwood
use was as a formal parameter name, used as a flag not a
function).
Oh, right. We've been talking at cross-purposes. I assumed that you were
suggesting that 'yield' should be contextually reserved. That is what
I've been saying couldn't work due to ambiguities.
--
David-Sarah Hopwood
-- although I bet most
JS programmers don't even know that is happening.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
John Cowan wrote:
David-Sarah Hopwood scripsit:
Then the functionality of a generator can be implemented using a
process/thread that extends a list or queue constructed from
dataflow variables.
Quite so. How, if at all, do these dataflow variables differ from
Prolog variables?
Prolog
[I sent this to es5-discuss, when I intended es-discuss. Sorry for the
noise for people subscribed to both.]
David-Sarah Hopwood wrote:
Jason Orendorff wrote:
On Thu, May 14, 2009 at 12:25 PM, Mark S. Miller erig...@google.com wrote:
Given both shallow generators and lambda, I don't understand
point, which I think is a separate point
from compiler analyzability. Really, no one writes yield(...) in Python,
and extra parens hurt (I know RSI sufferers who benefit from lack of
shifting in Python and Ruby).
Yes, those are separate points that I am not arguing against here.
--
David-Sarah
Brendan Eich wrote:
On May 14, 2009, at 4:34 PM, David-Sarah Hopwood wrote:
This approach avoids any problems due to a generator being able
to interfere with the control flow of its callers.
A generator can't interfere with the control flow of its callers.
Can you give an example
?
(This is unfortunately almost impossible to search for.)
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
the outer
function's scope.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
) in the
Harmony standard library.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mark S. Miller wrote:
On Sat, May 9, 2009 at 2:32 PM, David-Sarah Hopwood
david-sa...@jacaranda.org wrote:
[...] but the AST should preserve the associativity defined in the
language spec.
But which language spec? Again, specs only traffic in observable
differences. Since ES5 does
value effectively introduce another state for a
variable to be in, though, since the behaviour is indistinguishable in
user code in ES3?
It's not indistinguishable; exactly the first arguments.length parameters
are present, regardless of whether they are undefined.
--
David-Sarah Hopwood
requires an [[InCatchall]] flag on each object.)
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David-Sarah Hopwood wrote:
Brendan Eich wrote:
[...]
I finally found time to write up a proposal, sketchy and incomplete, but
ready for some ever-lovin' es-discuss peer review ;-).
http://wiki.ecmascript.org/doku.php?id=strawman:catchalls
# Catchalls are sometimes thought of as being
then). It would make sense for that
to support querying whether a given module is available, its version,
and other metainformation about it.
--
David-Sarah Hopwood ⚥
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
Christian Plesner Hansen wrote:
David-Sarah Hopwood wrote:
If converting one character to many would cause a problem with the
reference to toUpperCase in the regular expression algorithm, then
presumably Safari and Chrome would hit that problem. Do they, or
do they use different uppercase
David-Sarah Hopwood wrote:
Christian Plesner Hansen wrote:
David-Sarah Hopwood wrote:
If converting one character to many would cause a problem with the
reference to toUpperCase in the regular expression algorithm, then
presumably Safari and Chrome would hit that problem. Do they, or
do
Waldemar Horwat wrote:
David-Sarah Hopwood wrote:
I'll repeat my argument here for convenience:
A DivisionPunctuator must be preceded by an expression.
A RegularExpressionLiteral is itself an expression.
(This assumes that the omission of RegularExpressionLiteral from
Literal is a bug
error that
could prompt semicolon insertion.
The Note takes care of this.
This is not a case where the note applies; it's essentially the same
case as given by Eric Suen. My response to him is at
http://www.mail-archive.com/es-discuss@mozilla.org/msg01331.html.
--
David-Sarah Hopwood
, not PrimaryExpression. There is no technical
difference (since Literal is only used as one of the alternatives
for PrimaryExpression), but it's just common sense that a
RegularExpressionLiteral is a literal.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es
to toUpperCase in the regular expression algorithm, then
presumably Safari and Chrome would hit that problem. Do they, or
do they use different uppercase conversions for regexps vs
toUpperCase?
If the latter, then we should allow that, and probably require it.
--
David-Sarah Hopwood
methods with callbacks take a 'thisArg' not because it is
needed or even useful, but for compatibility, because they already do
in existing implementations that provide these functions.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss
Edward Lee wrote:
On Sat, Mar 21, 2009 at 9:50 AM, David-Sarah Hopwood
david.hopw...@industrial-designers.co.uk wrote:
Why is it better to use 'this' than to simply have the callback function
capture the variables it needs?
It's nice to be able to consistently refer to the same 'this' from
embedded in a browser that is being used as a
compilation target. His post has numerous technical errors (which I'll
address separately), but this isn't one of them.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https
.
I agree completely, and particularly with points 1) and 2). There
should be very good reasons to make behaviour unspecified or
implementation-defined; here there is not.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https
. The
.name property of all function objects would be non-[[Writable]] and
non-[[Configurable]].
Whether this is actually needed, I'm not sure, but it has all of the
functional and security properties I've seen stated as desirable so far
in this thread.
--
David-Sarah Hopwood
with.
I don't see why this is an interaction between 'name' and 'toString'.
Isn't this issue independent of whether 'name' is present?
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
David-Sarah Hopwood wrote:
Brendan Eich wrote:
The utility of mutable name for anonymous functions is not at issue if
we do not define name at all on such functions -- this is the proposal
Allen and I were converging on. You can set name on such anonymous,
expressed functions to whatever
Allen Wirfs-Brock wrote:
David-Sarah Hopwood wrote:
Herman Venter wrote:
I appreciate that this proposal does not try to go all the way on
octal. I am not so sure this is a good thing or that it makes the
proposal more likely to succeed.
I wouldn't be opposed to removing octal entirely from
will be added, I think, but there is currently
no detailed concrete proposal.
Some previous discussion:
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008159.html
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https
David-Sarah Hopwood wrote:
memo...@googlemail.com wrote:
I'd like to use link(obj, target).
E.g.
a = 10;
link(b, a);
a++;
b++;
print(b);
// output: 12
That would require a catchall mechanism, allowing accesses to
nonexistent properties of an object to be handled. It's quite likely
a bug for this change to parseInt, with a test case:
http://bugs.ecmascript.org/ticket/449.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
;-)
David-Sarah Hopwood wrote:
Suppose that S is a Unicode string in which each character matches
ValidChar below, not containing the subsequences !, / or ]], and
not containing ( followed by a character not matching AmpFollower).
--
David-Sarah Hopwood
1 - 100 of 224 matches
Mail list logo
