Hello Mark,
I think mistake is a harsh word. It is really a question of how much the
community wants javascript to adopt object-oriented paradigms. You could go
all the way and make classes a very strict subset of the language: throw an
error if the user tries to set a property of a class instance
On Sep 18, 2011, at 1:14 AM, Brendan Eich wrote:
> On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
>
>> On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich wrote:
>>
>> Binary data does no such thing! The descriptors are per generated
>> type-constructor, not per instance.
>>
>> once you def
On Sep 18, 2011, at 12:34 AM, Andrea Giammarchi wrote:
> On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich wrote:
>
> Who ever said they didn't?
>
> Sam did:
> > You'd need a benchmark that shows that the object allocation you're
> > avoiding here is worth the lack of flexibility.
Sam did not say
On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
> On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich wrote:
>
> Binary data does no such thing! The descriptors are per generated
> type-constructor, not per instance.
>
> once you define a StructType how do create an instance ?
>
> new Point2
On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich wrote:
>
> Who ever said they didn't?
>
Sam did:
> You'd need a benchmark that shows that the object allocation you're
> avoiding here is worth the lack of flexibility.
I see what you are getting at now, but you're missing something: your test2
> h
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich wrote:
>
> Binary data does no such thing! The descriptors are per generated
> type-constructor, not per instance.
>
once you define a StructType how do create an instance ?
new Point2D({x: 0, y: 0});
or binary data can create instances only throug
On Sep 18, 2011, at 12:09 AM, Andrea Giammarchi wrote:
> at least now we agree object literals *add* overhead
Who ever said they didn't?
> and with current JS.next typed structs/arrays proposal you can bet developers
> will do those kind of non-sense things ;-)
I see what you are getting at n
Cython is used to create Python extension so does js-ctypes ...
Cython is a superset of Python statically compilable so is, or it should be,
js-ctypes and/or JS.next proposal
The fact js-ctypes are not trace-JITed at all was *in any case* unexpected
to me and the fact js-ctypes are coupled with th
at least now we agree object literals *add* overhead and with current
JS.next typed structs/arrays proposal you can bet developers will do those
kind of non-sense things ;-)
I have updated the test case using a second Int32Array loop simply to access
the index
On Sun, Sep 18, 2011 at 6:03 AM, Bre
On Sep 17, 2011, at 10:48 PM, Andrea Giammarchi wrote:
> So here I don't understand why Sam had to bring it into the discussion ...
> anyway, still missing the answer from you Brendan:
>
> Why JS.next is bringing StructType and requires an "object description" per
> each created instance ?
Bin
On Sep 17, 2011, at 10:39 PM, Andrea Giammarchi wrote:
> Can we at least agree that if some extension brings *exactly* same
> constructor name, StructType and ArrayType, and more or less exactly the same
> signature/usage of what Brendan showed in his slides it become kinda natural
> to compare
On Sep 17, 2011, at 10:34 PM, Andrea Giammarchi wrote:
> Brendan I wrote I did it on purpose trying to predict what JS devs will do
> once JS.next will bring ctypes like syntax.
My objection is that you're confounding test2 by adding object literal overhead
to each loop iteration, in addition t
for the record, post updated:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>
>
> > Once again, why once a struct has been defined we need to create per each
> > instance its counterpart in native JS ?
> >
> > new Point2D({x: 1, y: 2}) ... why?
> > what's wrong with a *shimmable*
> > new Point2D(x = 1, y = 2)
> > so that no object has to be created?
>
> You'd need a benchm
Function VS eval is another story and Function does not suffer scope and
context, eval does.
Minifier don't care about function, Firefox seems to optimize the body same
as it does with any other function but still ... this is another story and
if a function does 1 operation rather than 10 I can't
Can we at least agree that if some extension brings *exactly* same
constructor name, StructType and ArrayType, and more or less exactly the
same signature/usage of what Brendan showed in his slides it become kinda
natural to compare/test/confuse these two different implementations for
different pur
Brendan I wrote I did it on purpose trying to predict what JS devs will do
once JS.next will bring ctypes like syntax.
I wrote the object with properties only assigned too indeed but as is for
functions expressions usually created everywhere by common developers rather
than reused where possible I
Hi Jonathan,
Your class recapitulates a mistake the committee almost made as well. Your
private and public member are in the same namespace. Private members should
not affect the behavior of the public API. However, if a class makes an
extensible instance, and a client of the instance tries to add
On Sat, Sep 17, 2011 at 10:14 AM, Xavier MONTILLET
wrote:
>
> When I say Firefox says, you can't I mean you really can't:
>
> ( function ( ) {
>'use strict';
>function Constructor ( ) { }
>Object.defineProperty( Constructor.prototype, 'property', {
>value: 'prototype',
>
I would like to add my suggestion for js classes.
https://gist.github.com/1224324
The key points are:
- Constructors are functions named the same as the class.
- Inside the class, *this* refers to the class instance.
- Functions and variables are declared outside the constructor, ins
On Fri, Sep 16, 2011 at 1:55 AM, Andreas Rossberg wrote:
> Being able to detect when a condition is violated is not equivalent to
> knowing that it always holds.
You're right, of course. Thanks for slicing that more finely for me.
Mike
___
es-discuss m
On Sep 17, 2011, at 3:02 PM, Brendan Eich wrote:
> An exception, or special case if you will: using Function or eval up front,
> hoisted and common'ed out of loops, and (this is crucial
"for eval", I meant to write here.
> ) not called from a function that you want optimized, in order to gener
On Sep 17, 2011, at 2:57 PM, François REMY wrote:
> The best way to avoid the "over-annotation" of codes is probably to teach
> users about WHEN or WHY they should add types guards. If you add the feature
> and don't explain what's her purpose and what specific scenarii it can solve,
> you'll g
On Sep 17, 2011, at 2:54 PM, Sam Tobin-Hochstadt wrote:
>>> There's an excellent overview of how to write
>>> high-performance JavaScript code by David Mandelin here:
>>>
>>> http://blog.mozilla.com/dmandelin/2011/06/16/know-your-engines-at-oreilly-velocity-2011/
>>
>> this has been linked in t
The best way to avoid the "over-annotation" of codes is probably to teach
users about WHEN or WHY they should add types guards. If you add the feature
and don't explain what's her purpose and what specific scenarii it can
solve, you'll get in trouble.
However, if you can coordinate with the wh
On Sat, Sep 17, 2011 at 2:34 PM, Andrea Giammarchi
wrote:
> First of all thanks for clarifications ... as I have said, js-ctypes
> extension looked way too similar to what Brendan showed in his slides.
> In any case, there are still a couple of confusing points to me and yes, I
> will update my po
On Sep 17, 2011, at 2:34 PM, Andrea Giammarchi wrote:
> Also I have explicitly slowed down the logic creating a "classic" literal JS
> object per each loop iteration ... still, way too slow performances so
> whatever js-ctypes has been created for, something went wrong, imo
Why are you doing th
First of all thanks for clarifications ... as I have said, js-ctypes
extension looked way too similar to what Brendan showed in his slides.
In any case, there are still a couple of confusing points to me and yes, I
will update my post as soon as these things are clear.
For example ...
> 1. Bina
On Sep 17, 2011, at 2:07 PM, David Bruant wrote:
> Le 17/09/2011 19:39, Brendan Eich a écrit :
>> On Sep 17, 2011, at 12:03 PM, Xavier MONTILLET wrote:
>>
>>> How come the get and set traps get a receiver argument when the others
>>> don't?
>> Please catch up on relevant threads in this list if
Le 17/09/2011 19:39, Brendan Eich a écrit :
> On Sep 17, 2011, at 12:03 PM, Xavier MONTILLET wrote:
>
>> How come the get and set traps get a receiver argument when the others don't?
> Please catch up on relevant threads in this list if you can. In any case, see
>
> http://wiki.ecmascript.org/doku.
On Sep 17, 2011, at 1:14 PM, Xavier MONTILLET wrote:
> function Constructor( ) { }
> Object.defineProperty( Constructor.prototype, 'property', {
>value: 'prototype'
> } );
NB: writable is undefined in that property descriptor, and undefined is falsy.
> var object = new Constructor( );
> obj
On Sep 17, 2011, at 12:03 PM, Xavier MONTILLET wrote:
> How come the get and set traps get a receiver argument when the others don't?
Please catch up on relevant threads in this list if you can. In any case, see
http://wiki.ecmascript.org/doku.php?id=strawman:strawman under "proxy
extensions",
On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:
> On 13 September 2011 16:48, Brendan Eich wrote:
>> On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
>>>
>>> * There are extra costs in space and time to doing the runtime analysis.
>>> * Compile time is runtime, so there are severe limi
Hi,
First of all here's the code that made me thought if this:
function Constructor( ) { }
Constructor.prototype.property = 'prototype';
var object = new Constructor( );
object.property = 'instance';
console.log( object.property );// 'instance'
function Constructor( ) { }
Object.defineProperty(
Hi,
On this webpage:
http://wiki.ecmascript.org/doku.php?id=harmony:proxies
They show this:
{
has: function(name) -> boolean // name in proxy
hasOwn:function(name) -> boolean //
({}).hasOwnProperty.call(proxy, name)
get: function(receiver, n
Andrea;
On 17 September 2011 04:12, Andrea Giammarchi
wrote:
> I know current Mozilla implementation is not exactly what will be in
> JS.next but it was the only way I had to test efficiency of this proposal
> and performances speaking it looks like an epic fail so far and please feel
> free to c
On Sat, Sep 17, 2011 at 4:12 AM, Andrea Giammarchi
wrote:
> my thoughts, my benchmark, and my worries about JS.next StructType and
> ArrayType:
> http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
This blog post is confusing 3 different things, and thus coming to
wrong concl
The Mozilla implementation is probably not optimized and is intended only for
testing purposes.
However, I agree with you on some points like typechecking and double memory
consumption during initialization.
From: Andrea Giammarchi
Sent: Saturday, September 17, 2011 10:12 AM
To: es-discuss@
my thoughts, my benchmark, and my worries about JS.next StructType and
ArrayType:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
I know current Mozilla implementation is not exactly what will be in JS.next
but it was the only way I had to test efficiency of this proposal
39 matches
Mail list logo
