On Fri, Jul 1, 2011 at 2:55 PM, Brendan Eich wrote:
> On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote:
>
> > In our implementation we are using a generic object. It has some
> overhead, and a specific internal "descriptor object" representation might
> be a bit faster, but such magic objects that
Thanks David,
Yes, this is important. The way I noticed it is that the same issue came up
for the FF implementation of WeakMaps <
https://bugzilla.mozilla.org/show_bug.cgi?id=656828>. I will be proposing
the to-be-fixed Mozilla API to the committee to become the new WeakMap
proposal -- making it m
2011/7/1 Brendan Eich :
> On Jul 1, 2011, at 10:51 AM, Mike Samuel wrote:
>
>> What is
>>
>> ({
>> get
>> x()
>> {
>> return 42;
>> }
>> })
>>
>> ?
>>
>> Could it match both as an object literal with a getter
>>
>> ({ get x() { return 42; } })
>
> Only that.
>
>
>> or as
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
On Friday, 2011-07-01 at 23:51 , Brendan Eich wrote:
> On Jul 1, 2011, at 8:40 AM, Irakli Gozalishvili wrote:
> >
> > On Friday, 2011-07-01 at 16:38 ,
On Jul 1, 2011, at 2:28 PM, Irakli Gozalishvili wrote:
> On Friday, 2011-07-01 at 19:31 , Brendan Eich wrote:
>
>> On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
>>
>>> With focus on prototype this is so much simpler:
>>>
>>> var Foo = Object.extend({
>>>initialize: function(options
On Jul 1, 2011, at 11:37 AM, Andreas Gal wrote:
> In our implementation we are using a generic object. It has some overhead,
> and a specific internal "descriptor object" representation might be a bit
> faster, but such magic objects that don't allow expando properties are
> usually pretty surp
On Jul 1, 2011, at 10:51 AM, Mike Samuel wrote:
> What is
>
> ({
> get
> x()
> {
> return 42;
> }
> })
>
> ?
>
> Could it match both as an object literal with a getter
>
> ({ get x() { return 42; } })
Only that.
> or as a block with 3 statements?
>
> ({ get; x
On Jul 1, 2011, at 8:40 AM, Irakli Gozalishvili wrote:
> On Friday, 2011-07-01 at 16:38 , Mark S. Miller wrote:
>
>> With two expectations for the semantics of something that does not appear in
>> the code, and without a static or dynamic rejection to prevent progress of
>> the code written to t
> With <| and 'super' in functions, I think you are set. It's hard to add more.
> The main debate is about whether this is enough, or do classes as sugar
> provide enough added value?
<|, super and possibly some support for subclassing (to set up the constructor
property in subclasses etc.) wou
On Friday, 2011-07-01 at 19:31 , Brendan Eich wrote:
> On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
>
> > With focus on prototype this is so much simpler:
> >
> >
> > var Foo = Object.extend({
> > initialize: function(options) { ... },
> > do_foo_job: function() { ... }
> > })
> >
Hi,
I just wanted to put on es-discuss the concern raised by Mark Miller [1]
about mutable internal properties of Date.prototype and that it should
be fixed in the next version of ECMAScript.
David
[1] http://code.google.com/p/google-caja/issues/detail?id=1362
___
Hi Andreas,
Property descriptors as specific "type" is an internal construct of the
ES spec. Their definition in ES5 was used in the context of ES5 (with
normal objects, host objects but no proxies). The proxy API needed a way
to represent them. Objects sound like the natural construct to do so.
On Fri, Jul 1, 2011 at 2:50 PM, Mike Samuel wrote:
> 2011/7/1 Mike Shaver :
>> On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel wrote:
>>> 2011/7/1 Mike Shaver :
What can someone do with that password, though? Just change your
subscription settings, afaik, so the security in place seems prop
2011/7/1 Mike Shaver :
> On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel wrote:
>> 2011/7/1 Mike Shaver :
>>> What can someone do with that password, though? Just change your
>>> subscription settings, afaik, so the security in place seems proportionate.
>>>
>>> Could report it upstream to the mailman
In our implementation we are using a generic object. It has some overhead, and
a specific internal "descriptor object" representation might be a bit faster,
but such magic objects that don't allow expando properties are usually pretty
surprising to programers. Most of the HTML5 DOM allows arbit
On Fri, Jul 1, 2011 at 2:30 PM, Mike Samuel wrote:
> 2011/7/1 Mike Shaver :
>> What can someone do with that password, though? Just change your
>> subscription settings, afaik, so the security in place seems proportionate.
>>
>> Could report it upstream to the mailman team, I suppose.
>
> Use it t
2011/7/1 Mike Shaver :
> What can someone do with that password, though? Just change your
> subscription settings, afaik, so the security in place seems proportionate.
>
> Could report it upstream to the mailman team, I suppose.
Use it to do a better job of impersonating. Try it out on other site
What can someone do with that password, though? Just change your
subscription settings, afaik, so the security in place seems proportionate.
Could report it upstream to the mailman team, I suppose.
Mike
On Jul 1, 2011 10:09 AM, "Axel Rauschmayer" wrote:
> That’s a good start, thanks. Still find
On Jul 1, 2011 1:14 PM, "Brendan Eich" wrote:
>
> On Jul 1, 2011, at 2:21 AM, Tim Smart wrote:
>
>> I quite the current prototype model we have in ecma5. My only gripes
would be that `prototype` to too wordy,
>
>
> Do you use it that often?
15 years ago, writing an overwrought prototype hierarchy
What is
({
get
x()
{
return 42;
}
})
?
Could it match both as an object literal with a getter
({ get x() { return 42; } })
or as a block with 3 statements?
({ get; x(); { return 42; } })
2011/7/1 Brendan Eich :
> On Jun 30, 2011, at 9:46 PM, Brendan Ei
On Jul 1, 2011, at 6:19 AM, Irakli Gozalishvili wrote:
> With focus on prototype this is so much simpler:
>
> var Foo = Object.extend({
>initialize: function(options) { ... },
>do_foo_job: function() { ... }
> })
With <| and 'super' in functions, I think you are set. It's hard to add mo
On Jul 1, 2011, at 2:21 AM, Tim Smart wrote:
> I quite the current prototype model we have in ecma5. My only gripes would be
> that `prototype` to too wordy,
Do you use it that often?
> and `__proto__` needs to become standard.
The <| operator is the future there. __proto__ won't be standardi
Thanks-- missed one when manually doing s/ImportPath/ImportBinding/g. Fixed.
Thanks,
Dave
On Jul 1, 2011, at 9:55 AM, Kam Kasravi wrote:
> Should this
>
> ImportDeclaration(load) ::= "import" ImportBinding(load) (","
> ImportBinding(load))* ";"
> ImportPath(load) ::= ImportSpecifierSet "from"
Should this
ImportDeclaration(load) ::= "import" ImportBinding(load) (","
ImportBinding(load))* ";"
ImportPath(load) ::= ImportSpecifierSet "from" ModuleExpression(load)
ImportSpecifierSet ::= "*"
| IdentifierName
| "{" (ImportSpecifier ("," ImportSpecifie
Ah, oh yes. I think I fail at mailing lists :3
2011/7/1 Peter Michaux
> Did you mean to send this to es-discuss?
>
> Peter
>
> On 2011-07-01, at 8:51 AM, Quildreen Motta wrote:
>
> Actually, in my opinion, constructor functions add needless complexity on
> JavaScript's inheritance mechanism, an
On Jun 30, 2011, at 9:46 PM, Brendan Eich wrote:
> Oops -- thanks. I will fix in a strawman that captures all of this.
Done:
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
/be
___
es-discuss mailing list
es-discuss@mozilla.or
On Fri, Jul 1, 2011 at 9:38 AM, Mark S. Miller wrote:
>> This could be handled by class literals by allowing for default
>> constructors. If one doesn't provide a constructor, the following one
>> could be provided:
>>
>> constructor(... args) {
>> super(... args);
>> }
>
> This one I object to
On Friday, 2011-07-01 at 16:38 , Mark S. Miller wrote:
> On Fri, Jul 1, 2011 at 7:18 AM, Sean Eagan (mailto:seaneag...@gmail.com)> wrote:
> > On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili > (mailto:rfo...@gmail.com)> wrote:
> >
> > > why do I have to create constructor function for all
On Fri, Jul 1, 2011 at 7:18 AM, Sean Eagan wrote:
> On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili
> wrote:
>
> > why do I have to create constructor function for all classes / subclasses
> ?
>
This magic trades confusion for convenience. In any earlier version of the
proposal, I actually
On Fri, Jul 1, 2011 at 8:45 AM, Irakli Gozalishvili wrote:
> why do I have to create constructor function for all classes / subclasses ?
This could be handled by class literals by allowing for default
constructors. If one doesn't provide a constructor, the following one
could be provided:
cons
That’s a good start, thanks. Still find it a bit scary that there’s no
encryption.
On Jul 1, 2011, at 16:07 , André Bargull wrote:
> Log-in at [1] and remove the option to send a monthly password remainder?
>
>> Get password reminder email for this list?
>> Once a month, you will get an email c
Log-in at [1] and remove the option to send a monthly password remainder?
*Get password reminder email for this list?*
Once a month, you will get an email containing a password reminder for
every list at this host to which you are subscribed. You can turn this
off on a per-list basis by selec
Sorry I did not intended to send email yet:
So here is my points:
1. Does this looks familiar (version with syntax highlighting
https://gist.github.com/1058534)
function Foo(options) { }
Foo.prototype.do_foo_job = function() { ... }
function Bar(options) {
if (!(this instanceof Bar))
ret
I absolutely agree with Alex and have few other points:
1. Does this code looks familiar ?
> function Foo(options) { }
> Foo.prototype.do_foo_job = function() { ... }
>
> function Bar(options) {
> if (!(this instanceof Bar))
> return this new Bar(options);
> Foo.apply(this, arguments);
> }
On 1 July 2011 12:12, Andreas Rossberg wrote:
> I believe there is some "type" confusion in the proxy proposal spec
> wrt property descriptors and their reification into attributes
> objects.
>
> 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal
> says:
>
> "The Desc argu
Can this be fixed? I’ve already sent feedback, but didn’t get a response.
Preferably, passwords would also be encrypted for storage.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
Home: rauschma.de
Blog: 2ality.com
___
es-discuss maili
I believe there is some "type" confusion in the proxy proposal spec
wrt property descriptors and their reification into attributes
objects.
1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal says:
"The Desc argument to this trap is a property descriptor object
validated by
BTW: I like the :: proposal (Brendan will remind you that it’s already taken,
though...).
What you are in fact creating is the illusion that the class name refers to the
prototype (with PAC, the :: would turn into a dot).
On Jul 1, 2011, at 11:21 , Tim Smart wrote:
> I quite the current prototy
What I’m asking for is the following (and I might not convince anyone, but just
consider the possibility):
If you are using a constructor function C only once, during construction and
otherwise always use C.prototype, wouldn’t it be better to focus on
C' = C.prototype
Then you would use
I quite the current prototype model we have in ecma5. My only gripes would
be that `prototype` to too wordy, and `__proto__` needs to become standard.
If you replaced `prototype` with `::` or something everything would be
swell.
function Parent (name) {
this.name = name || this.constructor.DEFAU
> I don't think
> JavaScript has ever been far from its prototype roots especially if
> the programmer shifts to thinking about a prototype object instead of
> thinking about a functions prototype property.
That is basically the point that the proposal tries to make. Have you taken a
look at the
41 matches
Mail list logo
