On Jun 22, 2007, at 2:20 PM, Peter Hall wrote:
> I can't see much about this on the wiki export, and it is barely
> touched on here:
> http://www.mozilla.org/js/language/es4/core/
> classes.html#superconstructor
That's way out of date, it goes back to the post-Edition 3 period
where Waldemar H
On Jun 22, 2007, at 3:11 PM, P T Withington wrote:
> I've always wondered what the point of carrying over C++'s
> constructor syntax was.
Ignoring the old pre-historic ES4 spec cited by Peter, I have to
apologize again for:
http://developer.mozilla.org/es4/proposals/nullability.html
being out
Functions are objects (instances), not types. Any new F given
function F(){} must return an Object, as in ES1-3.
You can write function types of course, they are structural types:
type F = function (int, double, string):Object;
The usual subtyping rules apply, with sane extensions for optiona
lable types for class variables that must be initialized.
Asking a question that smuggles your (unjustified) conclusion that
this particular corner case is "baroque" is no fair. Let's define
baroque carefully, without emotion ("hate") and whipping-devils (C++).
/be
>
&
On Jun 26, 2007, at 6:32 PM, Graydon Hoare wrote:
> The committee's feeling was that definite-assignment analysis -- what
> you're describing -- is too expensive, especially for lightweight
> compilers. It might be that any lightweight compiler is actually going
> to run in standard mode all the t
On Jun 26, 2007, at 9:36 PM, Peter Hall wrote:
>> Automatic inference of the default ctor signature and default
>> super-call
>> from the superclass would be fine by me. I'm not sure what other
>> people
>> think. It'd break AS code.
>>
>
>
> I don't think it would break AS code. The only plac
On Jun 26, 2007, at 6:58 PM, Brendan Eich wrote:
> The bias was against definite assignment analysis being required for
> strict mode, never mind good old standard mode, which can as Graydon
> notes detect uninitialized non-nullable properties the hard way at
> runtime, but bef
> While I see that it can be useful, I remain concerned that this will
> seem confusing to novices. Why do I need that colon? What does "x=x"
> mean? Why did I get the wrong result when I did the following, which
> looks a lot like the above?
>
> // novice error 1
> class C {
> function C(x
[Jumping in on one point only, I'll hope to help Lars get back to
vacation so he can reply in full later :-P]
On Jun 27, 2007, at 12:00 PM, Peter Hall wrote:
>> For JS, this means
>> having a straightforward compiler that performs the minimum amount of
>> analysis, incroporating quick-and-dirty
On Jul 2, 2007, at 9:21 AM, Kris Zyp wrote:
It appears (at least in the reference implementation) that one
there is an object that has a delegate object that is a typed
object, that overwriting members in the top instance is sometimes
not possible. For example:
class C { var x : String; }
On Jul 9, 2007, at 12:10 PM, Jeff Dyer wrote:
class C { var x : String; }
c = new C;
function F() {}
F.prototype=c;
f = new F; // f.__proto__ = c
f.x =4;
If you do this c.x now equals "4", that is the value is not set
in f, but it goes up the prototype chain and sets 4 into x (and
does impl
On Jul 9, 2007, at 2:19 PM, Jeff Dyer wrote:
See my comments above. There is no need for copy on write
fixtures, just a plain old expando on ‘f’ for ‘x’.
Ok, I see your point.
If you want type guarantees, use classes.
Rather, use classes or structural types only, not constructor
functi
On Jul 9, 2007, at 3:22 PM, Jeff Dyer wrote:
On 7/9/07 2:42 PM, Kris Zyp wrote:
It seems to me that transfering bound methods to the function
instances makes the situation equally confusing:
Now if write:
class C { var x : String; function m() : String { return this.x }}
c = new C;
function
On Jul 9, 2007, at 4:16 PM, Brendan Eich wrote:
> I think we have only two courses:
>
> 1. Kris's proposal to make F construct instances of C. If C is not
> dynamic, these instances can't be decorated with expandos by (new
> F) or its callers.
>
> 2. Y
On Jul 9, 2007, at 4:32 PM, P T Withington wrote:
> On 2007-07-09, at 19:16 EDT, Brendan Eich wrote:
>
>> Having thought about 1 more, I'd like to point out that it's *not*
>> what ES3 does:
>>
>> js> function F(){}
>> js> F.prototype = d
On Jul 9, 2007, at 4:40 PM, Brendan Eich wrote:
>> And it has burned me that I could not do that. I wanted to write an
>> 'annotated string' and couldn't because of exactly this restriction.
>> Will I be able to subclass built-in types?
>
> Subclass, yes
On Jul 9, 2007, at 4:51 PM, Kris Zyp wrote:
> You are right, it doesn't work for a Date, but it does work on an
> Array.
Only if you don't call toString or toLocaleString.
Most Array and String prototype methods are intentionally generic.
Too bad we didn't generalize this all over the place
On Jul 9, 2007, at 9:09 PM, Kris Zyp wrote:
> I think it seems worth considering what a programmer is intending
> if writes
> a function and defines a prototype for it. This is an explicit
> action to
> create objects that inherit from the prototype object. If a user has
> specifically written
On Jul 10, 2007, at 8:21 AM, Kris Zyp wrote:
> Because it's possible to violate the type constraints on fixtures in
> the non-subclass object created by the function constructor?
> Not if the instance of F is a instance of C.
>
> 1. Classes do not constrain types, have to check everything...
>
> C
On Jul 17, 2007, at 8:56 AM, Jason Orendorff wrote:
> On 7/17/07, Garrett <[EMAIL PROTECTED]> wrote:
>> I found this example:
>> http://www.mozilla.org/js/language/es4/rationale/
>> miscellaneous.html#typed-arrays
Garrett heard this, but just so the list knows: These old documents
are being mo
On Jul 10, 2007, at 9:20 AM, Kris Zyp wrote:
>> The class methods can't be extracted or called without this
>> binding to
>> the object from which they were extracted or in which they were
>> found, so
>> there's no type check. From the reference implementation:
> I thought we had agreed tha
On Jul 21, 2007, at 7:13 AM, Kris Zyp wrote:
> So does this mean that the verdict has been reached for whether or
> not new
> objects from function constructors can be classes?
I pointed out that ES3 does not do what you seem to want here
(functions as auxiliary constructors for classes). In
On Jul 23, 2007, at 10:23 AM, [EMAIL PROTECTED] wrote:
> In the public Date/time proposal, the Date.parse static method
> returns a Date. This is a bit odd, because the current javascript
> Date.parse method returns a number (nr. of ms since epoch). Is this
> by design?
That's a mistake, wh
I can take maximum blame for advocating Dict over Dictionary, based
on brevity and the Python type, transliterated appropriately
(capitalized, I mean ;-).
But Hash is just as good by that crude metric.
We'll have another straw poll. Hash was mooted early on, but then
Dictionary stuck, and l
See Lars's post today. It's a parameterized type. So you can map
however you please: Dict. or even Dict.<*,*>.
/be
On Jul 25, 2007, at 10:51 AM, P T Withington wrote:
> On 2007-07-25, at 13:36 EDT, Brendan Eich wrote:
>
>> We'll have another straw poll. H
Same as ever (backward compatibility): NaN.
/be
On Jul 28, 2007, at 8:19 AM, [EMAIL PROTECTED] wrote:
> On 7/23/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Jul 23, 2007, at 10:23 AM, [EMAIL PROTECTED] wrote:
>>> In the public Date/time proposal, the Date.parse sta
On Jul 28, 2007, at 11:21 AM, Lars T Hansen wrote:
Date.parse("2007-07-28")
SpiderMonkey:
js> Date.parse("2007-07-28")
NaN
We've never had a bug filed asking for this to work because it works
in IE (does it? I can't test atm). But anyway, Lars is right in
general; my answer was based on
On Jul 30, 2007, at 8:54 AM, Garrett Smith wrote:
> [overquoting deleted]
> var stuff = new HashTable.();
>
> stuff.add( "one", 1 );
s/add/put/
> stuff.hasOwnProperty( "one" ); // false.
> stuff.one;// undefined.
> "one" in stuff; // false.
Right.
> if( "one" in stuff.keys ) stuff.get( "one"
On Jul 31, 2007, at 5:41 AM, P T Withington wrote:
> Indeed. I was suggesting that the spec was broken; that it meant to
> prescribe an optimization to avoid unnecessary closures, but that it
> got it wrong (perhaps because it overlooked the mutability of the
> function object itself?). Surely b
On Jul 31, 2007, at 12:49 PM, Won wrote:
> Greetings (my first post) --
>
> I'm pretty excited about the proposed changes coming up for
> ECMAscript. "let" in particular seems overdue. For better or worse, I
> have a C++ programming background, and one of the idioms that I find
> useful every day
> On 2007-07-31, at 17:34 EDT, Brendan Eich wrote:
>
>> We are now planning to automate close for all iterators, not just for
>> generators, when started from a for-in loop, so you could write your
>> own object implementing the iteration protocol, and avoid the
>> gene
Great questions. The proposal has evolved a bit, so please forgive
the moving-target nature of the page available now at
http://wiki.ecmascript.org/doku.php?id=proposals:program_units
(BTW, this is the new and as far as I know world-readable location of
the dokuwiki we've been using for propo
On Aug 13, 2007, at 5:32 AM, Peter Hall wrote:
> I was just reading the Self type proposal for the first time
> (http://wiki.ecmascript.org/doku.php?id=proposals:self_type).
Cormac should reply authoritatively since he's the author of that
spec, but I'll have a go.
> How should a compiler hand
On Aug 13, 2007, at 1:59 PM, Peter Hall wrote:
>>> Or can't Self be used outside of the sorts of usage found in the
>>> proposal examples?
>>
>> That's it.
>>
>
> In that case, I think it needs to be clearer about how the syntax can
> be used.
No doubt the proposal needs to be clearer to become a
On Aug 14, 2007, at 10:10 AM, liorean wrote:
>> Peter Hall wrote:
>>> type B = {b:Self};
>
> On 14/08/07, Cormac Flanagan <[EMAIL PROTECTED]> wrote:
>> Yes, I think this should be fine.
>
> I'm all for allowing recursive structural types e.g. for use as binary
> trees or linked lists.
>
> type
On Aug 14, 2007, at 12:46 PM, Nicolas Cannasse wrote:
> Have you not considered having a two-level type spec ? One for
> compile-time and one for runtime ? If I'm not wrong, Java did that
> with
> generics.
We do not want a profiled or segmented specification, apart from the
optional strict m
On Aug 16, 2007, at 10:42 AM, Lars T Hansen wrote:
> On 8/16/07, Stefan Gössner <[EMAIL PROTECTED]> wrote:
>> Hello,
>> here are my first questions after following the list quite a while.
>>
>> 1. I really like the array slice syntax [start:end:step] described in
>> http://developer.mozilla.org/es
On Aug 16, 2007, at 11:42 AM, Dave Herman wrote:
>> Dave Herman's analysis is on the wiki, but for some reason I'm
>> getting an error trying to access the relevant page [3].
>>
>> ...
>>
>> [3] https://wiki.ecmascript.org/ECMA/wiki/doku.php?
>> id=discussion:classes_as_structural_types_with_brand
On Aug 17, 2007, at 2:47 PM, Garrett Smith wrote:
> It would be nice to have Array literal syntax declare it's ArrayType
> before the declaration of the array.
>
> For example:
>
> 1. var x : Array = [ "foo", "bar", document.title,
> getAnotherString() ];
Array is not a parameterized type. If i
On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:
> what is the difference between x1 and x2?
>
> class A {
>const x1;
>static final x2;
You need a var before x2. Also you can't add final except before
classes and methods (the reference implementation currently parses
'class A { stati
This has come up on this list before; please see the archive:
https://mail.mozilla.org/private/es4-discuss/2007-January/thread.html
(the "inheriting statics" thread).
Also, what section 9.2.7 do you mean? Could you cite the URL of the
document containing that section? Thanks,
/be
On Aug 17,
On Aug 17, 2007, at 3:37 PM, Brendan Eich wrote:
> On Aug 17, 2007, at 1:10 PM, Garrett Smith wrote:
>
>> what is the difference between x1 and x2?
>>
>> class A {
>>const x1;
>>static final x2;
>
> You need a var before x2. Also you can'
On Aug 18, 2007, at 10:13 AM, Garrett wrote:
> liorean wrote:
>>> What would be the benefit of a class having a prototype over
>>> 9instance
>>> properties/methods?
>>
>> Prototype properties can be shadowed by instance properties without
>> being changed, prototype properties are fallbacks if t
On Aug 18, 2007, at 1:51 PM, Garrett Smith wrote:
> But these methods are also bound, right?
Yes, good point -- I left out that further detail. |this| always
refers in a method to the instance from which the method was called
or extracted.
> In current coding conventions, many programmers (i
Hey Kris, Simon; a few comments:
On Aug 19, 2007, at 9:45 PM, Kris Zyp wrote:
>> where a filter might be used which have quite different needs: in
>> the case
>> of temporary/internal keys scattered in an object, it might be
>> easier to
>> just specify those keys and be done with it
> Specif
On Aug 20, 2007, at 7:57 AM, Kris Zyp wrote:
>> question arises: How would ad-hoc transient properties be set or
>> initialized in any old object?
> With classes being available, why not provide a pathway for
> developers to
> define transience correctly in proper OO manner that would be
> ser
On Aug 20, 2007, at 2:14 PM, Garrett Smith wrote:
> In ES3, i use this in context of a function instance.
>
> A = function A () {
>
> }
> A.instances = { };
> A.getById = function getById( id ) {
> return ( this.instances.hasOwnProperty( id ) && this.instances
> [ id ] ) ||
> ( this.instanc
wise it's too
> easy to miss the fact that a method is static.
>
> Another way to state this: most programmers new to JS struggle with
> figuring out what "this" refers to in a given context. Adding yet
> another situation in which "this" could be this or
On Aug 21, 2007, at 1:24 AM, zwetan wrote:
> +1 for being able to set the attributes
>
> but I think we should not add a TRANSIENT attributes for ES3,
> DONTENUM should be enought and backward compatible
See http://wiki.ecmascript.org/doku.php?id=proposals:enumerability
/be
On Aug 21, 2007, at 1:36 PM, zwetan wrote:
> On 8/21/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Aug 21, 2007, at 1:24 AM, zwetan wrote:
>>
>>> +1 for being able to set the attributes
>>>
>>> but I think we should not add a TRANSIENT attrib
We must keep DontDelete and ReadOnly invariant. See my reply to zwetan.
/be
On Aug 21, 2007, at 2:16 PM, Kris Zyp wrote:
>>> but I think we should not add a TRANSIENT attributes for ES3,
>>> DONTENUM should be enought and backward compatible
>>
>> See http://wiki.ecmascript.org/doku.php?id=propo
On Aug 22, 2007, at 12:20 PM, Kris Zyp wrote:
> Always invariant? What's wrong with being able to turn on ReadOnly,
> but not
> turn it off? Seems I recall seeing code in Rhino that already
> behaved that
> way...
> Kris
Turning off is the problem for integrity, but turning on is a pain
for
On Aug 22, 2007, at 2:17 PM, rasmus ekman wrote:
Just an arbitrary newbie question...
I note that the updated UnaryExpression BNF
codifies part of the behaviour of ES-262 implementations:
UnaryExpression ->
PostfixExpression
| delete PostfixExpression
| void UnaryExpress
That's partial application, not currying. No one has proposed its
standardization; lots of Ajax libraries implement it much as you show
below. The ones I've looked at play their own custom variations on a
theme, so wouldn't all be subsumed by a standard.
/be
On Aug 28, 2007, at 2:20 PM, Pet
On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:
> On 8/26/07, Garrett Smith <[EMAIL PROTECTED]> wrote:
>> Back to "caller"...
>> "caller" is on the prototype in Mozilla.
Not lately:
js> function f(){ return f.hasOwnProperty('caller')}
js> f()
This is a SpiderMonkey REPL based on code going int
On Sep 3, 2007, at 7:10 PM, Brendan Eich wrote:
> On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:
>
>> On 8/26/07, Garrett Smith <[EMAIL PROTECTED]> wrote:
>>> Back to "caller"...
>>> "caller" is on the prototype in Mozilla.
>
> Not
ES embeddings exist where URIs make no sense, so it's not a good
candidate for the core standard. But we expect the burgeoning Ajax
ecosystem to keep on burgeoning (http://www.answers.com/main/ntquery?
gwp=13&s=burgeon), and make good use of shared library hosting
arrangements such as those
On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=57048
>
> In this bug, dated 2000, Brendan and David agreed that
> isPropertyEnumerable should check the prototype chain.
That was a long time ago, and while David Flanagan carries a lot of
weight w
On Sep 10, 2007, at 1:21 PM, liorean wrote:
> On 10/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> Either reflect the __proto__ (read-only, please) property as some
>> implementations do, or hardcode the prototype structure and code your
>> propertyIsEnumerable t
On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:
> And my point was that it appears to duplicate functionality of
> hasOwnProperty in a differently named method.
The two functions are different:
js> var Op = Object.prototype;
js> Op.foo = 42;
42
js> print(Op.hasOwnProperty('foo'), Op.propertyIs
On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:
> I think this is what Garrett is referring to:
>
> js> function f() {}
> js> f.prototype.foo = "blah";
> blah
> js> var x = new f();
> js> print(x.propertyIsEnumerable("foo"));
> false
> js> for (var n in x) print(n);
> foo
>
> And I have to agree with
On Sep 11, 2007, at 1:47 PM, Kris Zyp wrote:
> __proto__ breaks abstraction boundaries in the language -- it's just
>
> Hiding for the sake abstraction is more valuable than introspective
> visibility? I disagree, at least with JavaScript, IMHO JS's
> introspective nature is one of it's greate
I am not looking to make trouble here, believe me, but I want to
point out two things that could help David's case:
1. JS regexps were modeled by me (to lwall's horror ;-) on Perl
regexen. Here's what perl (5.8.8) does:
$ perl
"aaab" =~ /(a\1)+|b/;
print "$& ($1)\n";
b ()
It's no surprise Ja
On Sep 13, 2007, at 7:23 PM, Dominic Cooney wrote:
> I notice that the normative grammar* doesn't mention SeaMonkey's catch
> (identifier if expr) syntax for filtering exceptions. Is that
> deliberate?
Yes, that was a SpiderMonkey (not SeaMonkey, n.b.; it may also be
supported in Rhino) extensi
On Sep 14, 2007, at 12:42 PM, liorean wrote:
> On 14/09/2007, liorean <[EMAIL PROTECTED]> wrote:
>> Maybe you don't. But almost all regex implementations that implement
>> capturing submatches that are specifically implementing the ES3
>> algorithm agree with me.
>
> s/that are specifically/that a
On Sep 23, 2007, at 8:59 AM, liorean wrote:
>> 1. The constructor property should be on the object instance
>> *created*
>> by the function.
>
> That argument I agree with. It should be on the instance and not
> the prototype.
The reason for the original prototype-owned constructor was to aff
On Sep 23, 2007, at 12:22 PM, Garrett Smith wrote:
>>> in no case is the value of (new function(){}).constructor Function.
>>
> It shouldn't be, but it is in OSX Ref Impl. (I did not build this).
>
> js> (new function(){}).constructor
> [function Function]
No, that's just http://bugs.ecmascript.o
JS1.7 shipped in Firefox 2 and it is "done". This list is for
discussion of ECMA-262 Edition 4 (ECMAScript 4, es4) features and
design decisions. See http://www.ecmascript.org/.
/be
On Sep 24, 2007, at 12:18 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Hello
Where can I post reque
On Sep 24, 2007, at 10:51 AM, Garrett Smith wrote:
> http://wiki.ecmascript.org/doku.php?id=proposals:maintenance_of_es3
>
> The docs for ES3 are gonna be updated?
No commitment from the group yet to do this.
> Including some changes to the spec?
Again no commitment yet from TG1 to pursue this.
On Oct 2, 2007, at 4:11 PM, Chris Double wrote:
> I notice the Spec page on the publically accessible wiki comes up with
> "Sorry, you don't have enough rights to continue. Perhaps you forgot
> to login?". Is it possible for this to be public? Page reference is:
>
> http://wiki.ecmascript.org/doku
On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:
>> I personally believe that the unsound, untestable/non-executable ES3
>> spec is a rathole we should avoid. The errata (which are not complete
>> by a long shot) that we have hosted at http://www.mozilla.org/js/
>> language/E262-3-errata.html wou
On Oct 9, 2007, at 6:33 PM, Brad Fults wrote:
> Hi,
>
> As far as I can tell [1] there have never been logical assignment
> operators (AND, OR) in ES and I can't access the spec on the wiki [2]
> anymore, so I don't know if they're in the spec. I don't see anything
> in the proposals section, so h
On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:
> Typechecking is a problem.
>
> typeof is limited and allows host objects to return anything. The
> problem is that some host objects return "function", for example, a
> NodeList in Safari. This is perfectly legal, according to the spec.
See http
On Oct 11, 2007, at 7:21 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
When convert null to string it is better to return empty string
then 'null' string;
var a= null;
var b= '';
b= 'test' + a; //b == 'testnull'; EXPECTED: b == 'test'
This is an incompatible change and there's no poi
On Oct 11, 2007, at 1:36 PM, Garrett Smith wrote:
> On 10/10/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
>> On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote:
>>if (it is Callable) ...
>>
> I wonder how host objects will deal with this.
>
> Will there be a
On Oct 11, 2007, at 8:02 PM, Garrett Smith wrote:
>> If you want to apply or call a non-function
>> callable, use Function.apply(callable, thisp, argArray) or
>> Function.call(callable, thisp, arg1, ...argN).
>>
> So these are equivalent?
>
> aNonFunctionCallableObj()
> Function.call( aNonFunction
On Oct 11, 2007, at 10:36 PM, Garrett Smith wrote:
> So that that's out of scope for ES4; it's OK for host objects to have
> custom behavior.
I'm afraid so, but we could say that host objects that are callable
SHOULD be functions if they appear to be functions otherwise; we
could say that all
On Oct 16, 2007, at 8:19 AM, Dave Herman wrote:
> But that's not what you proposed, is it? I understood your proposal to
> mean something more like:
>
> function f(g) {
> if (let (tmp = g())// case g():
> (tmp is RegEx ? tmp.match(x) : x == tmp))
> if
> }
>
> Dave
On Oct 21, 2007, at 11:48 AM, Jeff Dyer wrote:
>> The wrapper classes String, Number, Boolean are similar to the
>> (primitive) values they wrap, but they're not really related to those
>> value types in a type sense, and in ES4 the wrappers are of even less
>> utility than in ES3, I would say.
>>
I know of two industry-scale implementations under way, in addition
to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all
implementing ES4 in the next six to nine months. There's no reason,
zero, apart from will to do something else, why Microsoft (which has
enormous resourc
On Oct 22, 2007, at 4:53 AM, P T Withington wrote:
>> String has its uses, not just embedded in content that requires
>> compatibility: string and String inter-convert, String is non-final,
>> and the two share a prototype object.
>
> I think Dylan would have made String an open subclass of the se
On Oct 26, 2007, at 12:48 PM, Darryl wrote:
I think it'd be interesting and useful to have some
way to have units of measure as part of the structure
of a number.
See http://www.mozilla.org/js/language/old-es4/rationale/units.html
(and everyone, please help disambiguate by using "program uni
On Oct 26, 2007, at 5:11 PM, James Clark wrote:
Calling the second relationship "like" seems strange to me. An
object that stands in the strong relationship to a type is just as
like the type as an object that stands in the weak relationship.
The canonical term (both in theory and in real
On Oct 27, 2007, at 11:06 AM, Dan Scott wrote:
> Just following up on the discussion - since I've seen an
> announcement that the spec for ES4 is now closed, does this mean
> that a proposal for an addition of a standardized sprintf / format
> addition to the String object is off the table u
On Oct 27, 2007, at 8:00 AM, Scott Elcomb wrote:
Hi all,
First off, I'd like to say thanks for all the good questions and
answers from folks on the list. I haven't been here long, but have
already learned a bunch. Looking forward to ES4.
Thanks. Here's hoping ES4 as proposed is not quashed
On Oct 27, 2007, at 1:53 PM, Dave Herman wrote:
> In fact, Guy Steele gave a famous talk--at OOPSLA, no less--on the
> importance of language growth.
http://citeseer.ist.psu.edu/steele99growing.html
video: http://video.google.com/videoplay?docid=-8860158196198824415
/be
_
On Oct 27, 2007, at 3:38 PM, Scott Elcomb wrote:
> Not sure if you're active on Slashdot or not. Would you mind if I
> attached your message to the /. thread? (I won't post it without
> permission, and will mention "with permission" if it's provided.)
You could instead hyperlink to:
https://ma
On Oct 28, 2007, at 5:45 AM, David Teller wrote:
>Hi list,
>
> After reading the Outline document, I find myself wondering if
> there's
> a way to provide a type without any method for the user to manually
> create an inhabitant of that type ?
A class with a private constructor. See http:/
On Oct 28, 2007, at 2:16 PM, Robert Sayre wrote:
On 10/28/07, Mark Miller <[EMAIL PROTECTED]> wrote:
But even if you have succeeded at integrating together more good
ideas
into a coherent language design than have many previous brilliant
language designers, I have another concern: Standards
On Oct 28, 2007, at 4:39 PM, Dan Scott wrote:
> Ah, fabulous - it seems that although the term "sprintf" appears in
> the wiki, it's highlighted and therefore doesn't turn up in a
> search for the term. And I was too dumb to search for "string
> format" -- thanks for letting me know that the
On Oct 28, 2007, at 7:53 PM, Mark Miller wrote:
> I have now read the section of the overview document titled
> "Compatibility" and every embedded bold "Note:". Congratulations.
> Seriously.
Thanks. There are likely to be even fewer compatibility notes soon
(see http://bugs.ecmascript.org/ticke
On Oct 29, 2007, at 10:56 AM, Yehuda Katz wrote:
> Is there any reason browser vendors couldn't continue to ship the
> old ES3 interpreter, and make it available for
On Oct 29, 2007, at 2:05 PM, Brendan Eich wrote:
These are two of several features not in AS3, but AS3 is hardly the
ne plus ultra of JavaScript. So again I think your question is
skewed toward Adobe. Opera contributed ideas and solutions based on
its experience.
As did other members of
ave another concern: Standards bodies
should not
do de-novo design. And they especially should not foist a design as a
standard before there's a substantial track record of usage. How many
large systems have already been written in this proposed ES4
design? E
is a much smaller language th
On Oct 29, 2007, at 3:05 PM, Ric Johnson wrote:
>> bad, because if I had, you would have heard another side to the
>> story, and a vigorous debate, and then probably we wouldn't be
>> playing this "how long have you been beating your wife?" game. Which
>> I refuse to play.
>
> Um... I am not accus
On Oct 29, 2007, at 3:06 PM, Neil Mix wrote:
What would Adobe and Mozilla possibly have to make a "deal"
concerning?
Its probably the case that the head decision makers of Mozilla and
the
head decision makers at Adobe have never met each other, much less
made
a "deal".
I'll play devil's adv
On Oct 30, 2007, at 10:49 AM, Mark Miller wrote:
On Oct 30, 2007 10:13 AM, Chris Pine <[EMAIL PROTECTED]> wrote:
Yes, I read that. I am extremely doubtful that Microsoft is
suddenly so
concerned about browser compatibility for the benefit of the web.
(When
IE passes the Acid 2 test, let's
On Oct 30, 2007, at 11:37 AM, Yehuda Katz wrote:
Sent from my iPhone
Twice :-/.
Begin forwarded message:
From: Yehuda Katz <[EMAIL PROTECTED]>
Date: October 30, 2007 11:26:58 AM PDT
To: Michael O'Brien <[EMAIL PROTECTED]>
Cc: es4-discuss
Subject: Re: [TLUG]: ECMAScript ("Javascript") Vers
On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote:
> After playing with the ES4 RI yesterday, my biggest concern comes
> from the handling of various number types as compared to other types:
>
> * Literal numbers become ints, rather than Numbers. While ES4 is
> still compatible with ES3 via some
[Kris asks legitimate questions, to be answered by more than a
Microsoft spokesperson. I'm going to reply cc'ing the list, even
though there are political points here along with technical content.
The list is for discussion of ES4, and that category looks like it
must include some political
1 - 100 of 450 matches
Mail list logo
