inion. The underscores indicate nonstandard.
--
Ingvar von Schoultz
--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase, because this will easily
and elegantly prevent a
isambiguate
> value- from descriptor-getting. So:
I find inspectProperty() a little more descriptive and intuitive.
--
Ingvar von Schoultz
--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should al
it's the same for most people. Not having analyzed
all the details, it /seems/ to me that the ideal would be
that the above syntax lock and hide [[Prototype]], while a
different syntax for exotic use would allow the constructor
added freedom.
--
Ingvar von Schoultz
--- (My quirky use
result. Another, slightly
>>> longer alternative would be "retrieve".
>> What do you say to Ingvar's suggestion of "inspect"?
>
> Or (drum roll) "describe": describeProperty, which returns a property
> descriptor.
>
Another idea (with an
gt;> /be
>> _______
>> Es4-discuss mailing list
>> Es4-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es4-discuss
>>
>> ___
>> Es4-discuss mailing list
>>
ves rationales for design decisions. What's the
>>> rationale for leaving Object.extend out?
>> If the document needs to give rationales for leaving out each thing we did
>> not include, it would be quite a long document. What is the argument for
>> adding Objec
things that are marked local
(or let), and everything else gets hoisted out.
In fact I think a terminology with strong versus weak blocks
is clearer than the current terminology, where one type of
block is called block and the other is called variable object.
I'm sorry if this comes across a
Allen Wirfs-Brock wrote:
> Object.create's heritage is Doug Crockford's beget function and its primary
> purpose is to provide a more direct way to create an object with an
> explicitly specified prototype.
I think the name Object.createHeir would clarify its use bett
{
> const c:Number = 37;
> } else if (bar) {
> var c:String = "abc";
> }
> }
> ... do something with c, which is either a type, a constant, or a variable,
> and can be statically typed as either a Number or a String ...
>
> const d:c = ...
bout these, but they can be
> considered if their effects can be committed before the rest of the
> source following such a pragma is parsed. In light of all the possible
> ways before us, and the precedent in Mozilla for JS script types, the
> conclusion that opt-in versioning is infeasible or impractical needs to
> be demonstrated, not assumed.
>
> /be
>
>
> -
it doesn't enclose local variables). JSON
doesn't have any scoping blocks.
I you find the doubling abhorrent, do you find this more
palatable?
if
{ local stuff
}
if
[ no local stuff
]
This would require good syntax coloring. It wouldn't work in
ol
;
> type c = ...
> {
> if (foo) {
> const c:Number = 37;
> } else if (bar) {
> var c:String = "abc";
> }
> }
> ... do something with c, which is either a type, a constant, or a variable,
> and can be statically typed as either a Number or a
roblems that can never appear together.
The proposal that function hoist like var is completely unrelated
to {{ }}. It doesn't apply when you use {{ }} and everything becomes
let.
I'll reply about that in a separate email. And to avoid the above
mixing and confusion, I'll put it aside for
--
>
> How would you're "better block" work as a viable alternative without creating
> more work or doing what can already be done by let?
>
> Examples from http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
>
>
>
> _
blocks, which would then affect the behavior of existing definitions
> like var if one of the other definitions within the same block was a const
> or function, which would snowball into a complex mess.
Unrelated, I believe.
Ingvar
> Ingvar von Schoultz wrote:
>> I'm aston
ze that implementing it could be made that simple, the
change that small.
By the way, your translation
(function() { code })()
can also be expressed as
new function() { code }
Less parentheses!
(But I haven't explored possible drawbacks.)
--
Ingvar von Schoultz
--- (My qu
allow to drop an empty
> argument list from a function with a requirement that function { }
> always means an expression and ES3.1 would also support that, then in
> place of a block with let variables one can write:
>
> function {
>
> }();
>
> Regards, Igor
>
[EMAIL PROTECTED] wrote:
> Ingvar von Schoultz wrote:
>> [EMAIL PROTECTED] wrote:
>>> I'm trying to keep the language relatively simple.
>> You can't get away from supporting this:
>>
>> {
>> function a(){}
>> var b =
Igor Bukanov wrote:
> 2008/7/26 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>> Do you really think {{ }} appears in existing code, correctly
>> enclosing statement blocks, with the {{ and the }} placed tightly
>> together both at the beginning and at the end?
>
&g
syntax, but you can't refuse the above code and
functionality.
In other words, complexity is not a problem. ES4 can easily
choose whatever semantics people prefer.
--
Ingvar von Schoultz
--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all
Sorry about the length of this, but I'm trying to cover the
unclear things, and often I don't know which things are unclear.
Brendan Eich wrote:
> On Jul 26, 2008, at 2:07 PM, Ingvar von Schoultz wrote:
>
>> You can't get away from supporting this:
>>
&
Igor Bukanov wrote:
> 2008/7/26 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>
>> I think all of these would be unambiguous:
>>
>>{. code .}
>
> {. not work since {.0; } is a valid ES3
Oops! True indeed.
>>{: code :}
>>
>>{| code |}
Brendan Eich wrote:
> On Jul 26, 2008, at 2:06 PM, Ingvar von Schoultz wrote:
>
>> How sad! It seemed such a simple and intuitive notation!
>
> Opinions vary, but all the ones I heard at the Ecma TC39 meeting
> found it neither simple nor intuitive, and some abhorre
Igor Bukanov wrote:
> 2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>> I wonder if people would like using them.
>
> Anything that is available in a browser will be used and abused ;).
Wonderful! My notation will become popular! :-D
>>> Any of this can be
Mike Shaver wrote:
> On Sun, Jul 27, 2008 at 7:51 PM, Ingvar von Schoultz
> <[EMAIL PROTECTED]> wrote:
>>
>> Igor Bukanov wrote:
>>> eval('[]') is a valid and, in fact, useful ES3 code. Similarly eval('{[]}').
>> Yes, and by my rules
Igor Bukanov wrote:
> 2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>> If [...] is preceded by =, or enclosed in ( ), or in some other
>> position where you can't have a block, it's a literal. If it's
>> a literal it must contain a comma-separated l
Richard Cornford wrote:
> Ingvar von Schoultz wrote:
>> Igor Bukanov wrote:
>>> 2008/7/28 Ingvar von Schoultz wrote:
>
>>>>> Any of this can be a valid ES3 code as [] always means an
>>>>> array literal.
>>>> I get the impression t
Mike Shaver wrote:
> On Sun, Jul 27, 2008 at 9:15 PM, Ingvar von Schoultz
> <[EMAIL PROTECTED]> wrote:
>> Does it matter whether it's interpreted as an empty block or
>> an empty discarded array?
>
> It's not always discarded:
>
> js> var x
Richard Cornford wrote:
> Ingvar von Schoultz wrote:
>> Richard Cornford wrote:
>
>>> {
>>>1,2,3,4,5
>>> }
>>>
>>> - is a valid ES 3 Program (even if a pointless one); A Block
>>> statement containing an Expression statem
Igor Bukanov wrote:
> 2008/7/28 Ingvar von Schoultz <[EMAIL PROTECTED]>:
>> {{ }} is just the same as a scoping function used on ES3:
>>
>>(function() { code })()
>
> As Lars Hansen has pointed out any proposal for a shorthand for
> (function() { code
Brendan Eich wrote:
> On Jul 26, 2008, at 2:06 PM, Ingvar von Schoultz wrote:
>
>> How sad! It seemed such a simple and intuitive notation!
>
> Opinions vary, but all the ones I heard at the Ecma TC39 meeting
> found it neither simple nor intuitive, and some abhorre
hly awkward and kludgey construct
that people use only because there is no other way to do it. The
functionality is necessary, so you are forced to use it, but if
it weren't so necessary you wouldn't use that kludge.
> (especially for experienced developers
> with bad habits from othe
Ingvar von Schoultz wrote:
> In theory {{ code }} could be converted to a function that
> returns information about whatever break/continue/return was
> reached. But I'd be quite surprised if that is easy.
>
> Something like this. Written with syntax sugar:
>
>
For a description of the translation, see the quoted text below.
Ingvar
Ingvar von Schoultz wrote:
> Ingvar von Schoultz wrote:
>> In theory {{ code }} could be converted to a function that
>> returns information about whatever break/continue/return was
>> reached.
>
> I n
ntroduced, it
should probably use a different keyword.
--
Ingvar von Schoultz
--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase, because this will easily
and elegant
enabled, for compatibility and to satisfy
those who prefer the let and var combination.
--
Ingvar von Schoultz
--- (My quirky use of capitals in code comes from my opinion that
reserved and predefined words should all start with lowercase, and
user-defined should all start with uppercase
governing for(), while() or switch() goes here.
{
// The code between {{ }} goes here.
}
return _EndOfBlock;
}).call (this, arguments);
if (_ReturnValue != _EndOfBlock)
return _ReturnValue;
Ingvar
Ingvar von Schoultz wrote:
> The sim
hat I could have explained
some of the things below better, making them clearer. Should
I post better explanations?
I'm really very curious about that rebinding problem! Both
what it means, and where I seem to propose it (or actually
propose it, inadvertently).
Ingvar
Ingvar von Scho
Ingvar von Schoultz wrote:
> Any variable
> that you declare anywhere will simply splash out of any { } and
> attach itself to the nearest surrounding {{ }}, becoming visible
> in the entire space between them.
Int this splashing out of { }, function declarations are
a special ca
Thank you for your clear and to-the-point reply. I'll
make a /much/ shorter response.
For some reason I find brevity very difficult to attain.
But I'll discipline and restrain my verbosity.
Ingvar
Brendan Eich wrote:
> On Jul 30, 2008, at 3:13 PM, Ingvar von Schoultz wrote:
>
Very brief!
Brendan Eich wrote:
> On Jul 26, 2008, at 2:07 PM, Ingvar von Schoultz wrote:
>
>> You can't get away from supporting this:
>>
>> {
>> function a(){}
>> var b = a;
>> }
>>
>> ES4 is planning
tional,
it protects against capture problems. It's a minor limitation, certainly
not a showstopper.
--
Ingvar von Schoultz
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
so much,
they prefer having no {let} functionality at all in ES3.1.
--
Ingvar von Schoultz
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
;s an alternate syntax, more logical but less readable
in my opinion:
var x = myDict .:enumerable .someName;
var x = myDict .!enumerable .toString();
--
Ingvar von Schoultz
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozill
if (this.hasOwnProperty(x))
> yield x;
> }
> }
>
> for (var x in myDict.own()) ...
>
> -Yuh-Ruey Chen
>
> On Fri, Aug 8, 2008 at 1:07 PM, Ingvar von Schoultz
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
On the page http://www.ecmascript.org/docs.php three documents
are marked "New!", but the documents are from October and November.
--
Ingvar von Schoultz
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/li
46 matches
Mail list logo
