Re: types
I'd like to relate an interesting data point from Dylan. We found that
with generic functions, where you _have_ to specify parameter type for
dispatch, and a decent type inferencer, you seldom needed to specify
types anywhere else. When people specified types on locals, often the
compiler would ignore the declaration because it already knew, or it
would complain that it would have to insert a runtime check -- often
because the programmer had underestimated the actual type.
On Aug 14, 2008, at 1:40 PM, Steven Johnson [EMAIL PROTECTED] wrote:
On 8/14/08 6:25 AM, Neil Mix [EMAIL PROTECTED] wrote:
It sounds like static type checking infers a certain
amount of hard failure, i.e. you can't run this until you fix your
code. That's not really what I'm voting for. I just want it to be
possible, somehow, to catch simple type errors very early in the
development process, and then to run the same type annotated code
unchanged in the browser.
Depends on what you mean by hard failure. If we have a function like
// n must be a numeric type
function sqrt(n) { ... }
then the ability to say
function sqrt(n:Number) { ... }
only requires that n by convertible-to-Number at runtime. (If not,
ES4/AS3
required that a TypeError be thrown.)
This does make it possible to do some static type checking at
compile-time,
of course (and the AS3 compiler can optionally do this).
Personally, I like catching stupid mistakes of this sort as early as
possible, so I tend to use type annotations everywhere I can when I
code in
AS3. Your mileage may vary.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ECMAScript Harmony
[Trimmed recipients] On 2008-08-13, at 17:26EDT, Brendan Eich wrote: One possible semantic addition to fill a notorious gap in the language, which I sketched with able help from Mark Miller: a way to generate new Name objects that do not equate as property identifiers to any string. I also showed some sugar, but that is secondary at this point. Many were in favor of this new Name object idea. Is this Name object what we old Lispers would call a SYMBOL? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: How to escape implicit 'with (this)' of a method body
On 2008-07-31, at 12:34EDT, Peter Hall wrote:
Here's my take at an example of brittleness:
var bar = 42;
class foo {
function zot () { return bar; }
}
...
class subfoo extends foo {
var bar = 'oops!';
}
(new foo).zot() = 42
(new myfoo).zot() = ?
In AS3, the reference to bar in the zot function would be bound to
this.bar
I don't follow. There is no `this.bar` in the class where zot is
defined.
so, even in the subclass, there is no ambiguity and both
cases would output 42. I assume that ES4 would follow this behaviour.
The fragility is more likely to be in the opposite situation, where a
method in a class intends to access a global variable, but the
superclass has declared it too.
That was my original example, which would also exhibit fragility if
the superclass is developed/evolves independently. In either case,
the fragility stems from the implicit (unreformed) `with this` in
method bodies.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: How to escape implicit 'with (this)' of a method body
On 2008-07-29, at 01:19EDT, Brendan Eich wrote: On Jul 28, 2008, at 10:05 PM, Jon Zeppieri wrote: The original code used without (this), not with, which I took to mean avoid instance properties shadowing globals. Indeed. Perhaps I was being too clever in my pseudo-code. If you read the original as with, then there is no such problem. But if you construct a problematic case using 'with' and dynamic properties, then I concede that 'global' could be shadowed. This is a reason to avoid 'with'. In the ES4 proposals last sent out, you could always use __ES4__::global if you really wanted to avoid conflicts -- unless someone perversely added '__ES4__' as a dynamic instance property. There's no solution to this problem other than reserving at least one name, and we can't do that compatibly. We could reserve __ES4__ in version-selected ES4 mode, but that seems unnecessary. I guess this is considered a small penalty to pay in exchange for adding the magical instance scope to methods (which O-O programmers seem to expect these days). Something we'd regret more if we had multi-methods, perhaps... ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Questions about setters
Can I override a setter? Can I call the setter I override using
super? How exactly?
class foo {
var barstate;
function set bar (value) { barstate = bar }
function get bar () { return barstate }
}
class annotatedFoo {
override function set bar (value) {
note('setting bar');
// how do I call my super?
super['set bar'](value);
}
override function get bar () {
note('getting bar');
// how do I call my super?
return super['get bar']();
}
}
Can `super` by itself mean call next method? That would seem like a
useful shortcut, and avoid the question of how you call a method with
a space in its name.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: getter and setter inheritance
On 2008-05-09, at 12:46 EDT, Lars Hansen wrote: (One bike ride and one cup of coffee later.) Clearly there is a difference between class/interface inheritance on the one hand and prototype inheritance on the other. In either case I think the introduction of a setter and/or a getter in a context introduces definitions for both in that context, essentially a special property that holds a getter/setter pair. A missing getter/setter is generated (that's what ES4 specifies now.) That means that in prototype contexts, if an object has a getter or a setter for a field, the prototype will never be searched for the missing half. In a class context, getters and setters can be overridden because the class instance only has the one special property with the getter/setter pair, and the values in that property depend on the class that the instance is an instance of. So different classes have different pairs. (I've only been to spin class, but I've had 1 coffee and 2 teas.) When A missing getter/setter is generated, what is its functionality? Does it just error? Can I call a super getter/setter method (I hope)? What is the syntax for that? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: defineProperty/getProperty design sketch
On 2008-04-23, at 18:35 EDT, Brendan Eich wrote: The StrawName column contains some proposed names for the combinations or N/A where the combination is nonsense. These flag-bit- combination names do not always add clarity compared to |'ed flag-bit manifest constant names, IMHO. I have to admit, those don't clarify it for me either. I'm trying to understand: what would I say in a class attribute declaration to get the corresponding properties. If the name were mnemonic for that, it might help. If there is no way to get the corresponding properties with a class attribute declaration, why would we support doing so dynamically? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
[Coming late to the party] On 2008-03-13, at 12:47 EDT, Lars Hansen wrote: function __createProperty__(name:EnumerableId, dontEnum:boolean=false, dontDelete:boolean=false, readOnly:boolean=false): void If I did my math right there are 8 possible flag combinations, but only 6 make sense. Why not a single parameter that is a member of an enumeration? Maybe the enumeration values could be named mnemonically to match the ES4 declarative syntax? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Dynamic class default (was Re: Class method addition...)
On 2008-04-07, at 12:25 EDT, Lars Hansen wrote: But there is a mixture of constrained and unconstrained defaults in our current choices FWIW, Dylan used only sealed/open for classes and methods and had the interesting default that classes and methods were open within a module (the equivalent of a package, if we still have them) but sealed outside the module unless explicitly declared otherwise. To put it in implementation terms, you don't burden the programmer with annotating code that the compiler can clearly analyze to determine intent, but you also let the complier make optimizations that would be painful or impossible to make in a linker. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Dynamic class default (was Re: Class method addition...)
I'm late to the party here, but agree 100% with Steven's point that a language cannot create security. In Dylan, we called the need to declare to get dynamic-ness pay as you go. The programmer is made aware, by requiring a non-default declaration, that the feature asked for costs more. If you're counting votes, I vote for not dynamic by default. But my reason is performance, not security. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Name
On 2008-03-20, at 23:07 EDT, Lars Hansen wrote: Names depend on object identity insofar as some namespace values are equal only to themselves. I don't know how serialization is a problem that figures into this, though clearly some namespaces values can't be printed and then reconstituted in the language. Maybe the question is: Why do we need un-interned Names? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object initializers
I can ask `o[f] !== undefined` to determine if a defined property named `f` exists in `o`, whether `f` is a fixture or not, correct? If I only have `o`, is there a way for me to detect whether `f` is implemented as a getter in `o`, or is that completely invisible to me? On 2008-03-20, at 19:42 EDT, Lars Hansen wrote: I've attempted to sum up everything we have decided about object initializers (aka object literals). A short draft spec is included. Comments welcome from everyone, especially from ES4 WG members who might remember about things I've forgotten, or correct misunderstandings. --lars object-literals.html___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Error classes
+1 to Lars Error context/backTrace proposal. Can we also have something like #file and #line, so that the various Javascript translators (ours, Dojo, various compressors, etc.) can relate context back to the original source, rather than the executed source? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 2008-03-07, at 22:43 EST, Brendan Eich wrote: The goal is to find the minimum amount of mutating meta-programming sharpness for this make certain properties non-enumerable tool. If it can be done with a one-time namespace qualification step, that wins. A few comments: I am confused. I guess I thought everything was in a namespace, just that there is a default namespace that things with no explicit namespace are in. Which makes me wonder how the namespace/not- enumerable proposal will really work. I think it is absolutely right that fixtures are not enumerable. And a bug that things that would have been fixtures if you had them are enumerable in es3. It seems to me that for-in/enumerability are all about Maps, maybe now that we have Maps (and classes with fixtures), we don't have to worry about enumerability in Objects so much. Finally, for debugging, I would want to be able to find all the properties of an object, non-enumerable and fixtures included. Will there be a way to introspect like that? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Triple quoted strings
On 2008-03-06, at 02:24 EST, Brendan Eich wrote: On Mar 5, 2008, at 11:17 PM, Nathan de Vries wrote: On Thu, 2008-03-06 at 00:14 +, Peter Hall wrote: Except that it would have a few unexpected behaviours, especially around the and characters. What would those unexpected behaviours be? Here document syntax is available (and relatively standard) in UNIX shell, PHP, Perl Ruby. Python seems to be the only language that has strayed from the traditional syntax, and I'm not entirely sure why ES4 is planning to follow suite. I'm an old Unix hacker, I remember the Bourne Shell (source too, in C- gol). E4X may have given people the idea that ES4 will add even more (mis-)appropriated syntax but we aren't doing pipelines or command substitution. I don't see why we need here documents in all their glory, although I like and use them. Triple-quoted strings are simply for embedding quote and newline characters, verbatim and freely. If no one (including you Pythonistas) would find them useful then we should defer the proposal. I'm an older Unix hacker (old enough to either remember sh before the invention of heredocs, or to forget that they were there from the beginning :P), and Lisp, and Python. I'd like to see us keep triple-quoted strings. But with a simpler (tried and true?) syntax, say that of Python 'long strings'. (Which to my mind are just heredocs without a choice of delimiter.) Seems to me we just tried to be too clever parsing triple-quoted strings, leading to all those funny edge cases that started this thread. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: New Operator
Don't you want to be able to express rounding mode? And if so, do you need 4 operators? floor/, ceiling/, round/, truncate/? Oh, maybe they should be named /-, /+, /~ and /0. Yow. Is div truncate/, or round/? I can never remember. On 2008-03-05, at 18:18 EST, Lars Hansen wrote: Just \ would work if we're happy with not allowing its use at the end of a line. A little dodgy, syntactically, IMO. I've advocated \\ in the past, which by normal lexing rules would be unambiguous by the longest-token lexing rule. (/. is ambiguous, consider 3/.5.) --lars From: Michael O'Brien [mailto:[EMAIL PROTECTED] Sent: 5. mars 2008 15:06 To: Lars Hansen Cc: TNO; es4-discuss@mozilla.org Subject: Re: New Operator I'll vote for that also. It improves readability quite a bit. But is there a better operator than \? Shame // is taken. What about /. Michael Lars Hansen wrote: I have been pushing for this in the past on several occasions, but enthusiasm in the WG has been scant, unfortunately. Maybe I haven't been pushing hard enough. --lars From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TNO Sent: 5. mars 2008 14:13 To: es4-discuss@mozilla.org Subject: New Operator Is it too late to propose an integer division operator into the spec? I do quite a bit of WSH programming in both VBScript an JScript and sometimes its a bit of an irritant during a translation, it would be nice to see this operator \ available in the new ECMAScript instead of having to rely on more inefficient workarounds: VBScript: Dim result result = 19 \ 4 '(result = 4) JScript: http://www.codingforums.com/showthread.php?t=58799 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
You and Lars missed my sarcasm marks. I hope there is _not_ a shorthand. On 2008-03-03, at 12:14 EST, Brendan Eich wrote: We've talked about V~ for (V|undefined). It would have a few uses in the RI, but not enough to close the deal. /be On Mar 3, 2008, at 5:48 AM, Lars Hansen wrote: -Original Message- From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of P T Withington Sent: 3. mars 2008 13:47 To: Lars Hansen Cc: Waldemar Horwat; es4-discuss@mozilla.org Subject: Re: ES4 draft: Map On 2008-03-03, at 02:26 EST, Lars Hansen wrote: function get(key:K, default:(V|undefined)=undefined):(V| undefined) ... If V? is shorthand for (V|null), what is the shorthand for (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that expresses how I feel about a language with 'two nulls'. :P There is no shorthand for (V|null|undefined), though if V is a nullable type then (V|undefined) works just as well. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
On 2008-02-20, at 17:20 EST, Brendan Eich wrote: On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote: Is there any way this compatibility can be mitigated? I am assuming there is no conceivable way to actually replace methods ad-hoc with arbitrary functions and retain sane typing and class expectations. I'm not sure why you assume this. Latest RI downloaded from http:// ecmascript.org/ : I thought the question was about annotating class fixtures? But your reply made me think: So, built-ins cannot be classes, because they require backward compatibility? Or maybe I missed that there are sealed/class versions of built-ins (in some other namespace?) with just a thin veneer of prototype around them for back compatibility? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Function inside if statement?
On 2008-02-05, at 18:53 EST, Brendan Eich wrote: SpiderMonkey has for about a decade implemented three kinds of function forms: definitions, expressions, and statements. This is an example of the last -- it's a function definition, syntactically, except produced as a child of another statement, possibly even a block -- a position which the ES3 grammar cannot produce a function definition. Only if control flow reaches the function statement does it bind its name. This is an extension allowed by ES3 chapter 16. I would endorse standardizing this behavior. FWIW, the Openlaszlo compiler/translator extends es3 in a similar fashion to support conditional compilation. An `if` that tests a compile-time constant will be optimized away by the compiler. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
I think talking about stacks and stack overflows might be muddying this discussion. The language is a garbage-collected language and a function context (stack frame) should be subject to garbage collection just like any other object. A stack frame that is no longer 'reachable' (because it will be returned through) should be collected. A clever implementation trick is to notice this at compile time and simply reuse the frame. The use of `goto` is darn cute, and a nice way to make that assertion to the compiler and give a clue to the reader. It's a lot like `delete` though. `delete` doesn't mean that the referenced object will actually be collected, it just drops that reference. You may intend that by deleting a reference an object will be collected, but the language has no way for you to assert that. You could still argue that in strict mode the compiler should complain if a frame you `goto` out of is not going to be unreachable (and hence collected) after all (either because you don't really have a tail call, or because a closure or type error may capture the frame). But by the same token, I might like the compiler to warn me if I am allocating closures in a loop (easy to overlook). What I wonder is, why are we obsessing about this particular garbage collection problem? Because there is a clever implementation trick that solves it? Do we have other requirements on implementation's of garbage collection? Or just a general assumption that the garbage collector has to work? If I re-write my recursive tail-call algorithm as a loop that allocates a state object each time around the loop (and drops the reference to the previous state), do we require all implementations to not run out of space because I have a 'proper' bounded resource algorithm? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: super.apply(this, arguments)
Interesting. One wonders why we keep the silly fiction of naming the
constructor after the class if it is really going to show up in the
class as the `construct` method. It's always bothered me that I have
to write the class name in two places, and fix it in two places if I
change my mind, or copy/paste a class to create a new class.
But, does the construct method cause allocation? If so, it doesn't
really solve my problem, since I really only want the initialization
of the superclass constructor, not allocation.
It seems to me that what I really want is for there to be separate
ways to apply `new` (to allocate a new instance using apply) and to
apply the constructor method (to initialize a new instance using apply).
I want to be able to say:
class Foo extends Bar {
function Foo () {
super.initialize.apply(this, arguments);
I don't want to call `super.construct` because I don't want to
allocate a new instance of my superclass, I just want to run the
initialization that my superclass does.
I suppose I have to say:
Bar.apply(this, arguments);
but now I have to type not only my class name, but also my superclass
name in two places.
Or maybe we are going to be told this is yet another outdated wiki
page that is leading us astray?
On 2007-12-20, at 00:02 EST, Garrett Smith wrote:
There's a proposal that, I think, addresses that using construct:
http://wiki.ecmascript.org/doku.php?id=proposals:static_generics
Though in the context of a subclass' constructor, I don't know what
the syntax would be.
Garrett
On Dec 19, 2007 9:46 AM, P T Withington [EMAIL PROTECTED] wrote:
Is this permitted syntax in a constructor:
super.apply(this, arguments);
for the case where I want to pass all my arguments to my superclass
constructor? If not, how does one do that, especially if the
constructor I am calling from takes a ...rest arg?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
--
Monkey, so they say, is the root of all people today.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Eval-invisible let bindings
On 2007-12-07, at 05:06 EST, Lars Hansen wrote: That may in turn require heap-allocating individual captured storage cells in order to avoid capturing entire rib objects, which in its turn may cause overall slowdowns in code that does use closures. My experience is that closures are poorly implemented in current es3 runtimes because they don't do this analysis and instead capture the entire environment, making them _much_ more expensive than allocating an instance. My Lisp experience is that the compiler can warn when an 'indefinite extent' (upward) closure is being created to help the programmer avoid those (and the compiler can stack-allocate the captured state for 'dynamic extent' (downward) ones). Some languages eschew closures altogether because they are isomorphic to instances, but with explicit allocation. Personally, I find downward closures a powerful structuring tool, so I am glad we have them; but upward closures can be difficult for even the expert to spot, so I hope implementors will give us a hand there. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Anyone got an emacs mode file for es4?
javascript-mode doesn't quite cut it. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
On 2007-11-14, at 19:22 EST, Graydon Hoare wrote: (As far as I can tell -- not being a dylan hacker -- dylan doesn't even go as far as having a global sentinel type like nil) The Dylan equivalent of a nullable type is a union of your type with a singleton that acts as the sentinel. Most often a singleton of the boolean false value is used. So there is a macro `false-or(type)` that expands to `type-union(type, singleton(#f))`. This works for any type other than a nullable boolean. Because any value other than #f coerces to true in a boolean context, #f is very similar to nil. I've never known anyone to need a nullable boolean. (Although I have seen whacky es3 code that uses true/false/null as a sloppy 3-valued enumeration -- with attended bug reports when null is passed expecting it to behave like false.) I must say, coming from Dylan, es3's undefined _and_ null seem like overkill... but we're stuck with them now! ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Is ES3 good enough? Was incrementally strengthening ES3 paradigms considered?
On 2007-11-14, at 00:14 EST, Yuh-Ruey Chen wrote: Oh come on :) I was referring to the syntax of the class system, which is undoubtedly Java-esque. Lot of Java haters in the functional (no 1st-class functions!) and scripting (too verbose!) programming crowd. Pretty much everyone's first impression of the class system in ES4 is that Java is being merged into the language. Kinda like how everyone thinks that Java inherited its type system from C++ instead of Modula-3. A key difference from Java is that types are optional. There is not enough experience with es4 yet to know, but in other type-optional languages I have worked with, I did not have a Java-esque feeling of verbosity. Perhaps this is because I was coming from a dynamically- typed background, so I did not have the reaction that given types I had to declare them everywhere. Someone coming from a statically- typed background might just continue their old habits and never discover the freedom and power of leaving out unnecessary declarations. In my experience with Dylan, it worked best to only specify types to enforce contracts and to dispatch generic functions. In particular, you almost never declared the types of local variables, the compiler would work that out for you. Ideally, a type-inferencing compiler should be able to warn you when the lack of a type declaration will cause a run-time type check (safety warning) or run-time dispatch (performance warning). ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: need some clarification on compile-time type vs. run-time type
On 2007-11-12, at 02:04 EST, Brendan Eich wrote: Imagine explicit parenthese (not allowed because they mean union type, but pretend) I was just thinking how clever it was that parentheses meant both union type and expression grouping, because a union type of only one type is that type, so you could use parentheses here? x is (like T) What am I missing? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: need some clarification on compile-time type vs. run-time type
On 2007-11-11, at 00:57 EST, Brendan Eich wrote:
There are questions about exactly what strict mode analyses might be
mandated as normative if an implementation supports strict mode. This
may be clearer to Graydon and Cormac than to me, so I'd welcome their
comments. For example:
function g(a_not_null: T!) ...
function f(a: T) {
if (a !== null)
g(a); // no cast required?
}
IMO, mandating that level of analysis violates the spirit of the goal
of permitting simple compilers. You should use `type switch` if you
want to avoid the cast (and guarantee no redundant runtime overhead).
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Syntax for union types
+1 for | On 2007-11-09, at 13:21 EST, Brendan Eich wrote: As Lars suggested, we have bigger fish to fry, but we settled on union syntax quickly and were content to stay there. I'm not against | instead of , and if enough people think it's the right user interface, we could consider it again. I'm not saying it's a good use of time to fuss over this, but it's fixable if (T, U, ...) is not as good as (T | U | ...). Recall that ES4 and indeed JavaScript do not have tuples, so we want to use [T, U] for the array structural type describing a tuple of at least index 0 of type T and index 1 of type U. If we ever did add tuples, then Yuh-Ruey has a point I think: we might rather use (T | U) for union of T and U, and (T, U) -- or possibly (T, U,) to match expression syntax (which would have to be (e1, e2,) to avoid ambiguity with comma expression) for tuple type. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Possibility of standardized sprintf() in ES4?
I would be very interested in this. Have a look at our implementation (not called sprintf, but has similar goals). Our implementation has an additional goal of keeping an association between the result string and the objects it represents. Being a dynamic language, I think es4 should aspire to more than just C sprintf. http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/compiler/ LzFormatter.lzs Our source is licensed under CPL. http://svn.openlaszlo.org/openlaszlo/trunk/LICENSE.txt On 2007-10-15, at 08:27 EDT, Dan Scott wrote: Hello: I've been working on a project requiring i18n support in ES (http://open-ils.org), and it's become clear that a standard sprintf() implementation in ES would have been very useful. There are currently some open-source sprintf() implementations written in ES, but all of the ones I've looked at so far seem to either have unusual licenses or incomplete implementations (positional specifier support is absolutely necessary for i18n, for example.) http://hexmen.com/blog/2007/03/printf-sprintf/ is probably the closest thing I've found to a solution yet. For something as basic as string formatting, it would be great to be able to count on a core implementation of sprintf() (or something equivalent) in a future version of ES. Jon Udell made a comment to the effect that string formatting was a part of the TG1 wiki at http://weblogs.mozillazine.org/roadmap/archives/2006/02/ js_and_python_news.html, but I've been unable to find that section in the wiki (unless that is limited strictly to String.replace()). Is there any other interest in adding a native sprintf() (probably as String.sprintf()) to the ES4 specs? -- Dan Scott Laurentian University ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
isPrototypeOf considered useless
If the prototype property of an object is not going to be exposed, is
there going to be a way that I can tell whether or not there are
intervening prototypes?
js function objectWithPrototype (proto) { function xtor () {};
xtor.prototype = proto; return new xtor; }
js bar = { b: 2 }
[object Object]
js foo = objectWithPrototype(bar)
[object Object]
js foo instanceof Object
true
js Object.prototype.isPrototypeOf(foo)
true
js foo.__proto_ === Object.prototype
false
How can I detect that `bar` lies between `foo` and `Object.prototype`?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: New Feature to JS 1.7
I am saying that the OpenLaszlo framework implements a class system
on top of JS1 (as do many other AJAX frameworks). I don't expect JS1
to ever support this natively. As you wrote, that is what JS2 is for.
On 2007-09-27, at 08:33 EDT, [EMAIL PROTECTED] wrote:
Sorry for my English
We implement `nextMethod` with annotation on the method function
objects
When will you implement 'nextMethod'?
- Original Message -
From: P T Withington [EMAIL PROTECTED]
To: [EMAIL PROTECTED]@aldec.com
Cc: Brendan Eich [EMAIL PROTECTED]; Es4-discuss@mozilla.org
Sent: Wednesday, September 26, 2007 7:10 PM
Subject: Re: New Feature to JS 1.7
Your best bet for js1+ is to use one of the many class-like
frameworks, prototype, dojo, or my favorite, [OpenLaszlo](http://
pt.withy.org/ptalk/archives/2006/05/circles_and_arrows.html). We
implement `nextMethod` with annotation on the method function
objects.
On 2007-09-25, at 02:33 EDT, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
As js4 will support OOP natively, this feature will useless for it
but for js1.7 it will be usefull.
In js1.7 I can not call next function from prototype chain
For example:
function A(){};
A.prototype.f1= function(){};
function B(){};
B.prototype= new A(){};
B.prototype.f1= function(){ /*How call f1 from prototype A?*/}
There will be usefull to have next property:
B.prototype.f1= function() { arguments.inherit( this, arguments ); /
*use full feature to call next function in prototype chain */ };
- Original Message -
From: Brendan Eich
To: [EMAIL PROTECTED]
Cc: Es4-discuss@mozilla.org
Sent: Monday, September 24, 2007 7:29 PM
Subject: Re: New Feature to JS 1.7
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 request for new feature to JavaScript 1.7?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
__ NOD32 2547 (20070924) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
__ NOD32 2553 (20070926) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: New Feature to JS 1.7
Your best bet for js1+ is to use one of the many class-like
frameworks, prototype, dojo, or my favorite, [OpenLaszlo](http://
pt.withy.org/ptalk/archives/2006/05/circles_and_arrows.html). We
implement `nextMethod` with annotation on the method function objects.
On 2007-09-25, at 02:33 EDT, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
As js4 will support OOP natively, this feature will useless for it
but for js1.7 it will be usefull.
In js1.7 I can not call next function from prototype chain
For example:
function A(){};
A.prototype.f1= function(){};
function B(){};
B.prototype= new A(){};
B.prototype.f1= function(){ /*How call f1 from prototype A?*/}
There will be usefull to have next property:
B.prototype.f1= function() { arguments.inherit( this, arguments ); /
*use full feature to call next function in prototype chain */ };
- Original Message -
From: Brendan Eich
To: [EMAIL PROTECTED]
Cc: Es4-discuss@mozilla.org
Sent: Monday, September 24, 2007 7:29 PM
Subject: Re: New Feature to JS 1.7
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 request for new feature to JavaScript 1.7?
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
__ NOD32 2547 (20070924) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: __proto__
On 2007-09-22, at 17:52 EDT, liorean wrote: Which could be done, of course, it should be a simple thing to add that in the algorithm for [[Construct]]. But then we have the question of what to do with constructors that return other objects than that set up by steps 1 through 5 of the [[Construct]] algorithm. A constructor can return other objects, you know. You'd have to decide whether this property should be set up prior to step 6 in the algorithm or subsequent to step 7. If prior, only the original object that was created in step 1 gets it, if subsequent, return values get it even if they are not the same as the original object. Dylan has a rule that the constructor must return an object that is a subtype of the constructor. If that were enforced, I would see no reason to reset the constructor property of the returned object. Actually, I think this would be a nice and simple fix to ES3 that probably wouldn't hurt much code out there. Agreed. As I mentioned elsewhere in this thread, we do this manually in our framework for now. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: 9.6.2 - 'this' or 'super' in a static method
On 2007-09-03, at 07:41 EDT, Lars T Hansen wrote: Now I see what you mean. You would like this class to be dynamically scoped like this. Yet when we were talking earlier about this function and this generator, they are both statically scoped entities -- unlike this. And that's how I've been thinking about this class -- as static. The motivation for this function was to be able to reference the function enclosing the reference not by name, but by some mechanism resilient to name change, and similar for this generator. So I figure, why not the class. Taking this further, would not this in your class-static method capture exactly what you want to capture (except that it's illegal right now and probably used by mistake about 25% of the time?) Well, that takes us full circle... Indeed. What I wanted was a way in a class method to say 'yes, I mean `this`, and it is not a mistake'. `this class` seemed like a pretty good idea for that. But not if it is going to be static. Your solution is not quite what I had expected to do, but it will work, so I guess this is not a pressing need. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Question about joined function object of ECMA-262 3rd edition
On 2007-07-31, at 07:52 EDT, Lars T Hansen wrote: On 7/30/07, P T Withington [EMAIL PROTECTED] wrote: So, what the spec meant to say is: If the compiler writer can think of an optimization that will save time or space and not break the semantics of Javascript, they are permitted to make that optimization. :) Joining is more sinister than that and several messages in this thread have approached the problem from various angles. The worst of it is that side effects on function objects are unpredictable, as Neil Mix wrote earlier. 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 backwards compatibility should not trump correctness? You don't want to have to force users to contrive to create a closure just to be able to add properties to a function? Oh. Ha, ha. Now I understand a piece of code in our runtime that did exactly that (since removed). I think the test case you are looking for might be the SWF version 5 interpreter. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
