On 2011-04-18, at 13:48, Brendan Eich wrote:
> Do popular minifiers still not parse and insert semicolons (and remove
> newlines) as needed?
Only the broken ones! :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo
On 2011-04-15, at 21:48, Mark S. Miller wrote:
>Why dynamic scoping was
> attractive and why it turns out to be bad is one of the most important
> lessons from the history of language design.
It's a power tool, and can be misused, but it still has a
On Apr 14, 2011, at 20:48, Brendan Eich wrote:
> Seems to me Tucker was pretty clearly arguing that ?. should be explicit as
> in CoffeeScript, not implicit and inevitable via . as in AS2. That's all.
Yes. Our experience was that implicitly short-circuiting on dereferencing
undefined had benef
On 2011-04-13, at 15:23, Brendan Eich wrote:
>>
>> in my view, the operator is not "?." (i.e. "a question followed by a dot"),
>> but still just ?. The following dot is already about property accessor:
>>
>> foo.bar?.baz
>>
>> again, bar? is separated, and only after that it's accessed to `baz
On 2011-04-09, at 04:33, Peter van der Zee wrote:
> Am I missing anything? Or are there cases where labels allow you do
> something that's impossible without labels?
They let you write more literate code? I agree labels should be eschewed,
except where necessary. But sometimes, you just need t
On 2011-04-07, at 13:27, Brendan Eich wrote:
> On Apr 5, 2011, at 2:19 PM, David Bruant wrote:
>
>> What I'm worried about is the memory cost of such an implementation. The
>> current [[HasInstance]] implementation has a constant memory cost. Keeping
>> references has a linear memory cost in te
On 2011-04-04, at 12:40, Sam Tobin-Hochstadt wrote:
>> Renaming:
>> - I find this syntax slightly unintuitive: import Geometry.{draw: drawShape}
>> At first glance this would mean for me: rename drawShape to draw. "draw"
>> feels to me like the result of the import.
>
> This is based on the des
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
> We did not discuss allowing |this| to be bound otherwise, *except*
>
> #foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the outer
`this` binding into the closure? (With the hazard tha
On 2011-03-29, at 17:52, Allen Wirfs-Brock wrote:
> On Mar 29, 2011, at 1:12 PM, P T Withington wrote:
>
>> If I had a vote, it would be for a way to explicitly name the `-1th`
>> argument to a function. And I would wish for it to be available in all
>> function forms,
On 2011-03-29, at 14:19, Allen Wirfs-Brock wrote:
> I'll leave it to reader to weigh the above pros and cons. But I do have a
> closing statement:
>
> There is a decades long disagreement among designers/users of function and
> object-oriented languages. OO proponents think there is something
On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote:
> I agree entirely that it goes with the existing fixed implicit |this|
> binding -- I just think that cuts the other way. The reason we're
> having this discussion is that the existing behavior of |this| isn't
> always what you want, and is har
You wouldn't need to reset the __proto__ of result if construction and
initialization were separated, if the __proto__ of objects were only set by
`new constructor`. If `constructor.apply` did _not_ create a new object, only
initialized it according to the arguments.
[The pattern you give is e
On 2011-03-14, at 17:13, Juan Ignacio Dopazo wrote:
> I totally forgot about Object.getPrototypeOf().
On 2011-03-14, at 17:14, Jorge wrote:
> ISTM, you would just need to follow the [[prototype]] chain, like so:
Indeed. That is what I was missing. (I don't have a way to portably emulate
tha
On 2011-03-14, at 14:29, Jorge wrote:
> On 14/03/2011, at 18:32, P T Withington wrote:
>> On 2011-03-13, at 18:15, Juan Ignacio Dopazo wrote:
>>>
>>>
>>> The idea behind it was to be able to walk down the prototype chain by doing
>>> o.constru
On 2011-03-13, at 18:15, Juan Ignacio Dopazo wrote:
> @Brendan My mistake was thinking that setting enumerable to false also made
> it return false on hasOwnProperty().
>
> The idea behind it was to be able to walk down the prototype chain by doing
> o.constructor.prototype.contructor.proto... Bu
On 2011-03-11, at 18:40, Charles Kendrick wrote:
>> "These developers" didn't take a "calculated risk". They saw it worked
>> with the implementations at the time and hoped it would be so in the
>> future.
>
> That is precisely the calculated risk they took.
FWIW, OpenLaszlo does not take that r
On 2011-03-09, at 13:20, Shanjian Li wrote:
>> It doesn't specify how to print objects, except for %s, which says that if
>> the argument is not
>> a string, convert it to string using .toString().
>>
>
> If the format specifier does not apply to the argument given, it should
> raise exceptions.
On 2011-03-05, at 14:38, Christian Mayer wrote:
> Am 05.03.2011 17:31, schrieb Brendan Eich:
>> On Mar 5, 2011, at 5:41 AM, Christian Mayer wrote:
>>
>>> 1) A printf compatible format string
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:string_format
>> http://wiki.ecmascript.org/doku.ph
On 2011-02-21, at 00:47, Mark S. Miller wrote:
> But they convert to back to two different floating point numbers, at least
> on all the browsers I quickly tried.
>
>> 0.43429448190325176 === 0.4342944819032518
> false
>> 0.43429448190325176 < 0.4342944819032518
> true
>> 0.43429448190325176 > 0.
> /be
>
>
> On Feb 1, 2011, at 11:09 AM, P T Withington wrote:
>
>> [Interested bystander 2p.]
>>
>> The thing you are looking for is common in other advanced dynamic languages
>> (mostly Lisp derivatives, see
>> http://en.wikipedia.org/wiki/Ex
[Interested bystander 2p.]
The thing you are looking for is common in other advanced dynamic languages
(mostly Lisp derivatives, see
http://en.wikipedia.org/wiki/Exception_handling#Condition_systems). It is the
concept of handling the condition in the context where the condition is
signaled,
If I define an object with both valueOf and toString methods:
var color = {
valueOf: function () { return 0xff; }
,toString: function () { return 'red'; }
}
The rules of `+` result in:
color + 1 => 16711681
color + '' => '16711680'
This is because of:
> 11.6.1 The Addition
On 2010-11-23, at 14:14, Brendan Eich wrote:
> On Nov 23, 2010, at 5:19 AM, P T Withington wrote:
>
>> On 2010-11-22, at 02:37, David Herman wrote:
>>
>>> if we allowed for-in to be overloaded, I would tell people that they should
>>> deprecate the legacy fo
On 2010-11-22, at 02:37, David Herman wrote:
> if we allowed for-in to be overloaded, I would tell people that they should
> deprecate the legacy for-in and replace it with an explicit iterator such as:
>
>for (x in keys(obj))
I have learned a mnemonic for for-in: that it is iterating using
On 2010-11-22, at 14:33, Brendan Eich wrote:
> Is losing the braces really worth the added complexity?
Perhaps not. Braces are surely as good a way to denote keyword args as any
other flag. It occurred to me that there is no equivalent of object literals
in the languages I know that have keyw
On 2010-11-22, at 13:13, Brendan Eich wrote:
> That, plus the relative rarity of annotated initialisers (in my best guess --
> we can argue about this or try to estimate by adding guards to existing
> code), make me still favor (2).
The idea of guards as "adjectives" (ala C) is a non-starter?
[2p. from the Lisp world, the putative inventor of the rest/spread operator.]
In Lisp, arglists are lists instead of arrays, the operator is `.`, and
conveniently, the empty list, `()`, and Lisp null, `NIL`, are just two ways to
write the same atom. In Lisp, option B just falls out:
(f . NIL
On 2010-10-28, at 17:10, Hudson, Rick wrote:
> GC implementation
> Software stacks on multicores will need GCs to become increasingly concurrent
> and latency free. Weak maps cause concurrent GCs and additional mutator
> synchronizations. While a concurrent GC already has to do some
> synchron
On 2010-10-29, at 04:50, Peter van der Zee wrote:
> What's the use case for weak maps? What would you do with it that currently
> impossible and why is the workaround (if any) problematic enough to warrant
> a weak map implementation?
Another use case was mentioned in the "New topic regarding Pro
On 2010-10-27, at 17:09, Brendan Eich wrote:
> JS will never be as simple as Self, but with proxies and value types based on
> them, it seems we might have get very close to the "right" answer to David's
> question.
2p. from the Dylan POV: Dylan only had equality and identity (thinking Lisp
h
On 2010-09-24, at 18:11, Jorge wrote:
> So b is truly a subclass of Array, not a fake one.
I stand corrected. At some time in the past, this did not work for me.
Apparently things have improved!
Thanks.
___
es-discuss mailing list
es-discuss@mozilla
On 2010-09-15, at 14:44, Tom Van Cutsem wrote:
>> It's the easiest way though (Python e.g. uses linearization too to avoid
>> diamonds issue). The way with warning a user about naming conflicts (in
>> particular, in your implementation too) seems also good. From the other hand
>> we don't warn a u
On 2010-09-14, at 17:39, Tom Van Cutsem wrote:
> It is true that original traits are always stateless. This is not so much to
> avoid name conflicts as to avoid the whole problem of diamond inheritance
> (duplicate state inherited via different inheritance paths, cf. C++'s
> virtual inheritance).
On 2010-09-14, at 04:56, Tom Van Cutsem wrote:
> If we want to stick to reserved keywords, "implements" seems the most
> appropriate (although this similarly confuses trait composition with
> interface implementation).
Alternatively, you could repurpose the (now disparaged) `with` keyword. That'
On 2010-09-09, at 06:13, Tom Van Cutsem wrote:
> There's no mistake that dedicated syntax for traits would help users and
> implementors alike. However, while I (or others) could definitely come up
> with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that
> still wouldn't solve
On Sep 8, 2010, at 15:52, David Herman wrote:
> libraries should generally be very widely used and very stable before they
> are added to the ES standard library.
That would seem like an unfair penalty. Am I to infer classes-as-sugar OS
preferred because it _can't_ be implemented as a library
On 2010-09-05, at 10:33, Mark S. Miller wrote:
> http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
>
> Of the three straw contenders for this niche, my preference order continues
> to be
> * Traits
If I had a vote, it would be +1
> * Classes as Sugar
> * Enhanced Object Literals
On 2010-09-07, at 12:02, Brendan Eich wrote:
> 3. identical
If I had a vote, +1
Is there someplace that concisely explains the cost of just fixing `===` so I
could understand why that is not a choice?
___
es-discuss mailing list
es-discuss@mozilla.org
On 2010-07-04, at 04:09, Brendan Eich wrote:
> Likewise for hashcode: if the object's address is one-way hashed to the
> hashcode() result, but the GC moves the object, then the object will need to
> grow a field to store its invariant hashcode.
FWIW Dylan (and its ancestors) gets around this b
Coming late to the party: 'alias' might be intuitive (from it's dictionary
definition and use in filesystems as a non-preserving way to give an alternate
name).
On 2010-07-03, at 00:57, Brendan Eich wrote:
> On Jul 2, 2010, at 8:58 PM, David Herman wrote:
>
>>> Cool. I'm warming to WeakMap as
On 2010-05-15, at 11:22, Brendan Eich wrote:
>> On May 15, 2010, at 7:53 AM, David Herman wrote:
[...]
>>> FWIW, the rename on import looked "backwards" to me at first glance, but I
>>> think I can learn.
>>
>> Yeah, I'm not thrilled about how hard it is to remember which way it goes. I
>> mean
On 2010-05-13, at 19:41, David Herman wrote:
> I've updated the strawman proposals for static modules and dynamic module
> loaders and would love to get feedback from the es-discuss community.
>
> * Static modules:
>
>http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
>http:
On 2010-04-17, at 00:06, David Herman wrote:
>>> PS Still, I have my doubts about using any such mechanisms for versioning.
>>
>> The topic is not versioning in full, rather hiding properties added to
>> built-in prototypes.
>
> I had the impression Tucker was thinking about versioning, but I m
On 2010-04-16, at 14:31, David Herman wrote:
> Tucker: if the "property-nameness" attribute weren't transferrable but names
> were objects with property tables, do you think that would be powerful
> enough? Or would you want the ability to define custom constructors, e.g.:
>
>function MyCus
On 2010-04-16, at 13:07, Brendan Eich wrote:
>> Another Harmony idea: http://wiki.ecmascript.org/doku.php?id=strawman:names
>> for unforgeable property names not equated to any string. These cannot
>> collide, and with sugar to let them be used with . (not only in computed
>> property accesses
On 2010-04-05, at 17:37, Mike Samuel wrote:
> You can
> find my slides at
> file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html
> .
I'd love to see your presentation, but I can't seem to reach your home dir from
my LAN. Any chance there is a more public copy somewhere?
_
On 2010-02-17, at 18:49, Tom Van Cutsem wrote:
> As a unit of code reuse, trait composition is more flexible than class
> inheritance.
+1
On 2010-02-17, at 19:30, Mark S. Miller wrote:
> Of the three, I would rather see Tom's traits than either my
> classes-as-sugar or Allan's extended object l
st track of where Harmony is heading with classes, but do you have
any thoughts on that? Do you see you traits as an alternative to any other
class proposal, or would it be intended as an extension of classes (as the
original traits proposal was), should they ever arrive?
P T Withington
On 2010-02-05, at 18:08, Dmitry A. Soshnikov wrote:
> Scope chain (test): [
> global,
> {foo: undefined, bar: undefined},
> {foo: 20, test: function () {...}}
> ]
This is the key that I was missing, as Brendan made clear. Despite `foo` and
`bar` being declared inside the `with`, because decl
On 2010-02-05, at 17:42, P T Withington wrote:
>>>
>>> Flash 10 gives me the answer I expected. I have not tested other JS
>>> engines.
>>
>> Flash 10 bug.
>
> I will report. Thanks.
FTR, appears to be already reported as:
On 2010-02-05, at 17:25, Brendan Eich wrote:
> On Feb 5, 2010, at 2:14 PM, P T Withington wrote:
>
>> ({
>> 'foo': 20,
>> 'test': function () {
>> var f = function () {
>> alert("foo:"+ foo);
>> alert(&
({
'foo': 20,
'test': function () {
var f = function () {
alert("foo:"+ foo);
alert("this.foo:"+ this.foo);
alert("bar:"+ bar);
}
with (this) {
var foo = 42;
var bar = 21;
f.call(this);
}
}
}).test();
--
By my reading, `foo` and
On 2010-01-27, at 13:17, Brendan Eich wrote:
> On Jan 27, 2010, at 10:15 AM, P T Withington wrote:
>
>> On 2010-01-27, at 13:06, Brendan Eich wrote:
>>
>>> Anyway, we do not want to require exotic techniques. We want to allow C++
>>> implementations, whic
On 2010-01-27, at 13:06, Brendan Eich wrote:
> Anyway, we do not want to require exotic techniques. We want to allow C++
> implementations, which require constants to avoid obvious performance hits
> for no good reason. Competition will kill any browser foolish enough to take
> such hits.
That
On 2010-01-27, at 12:17, Brendan Eich wrote:
> On Jan 27, 2010, at 8:16 AM, Peter van der Zee wrote:
>
>> new ArrayMapping(arrBuf, intBits, intStart, intFinish);
>
> The WebGL use-case cannot tolerate scaling by a variable "intBits" element
> width. It wants constant (compile-time) element size
On 2010-01-26, at 13:43, Vladimir Vukicevic wrote:
> Howdy,
>
> At Brendan's request, I've just added a new strawman proposal for ES typed
> arrays to the wiki. This proposal comes from the WebGL group, which needed a
> way of efficient access to and manipulation of native machine-type arrays;
On 2010-01-18, at 15:41, Mark S. Miller wrote:
> On Mon, Jan 18, 2010 at 7:32 AM, P T Withington wrote:
>
>> In the various classes-as-sugar proposals, is there a way to test if one
>> class is a subclass of another? Is it as simple as:
>>
>> clas
In the various classes-as-sugar proposals, is there a way to test if one class
is a subclass of another? Is it as simple as:
classa.prototype instanceof classb
?
Should there be a `subclassof` operator?
___
es-discuss mailing list
es-discuss@mozi
On 2009-12-15, at 23:28, Brendan Eich wrote:
> Something more like Self, in other words. I still wonder if we can't recover
> that lost form, enable prototype-based composition as Tucker wanted, and
> banish host objects to the ninth circle of hell, in a future edition.
We can dream! :)
__
On 2009-12-15, at 13:59, Mike Samuel wrote:
> 2009/12/15 P T Withington :
>> On 2009-12-08, at 13:10, Mike Samuel wrote:
>>
>>> All true. And yet it is not uncommon. See the bottom of this email
>>> for a quick survey of a number of libraries' uses of t
On 2009-12-08, at 13:10, Mike Samuel wrote:
> All true. And yet it is not uncommon. See the bottom of this email
> for a quick survey of a number of libraries' uses of the array-like
> concept.
FWIW, Here is the (separately/simultaneously invented) definition from
OpenLaszlo:
function isArr
On 2009-12-12, at 18:14, Mark S. Miller wrote:
>> In my experience, it is always a bad idea for the GC to invoke user-code.
>>
>
> Always? E uses async post mortem finalization to implement distributed
> acyclic GC. Without some way for "GC to invoke user code", I don't see how
> this is possibl
On 2009-12-11, at 12:43, Brendan Eich wrote:
> It would be more than nice. It is important that the spec not mandate any
> particular schedule. We have seen endless over-coupling to GC implementation
> details where programmers who can hook into finalization or another GC phase
> do so for all
On 2009-11-04, at 16:27, Brendan Eich wrote:
Alas not in content script. It seems the original bug that depended
on //@line infrastructure (which is in SpiderMonkey, ready to be
used), the bug to enable //@line *only* for our browser UI
("chrome") and similar such (XBL, XPCOM component) scr
On 2009-11-04, at 15:28, Brendan Eich wrote:
On Nov 4, 2009, at 12:26 PM, Brendan Eich wrote:
SpiderMonkey, when you set the JSOPTION_ATLINE runtime option flag,
understands a comment of this form:
//@line n
//@line n "f"
Can I enable this option from my script (preferably, or Firebug as
Sure would be nifty to have #file and #line directives, now that
Javascript is the new C.
FWIW, OpenLaszlo generates annotations like so:
Filename, line, column:
/* -*- file: lpp-8534.lzx#10.7 -*- */
Same file, but line numbering needs to be reset (because output has
more or less lines cor
On 2009-09-24, at 17:56, Charles Jolley wrote:
I've been told that I could name the functions. e.g.:
ClassB = ClassA.extend({
foo: function foo() {
// ..code
}
});
Somehow that should solve my problem, though I can't really work out
how. But regardless, asking developers to name each
On 2009-09-04, at 13:24, Brendan Eich wrote:
I hope it doesn't break anything on the web. It could, because using
for-in to inspect properties and extend base objects with copies of
them is standard practice (Doug's "Swiss inheritance", search for
"Swiss" in http://www.cosmik.com/aa-october
On 2009-07-22, at 14:14EDT, Brendan Eich wrote:
We all know many ways (too many!) to support inheritance. Would it
help to pick a winner prematurely, compared to giving people sugar
for high-integrity factories, which they must write the long way in
ES5, or not at all in current JS?
On 2
On 2009-07-01, at 03:48EDT, Christian Plesner Hansen wrote:
Methods live on objects and their prototypes.
Only if you co-opt the word "method" to mean that. I would claim this
is just shorthand for "instance method". There is also "class method"
or "static method". There are other defin
On 2009-06-30, at 14:06EDT, Brendan Eich wrote:
These are nice generic functions. With type annotations or guards,
you could imagine them as adding to generic function "+":
generic function "+"(a :Point, b :Point) {
return new Point(a.x + b.x, a.y + b.y);
}
Syntax is not the point, plea
On 2009-06-30, at 01:26EDT, Brendan Eich wrote:
http://www.norvig.com/design-patterns/
+∞
The flip side of the "diffusion of responsibility" is the "solipsism
of encapsulation", which falls down as soon as there is more than one
self (or `this` :P).
__
On 2009-06-27, at 22:12EDT, Alex Russell wrote:
But this has demonstrated, to me at least, that the important
language optimizations can be done well under the hood, without
hinting. IMHO this is a good use of human capital, compared to the
alternative of unleashing pragmas and machine type
On 2009-06-24, at 11:08EDT, Brendan Eich wrote:
Most users do not know and do not care about information theory
optimality, they just want sums and differences to "work".
Don't most users really want rational numbers, plus a way to present
them to a certain level of precision?
Does making an object not extensible imply/require than the object's
prototype is also not extensible?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 2009-06-18, at 04:06EDT, Brendan Eich wrote:
Nevertheless, I'm pleased to report that our v8 folks agree that if
Mozilla does this and does not back off because of compatibility
problems, they will do so as well. Thanks for being brave enough to
jump into this pool first!
Water's fin
These two are reversed, aren't they? The const should have the getter
rather than the value?
On 2009-03-30, at 22:41EDT, Mark S. Miller wrote:
pubInstVar: {get: Object.freeze(function{return pubInstVar;}),
enumerable: true},
pubInstConst: {value: pubInstCons
On 2009-05-17, at 14:00EDT, Brendan Eich wrote:
those painful and fruitless parentheses
Sometimes those parentheses are comforting, not painful. How many
times in JS do you see:
typeof(foo)
or in C.*
sizeof(boo)
___
es-discuss mailing lis
On 2009-05-04, at 17:39EDT, Brendan Eich wrote:
On May 4, 2009, at 2:00 PM, P T Withington wrote:
On 2009-05-04, at 14:46EDT, Brendan Eich wrote:
On May 4, 2009, at 10:45 AM, P T Withington wrote:
Assuming we're allowed to speculate on futures here...
I was thinking about improving
On 2009-05-04, at 14:46EDT, Brendan Eich wrote:
On May 4, 2009, at 10:45 AM, P T Withington wrote:
Assuming we're allowed to speculate on futures here...
I was thinking about improving debug-ability by adding descriptive
names to function expressions thusly,
var myFun = functio
Assuming we're allowed to speculate on futures here...
I was thinking about improving debug-ability by adding descriptive
names to function expressions thusly,
var myFun = function "my description here" (...) { ... };
I.e., be able to use an arbitrary string as the "name" of a function
e
Worse yet, you have inspired my managers to rename OpenLaszlo 4.2.1 to
OpenLaszlo 4.3. Granted we are behind ECMA in our absolute value, but
we make up for it in total decimals. I have just now released
OpenLaszlo 4.2.0.2! Can 4.2.0.2.1 be far behind?
:)
On 2009-03-30, at 19:05EDT, Zach
On 2009-03-13, at 01:04EDT, Brendan Eich wrote:
To your point, which I addressed in different terms: we could make
Object.prototype.toString look for [[Class]].[[Constructor]].name
where [[Constructor]] is unnameable-by-script and references the
class's constructor function. This would sati
On 2009-03-12, at 18:49EDT, Brendan Eich wrote:
On Mar 12, 2009, at 1:33 PM, Brendan Eich wrote:
On Mar 12, 2009, at 3:54 AM, Tobie Langel wrote:
On Mar 11, 2009, at 21:32 , Brendan Eich wrote:
Want to help?
Sure. How?
The discussion here should focus on use-cases, which will help us
On 2009-03-12, at 19:25EDT, Brendan Eich wrote:
On Mar 12, 2009, at 2:23 PM, P T Withington wrote:
[...]
So, why can't we standardize the `constructor` property, that seems
to exist in some implementations, to actually return the
constructor of the object (and not the constructor o
On 2009-03-12, at 17:04EDT, Brendan Eich wrote:
On Mar 12, 2009, at 1:54 PM, P T Withington wrote:
But, I would very much like to see a standard way to discover an
Object's constructor, and a way to enumerate _all_ the properties
of an object. I know there is a tension between sec
On 2009-03-12, at 16:31EDT, Brendan Eich wrote:
On Mar 12, 2009, at 11:57 AM, P T Withington wrote:
[...]
Same here, but I bet I did it differently. Which makes me think
this is _not_ an area for standardization. As long as there is a
standard way to enumerate the properties of an
On 2009-03-12, at 14:28EDT, Jason Orendorff wrote:
On Wed, Mar 11, 2009 at 6:20 AM, Tobie Langel
wrote:
It is very useful to be able to specify the debugging
representation of an
object distinctively from it's toJSON or toString representation.
No doubt. I've implemented similar function
Personally, I always name my function expressions, (and don't use new
Function) so I am not presented with this dilemma. And that works
great for me except for the one runtime in the universe that makes a
hash of named function experssions...
For introspection purposes, I create an object i
On 2009-02-17, at 08:07EST, Michael Haufe wrote:
JavaScript's non-standard Sharp Variables (https://developer.mozilla.org/En/Sharp_variables_in_JavaScript
)
I had no idea SpiderMonkey was implemented in [Lisp](http://xrl.us/begjkz
)!
___
Es-discuss
On 2009-01-05, at 07:42EST, Michael Ratcliffe wrote:
I have a question about the Javascript onerror event ... I know it
is not part of the
ECMA standard and that is my point.
I would sure like to see a more comprehensive error-handling
capability in the language. Something that would let
On 2008-12-11, at 13:26EST, Brendan Eich wrote:
Is it really too onerous (upon implementors) for strict mode to make
case (1) an error?
I think Joe the Hacker would be most happy if there were a mode (it
might be called strict) where the parser would say:
"Joe, you wrote two lines of code
On 2008-12-11, at 03:21EST, Brendan Eich wrote:
Again, what problem are you solving? I hate to add it, but I mean
"real-world problem", one you can show biting deployed code on the
web, or tell a few anecdotes about. Not hypothetical problems from a
spec (ES1 had a few of those too).
My n
On 2008-12-08, at 12:19EST, Brendan Eich wrote:
But is it really worth the trouble? The C heritage, specifically
most JS hackers' training, militates against JS ever being used in
the large as an expression language.
Are you saying these new dogs are incapable of learning the tricks us
ol
On 2008-12-08, at 00:59EST, David-Sarah Hopwood wrote:
What is the advantage of this syntax over ^(a, b) {a+b}, for example?
I prefer the above, if it were unambiguous.
Ditto for P T Withington's proposal of ^{(a, b) a+b}.
The above, I think, is. Because it is currently invalid.
_
On 2008-12-06, at 00:23EST, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3
On 2008-12-04, at 15:23EST, David-Sarah Hopwood wrote:
Arguably, the problem here is that semicolon insertion is and always
was a bad idea.
That and not requiring whitespace around operators, thus taking away a
huge domain of possible multi-symbol names (such as := for
initialization/assi
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
___
Es-discuss mailing list
Es-discuss@
If we are voting on the color of paint to use, I sure like:
^(a, b, ...) { ... }
+ ^ is mnemonic for Λ (Greek capital lambda)
+ ^ is mnemonic for 'pointer' so I am reminded that I am creating and
object here
+ () keeps parameters in a parameter list so I don't have to learn a
new syntax (a
On 2008-12-02, at 20:32EST, Peter Michaux wrote:
I keep a list of all the X->ES3 compilers I encounter in the middle of
the following page
http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5
Clarification on:
OpenLaszlo is the opposite direction: JavaScript compiled into Flash
1 - 100 of 123 matches
Mail list logo
