Andrea, it's difficult to understand why you think the fat arrow does
not help or I misunderstood your point, if |this| is already bound to
something, like for events, then you don't need it, if you want to bind
to something else then you use bind, if you want to bind to the outer
|this| then y
Le 02/10/2013 10:37, Claude Pache a écrit :
+1. The big win of arrow-functions, is that it prevents from using various
ad-hoc kludges (`var that = this`, `[].some(..., this)`, etc), whose sole goal
is to defeat some unwanted feature (proper `this` binding in callbacks). Not a
killing-feature,
Le 26/09/2013 20:14, Alex Russell a écrit :
On Thu, Sep 26, 2013 at 9:56 AM, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
I would like to defend against a potential mitm/code injection and
ideally against globals modifications.
Only one of those is a threat (MITM).
o you want to defend,
from who or what, and for how long?
On 26 Sep 2013 00:40, "Aymeric Vitte" <mailto:vitteayme...@gmail.com>> wrote:
This is similar to the "Native" thread as Andrea mentioned.
Then when SES is coming?
It seems urgent to boo
Le 26/09/2013 17:27, Mark S. Miller a écrit :
David, thanks!
Aymeric, yes, what David said ;).
OK, I will look at it again and try it.
Regards,
Aymeric
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
___
//www.ianonym.com
[3] http://www.ianonym.com/intercept.html
Le 26/09/2013 12:59, David Bruant a écrit :
Le 26/09/2013 12:16, Aymeric Vitte a écrit :
Le 26/09/2013 11:43, David Bruant a écrit :
Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit :
For those interested I provided in the CS
Le 26/09/2013 11:43, David Bruant a écrit :
Le jeu. 26 sept. 2013 11:11:40 CEST, Aymeric Vitte a écrit :
For those interested I provided in the CSP thread a link to a FF bug
report where it's explained how some security policy (here Websocket
spec) forces me to do insecure things. I don
://groups.google.com/forum/#!topic/mozilla.dev.security/6qBHmVAhtYY
Le 26/09/2013 10:22, David Bruant a écrit :
Le 26/09/2013 09:10, Aymeric Vitte a écrit :
There are other cases, like malicious code injection.
CSP goes a long long way in preventing these.
I don't know if it's really f
This is similar to the "Native" thread as Andrea mentioned.
Then when SES is coming?
It seems urgent to boost it, I have tried CSP recently, or at least what
works today, see [1] and [2], unfortunately I don't see quite well what
it does secure, today and tomorrow.
Regards,
Aymeric
[1] htt
n't think there is a reasonable solution for
the second case.
Once again we all trid in the past and failed for usability,
performance, not so secured env ... etc etc ...
As summary if you have a party in your house ... you better know your
guests :D
On Wed, Sep 25, 2013 at 3:48 PM, Aymeri
It's not easy to freeze the world like Caja is doing, and it's not easy
to have a library that takes care of it securely, and the use case is
not always to use modules to have a fresh global.
Some years ago, doing widgets stuff inside web pages, I had a
"RestoreNativeVar" function restoring na
I have not read everything about the promise/future/re-promise subject
but what I have read seems to show that everyone has a personal
understanding of the thing.
So please see
http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0003.html ,
code example that I have written for WebCry
I don't know what is a determinist way for enumeration and who is right
(I would be more enclined to keep the chronological order of property
settings but if the strawman says the contrary there must be a good
reason), but not knowing about #164, I wrote one day :
https://code.google.com/p/v8/i
Russell wrote:
On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte
wrote:
Le 02/04/2013 04:24, Kenneth Russell a écrit :
Agreed. DataView's methods are all simple and should be easy to
optimize. Because they include a conditional byte swap, they can't run
quite as fast as the typed arra
Le 02/04/2013 04:24, Kenneth Russell a écrit :
Agreed. DataView's methods are all simple and should be easy to
optimize. Because they include a conditional byte swap, they can't run
quite as fast as the typed arrays' accessors -- but they shouldn't
need to. DataView was designed to support file
I think one day I would have raised this subject too. While doing [1] to
[3], I was wondering during some time if I was using typed arrays
correctly, because I found strange to have to create each time a
DataView of a possible enormous buffer to read 2 bytes, and what the
impact on performances
Le 22/03/2013 19:33, Mark S. Miller a écrit :
On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
As far as I remember when I looked at it, there was a getfreevar
function or something like this parsing the code (or I
misunderstood, se
As far as I remember when I looked at it, there was a getfreevar
function or something like this parsing the code (or I misunderstood,
see [1] but don't read the proposal, it's wrong, even if I don't totally
give up with the concept).
But anyway, since it will change, does it exist an officia
Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit :
>2) What is the nature of the bindings created with the Module constructor?
>In the following scenario, what is output?
>
> var a = 123;
> var M = new Module({ a: a });
>
> a = 456;
> console.log(M.a === a); // bound to "var a"
Typed Arrays are not frozen on FF, they are not extensible, only new
typed_array(nothing) is frozen (just bad luck for your example :-) ).
Reading this thread, it seems that I am not using good practices,
because I am using quite often the object literal indexed with numbers
(var a={};a[1]=som
and, I forgot and don't know exactly if this should fall here, a
toString(encoding) method which supports streaming, see [3] using
TextEncoder/TextDecoder
Le 12/02/2013 12:54, Aymeric Vitte a écrit :
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
All the presentation decks fro
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
All the presentation decks from the meeting are publicly available at
http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013
the short form:
In ES5, today you can use Array.prototype as the [[Prototype]] of
non-Array objects or
I don't know when tasks.js will be "usable" (ie generators supported)
but probably it's a very good solution to solve all the async (and
resync) issues I had doing https://github.com/Ayms/node-Tor where
unexpected and unpredictable things as well as performances reasons
forced me to use [do_not
We don't know what name has 'global' (ie var global=this, var
window=this, etc)
This is what I tried to figure out here among others :
https://gist.github.com/2995641 ("automatic" global.global=global,
window.window=window), maybe impossible, unlikely, or whatever
I don't know well about thi
Le 28/07/2012 01:55, Rick Waldron a écrit :
Explanation of specification history and roots in newer DOM mutation
mechanism.
AWB: Is this sufficient for implementing DOM mutation event mechanisms?
RWS: Yes, those could be built on top of Object.observe
Probably I must be misreading the pro
The goals of the proposal are indicated in the strawman but not the
rationale.
I am still wondering what I can observe in a DOM environment for example
with the current proposal.
Le 18/07/2012 22:19, Aymeric Vitte a écrit :
I know this would induce other modifications in the specs but I am
I know this would induce other modifications in the specs but I am
wondering why "o.x=6" (strawman examples) does not notify
(type="triggered" or something like that), it does not modify the
object's property but it could be interesting to get the notification
too (document.body.innerHTML=xxx)
Yes it's true, focusing too much on my needs, then forget it
Le 13/07/2012 11:39, Jason Orendorff a écrit :
On Fri, Jul 13, 2012 at 3:39 AM, Aymeric Vitte wrote:
But coming back to my point, I am not talking about a download like a xhr
where you can set cookies, do post requests, etc, j
Le 10/07/2012 13:40, Sam Tobin-Hochstadt a écrit :
On Tue, Jul 10, 2012 at 7:36 AM, Aymeric Vitte wrote:
Where System.eval does a simple eval if url is not a module.
Right, that's what `loader.eval` is specified to do for module loaders.
Where is it in the proposal ? I can not find it,
Le 12/07/2012 01:17, Jason Orendorff a écrit :
On Mon, Jul 9, 2012 at 6:04 PM, Aymeric Vitte wrote:
If the answer is that it is not possible because of the same origine policy,
then it is not difficult to show that this policy can be broken already, by
some "manipulations", then i
x27;s code --> a.b='b';
}
Where System.eval does a simple eval if url is not a module.
Or something like that, why do we have the eval(src) possibility in the
proposal if we can not fetch src ?
Le 10/07/2012 01:48, Aymeric Vitte a écrit :
Le 10/07/2012 01:18, Sam Tobin-Hochstadt
6/07/2012 19:21, Aymeric Vitte a écrit :
Le 06/07/2012 18:52, Sam Tobin-Hochstadt a écrit :
On Fri, Jul 6, 2012 at 12:51 PM, Aymeric Vitte wrote:
OK, then are there objections to the async System.download(url,callback) ?
This is just a version of XHR, but with a different cross-origin
policy?
Yes
Le 06/07/2012 18:52, Sam Tobin-Hochstadt a écrit :
On Fri, Jul 6, 2012 at 12:51 PM, Aymeric Vitte wrote:
OK, then are there objections to the async System.download(url,callback) ?
This is just a version of XHR, but with a different cross-origin
policy?
Yes
and the former unlikely.
Why
OK, then are there objections to the async System.download(url,callback) ?
Le 06/07/2012 17:09, Russell Leggett a écrit :
On Fri, Jul 6, 2012 at 10:58 AM, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
Do we have a survey of the use of sync against async ? I
Do we have a survey of the use of sync against async ? I think it
would show that sync is much more used (wrongly or easy way again,
but...).
I completely disagree with this. Most developers without the
knowledge/skill to know why sync is bad are just going to use a
library lik
Le 06/07/2012 03:17, Brendan Eich a écrit :
Aymeric Vitte wrote:
Then the sync xhr is absurd ?
It's a botch that developers avoid , else they jank the user interface.
Yes, as far as you can or as far as you want to avoid unnecessary
complication, for example projet [1] is loading qu
I don't understand your comment about `window` and `document`. They
are already globals in browser JS environments.
Please, take some time to read again my previous posts, I am refering to
both server side's and browser's env, with 'window' and 'document' that
are familiar as examples, but th
It's confusing maybe because what I am requesting is very very basic
compared to modules/loader complexity and maybe I did mix it with an
example not so basic.
I just want something that loads the code and then I decide what to do
with it. Indeed on browser's side it would be like a cross-doma
a System.download(url) ?
Note : the above case is the exact real life representation of what I am
trying to describe here : https://gist.github.com/2995641
Le 03/07/2012 21:06, Jason Orendorff a écrit :
On Tue, Jul 3, 2012 at 2:29 AM, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
Forgot to copy the list...
Message original
Sujet: Re: Static Module Resolution
Date : Tue, 03 Jul 2012 09:27:50 +0200
De :Aymeric Vitte
Pour : Brendan Eich
Copie à : Kevin Smith
Le 02/07/2012 20:09, Brendan Eich a écrit :
Again, sync loading is anathema
I think I have already raised 10 times at least the fact that the
current module proposal does not allow to load a non module so both are
complementary and can interact between each others.
is not available in non browsers environments
and 3) is unnecesary complicate
Le 30/06/2012 20:19, Dav
I think we all agree that global isolation is the core purpose of a
module system. (Is that incorrect?)
Partly agree? I believe that obviating the *need* for globals is the core
purpose of a module system. I don't believe that modules should necessarily be
strictly separated. Modules should
Le 27/06/2012 01:48, Wes Garland a écrit :
What I find bad (1) is the need of VMs, let's take node.js's one,
it's calling c++ stuff, calling itself js's stuff, and at the end
things are coming back to js (with some imperfections like
node.js's VM not binding things correctly in
Le 26/06/2012 20:54, Isaac Schlueter a écrit :
The linked blog post is a very rough cut of where my thoughts are on
the subject. Expect changes and cleanup. It does not represent a
fully-baked (or even half-baked) idea, but more like a general
direction.
I expect to clean it up and propose so
Starting a new thread in order not to interfer but it is related (as far
as I understood modules implementation is let to the appreciation of
people that will develop it).
See https://gist.github.com/2995641
Since everybody is spending his time to wrap and try to separate things
while trying
I guess the grep work is not easy to do, but I have tried (manually) to
find ?. or ?( in coffee script projects, trying to seek into projects of
main contributors.
Maybe not lucky or not really aware of the most popular projects, but I
did not find any up to now.
According to my previous pos
Because it's rare to have a maybe-method called on a maybe-object,
Yes it's probably rare as I previously mentioned too, thinking about it
I still can not find a single example of use, then maybe CS users can
highlight this
Existence looks more important than callable, the CS's way like
a?.
some examples
Le 20/06/2012 00:36, Aymeric Vitte a écrit :
Coffeescript seems to have some radical behavior (a.b?.c.d.e.f) a bit
similar to what I suggested (which ok can not be in js)
But the discussion here still does not say how much a.b?() or
a.b?.call(xxx) is used in coffeescript
Personn
Coffeescript seems to have some radical behavior (a.b?.c.d.e.f) a bit
similar to what I suggested (which ok can not be in js)
But the discussion here still does not say how much a.b?() or
a.b?.call(xxx) is used in coffeescript
Personnaly I was thinking that ?. should more allow to check exist
When I made that one : https://github.com/Ayms/node-dom it was supposed
to be a fast and minimal implementation of the DOM, so it works in
almost all real cases and do not crash in other situations.
The result is not bad but not as fast as expected neither minimal. Not
minimal because I had to
OK, ?. is enough and good
Le 18/06/2012 16:48, Brendan Eich a écrit :
Aymeric Vitte wrote:
Why not, instead of adding "?" operator ?
You mean ?. here, I assume.
The answer is because what you propose is an incompatible change to
ECMA-262 (all editions) and JS back to its birth,
This is related to what I was trying to figure out in the "more fun with
undefined" thread, maybe it is wrong or have too many impact but I was
about to suggest :
8.9.1 GetValue (V)
...
5. If IsUnresolvableReference(V), return undefined
11.2.1 Property Accessors
Runtime Semantics: Evaluation
.
g(c.d);//Reference error for me
Le 15/06/2012 16:56, T.J. Crowder a écrit :
On 15 June 2012 15:34, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
I am not talking about defining implicit properties or such
things, neither having undeclared stuff looking declared, but just
:52, T.J. Crowder a écrit :
On 15 June 2012 14:34, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
Example :
console.log(a);//Reference error, GetBase returns undefined
console.log(window.a);//undefined
--> does not seem very logical, no ?
To me this would b
Probably there are very good reasons but I reask the question : why
should the attempt to access a property of a variable equal to undefined
global property not return undefined global property ? (ie a way that
this works : if (a.b.c.d) {} when a,a.b, etc are not set)
This can be usefull when
endan Eich a écrit :
On Jun 14, 2012, at 6:38 PM, Aymeric Vitte wrote:
Maybe I missed it, never saw the use of null since a long time, but I can be
wrong
As Allen pointed out, null is specified in ECMA-262, e.g. Object.getPrototypeOf.
/be
--
jCore
Email : avi...@jcore.fr
Web :www.jco
Just to be clear I am talking about the use of null in the scope of the
current discussion (ie operators/default) only
Le 15/06/2012 01:37, Aymeric Vitte a écrit :
"Before"...
I put Rick's answer below too, in strict/correct code it can be used
but what examples (except you
probably behave the same as undefined
Le 15/06/2012 01:12, Tab Atkins Jr. a écrit :
On Thu, Jun 14, 2012 at 4:06 PM, Aymeric Vitte wrote:
Nobody (except w3c) is using null, or when someone is using it, it is the
same way as undefined, and it is not explicit (ie a||b or a==b, not
a===null), I
This discussion I think is going into a useless complexity.
Nobody (except w3c) is using null, or when someone is using it, it is
the same way as undefined, and it is not explicit (ie a||b or a==b, not
a===null), I remind some old code where we could see the use of null but
can not find a sing
Typo below, I meant "which can be written : if
(!(((typeof(api)!="undefined"??api.a:undefined)??api.a.b:undefined)??api.a.b.c:undefined))
{try later}"
Le 13/06/2012 12:12, Aymeric Vitte a écrit :
Indeed, maybe both should be included.
What about this case :
if (typ
Indeed, maybe both should be included.
What about this case :
if (typeof(api)=="undefined") {try later} else if (!api.a) {try later}
else if (!api.a.b)) {try later} else if (etc...)
which can be written : if
(!(((typeof(api)!="undefined"?api.a:undefined)?api.a.b:undefined)?api.a.b.c:undefine
Comments:
- fat arrow : I am not a fan of the syntax but it is usefull and does
fix the unlogical behavior of |this| (the rules are the same for the
|this| binding, it does not change except that you must apply it to the
surrounding environment), the thin arrow (as soft binding's use I
suppos
No, you are not alone.
Mustache and cascade are interesting but maybe not extremely, extremely
usefull.
Then as people have tried since years, I did write too a 'with'-like
proposal in strict mode, I already sent it some time ago and got 0
feedback, maybe I did not present it the right way,
I really like(d) the mustache proposal but unfortunately reached the
same conclusion : too complicate and confusing for what it brings. It's
surprising that the fundamental difference between Put and DOP was
unknown from almost everybody (including myself), then a rapid and easy
conclusion know
Le 26/05/2012 22:01, Brendan Eich a écrit :
Domenic Denicola wrote:
Is there a parallel to be drawn with
__(define|lookup)(Getter|Setter)__, or is __proto__ different? I
quite liked Allen's blog post about why IE decided to never support
them [1]. Following that reasoning seems to lead to
Draft is here : https://gist.github.com/edd064e5b29e67ebe493
Maybe everything is not accurate regarding some comments and annex
should include other examples but, before writing more, let's submit it
As mentionned in the gist, it is supposed to address several topics :
security and wrapping,
Le 23/05/2012 22:30, David Herman a écrit :
- I will be redoing the entire wiki to focus on community first, committee
second, and to make the big picture clearer
I know writters don't have always time but maybe adding more examples
and simple ones (even not reflecting the whole picture) in
hadow follows now with
every vendor/platform thinking they can specify whatever they like, and
others thinking they can shut down whatever they like (tip : the name
starts by a G)
Le 22/05/2012 19:17, Wes Garland a écrit :
On 22 May 2012 12:54, Aymeric Vitte <mailto:vitteayme...@gmail.com
I don't see how a FFI could really help developers. What would be needed
is a not empty intersection between
http://developer.apple.com/library/safari/navigation/,
https://wiki.mozilla.org/WebAPI, WHAT WG, W3C, etc, unfortunately it is
not the case at all
Or something like phonegap if it can
, set:scopedSet}, //set and get window.d
parseInt: window.parseInt; //initial parseInt, not evil
f: "f" //frozen initial value
Then :
function() {
"use strict";
return (
var
a="a";window.b="b";c="c";parseInt="evil";d=
Le 10/05/2012 20:04, Anton Kovalyov a écrit :
it'd be really nice to have down-to-earth explanation of harmonized
changes with code samples that resemble real world use cases.
Yes.
TC39 can not ask the opinion of every developers or community
representatives, and developers can not spe
1- Yes, several time that you mention it, and ++ from me each time
2- I prefer the dot notation rather than Object.extend, even if both are
good
Le 28/04/2012 20:49, Kevin Smith a écrit :
Hi Angus!
1) Kevin et al suggested YAGN call/apply on (non-method)
functions. Here's a pretty ne
self (but not an iframe)
For proxies, I am not expert, what does it bring to emulate the dom
faithfully ?
Le 20/03/2012 06:27, Mark S. Miller a écrit :
On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte <mailto:vitteayme...@gmail.com>> wrote:
'Avoid “this”. Use closures rath
'Avoid "this". Use closures rather than prototypes'
Probably the public was stunned by that one... (technical problems too,
could not hear the video, just saw the slides)
Technically for the purpose of your presentation, it is correct, but I
am coming back again to real life, you are using st
The first question maybe in all these discussions is what is needed or
not (in real life).
In BTF discussions I gave an example where (surprisingly) for an app
there were a very few prototype like declarations.
Because I just did not need it for this app.
The second question is maybe whether
Hi,
I think I have missed something in the discussions (or globally) because
I don't understand very well why methods are involved in lexical this.
But if it is so, why events handlers should be different from a js
perspective ? Maybe you could include in the tool everything that is a
method
x=document.createElement('div');
x.onmousedown=function() {var a=this.style};
var y=function() {var a=this;};
x.onmouseover=y;
are not counted as BTF candidates
Since I have not yet understood what should become methods with the
arrow/do or do proposals, I can not say more...
Le 14/03/2012 22:15
For me no. I have looked into popcorn.js today and could not convince
myself that it was more readable, maybe it's a question of history or
feelings (and to get used to it) but without being an expert in all
languages, I consider js to be a unique (clever) language, using the
arrow notation mak
So BTF stands for "bound-this function expressions"
But it does include case b (don't care about "this")
Then in the next email you conclude :
"Interestingly, when we take the sum of BTF candidates and object
literal methods, we account for over 90% of function expressions."
Is it surprising
I have tried the tool with node-dom (https://github.com/Ayms/node-dom)
to check what it would give on a whole site, not only a framework, see
the result below for a usual web site (here http://www.castorama.fr), I
did not compile it yet because it seems that there is a slight problem
with the t
I was not aware of this document when I wrote :
https://mail.mozilla.org/pipermail/es-discuss/2012-March/021050.html
Reading my post again, it's indeed not clear at all that I was
referring more to the syntax than block lamdas's principles and that
this should behave as block lambdas,
and 3 look useless ?).
I did not say that block lambdas were not interesting and powerfull, I
just think that this might be difficult to swallow/use by developpers,
so an intermediate approach maybe was not bad, but apparently it is no
possible.
Le 08/03/2012 19:22, Brendan Eich a écrit :
Aym
Then you really have three somewhat modest proposals:
1. optional "function".
2. braceless functions that auto-return the completion value of the
expression and exhibit TCP freakdeekness.
3. do-expressions blocks that evaluate to their completion value.
These three seem to combine to let you do
ot;this", still thinking about it, what I wrote below does not
solve all cases
Le 06/03/2012 17:33, 程劭非 a écrit :
> That will work in json but Object.GetBase is not so nice.
>
> Also I think GetBase(GetBase(GetBase(this))) looks a bit ugly.
>
> 在 2012年3月7日 上午12:22,Aymeric Vitte
gt;
> var x = {
> a:{
> },
> b:{
> }
> }
>
> x.a.p = x.b.p = {};
>
> So GetBase is not able to decide to return x.a or x.b.
>
>
> 在 2012年3月6日 下午11:08,Aymeric Vitte <mailto:vitteayme...@gmail.com>>写 道:
>
>> Some object could have more than one
> Some object could have more than one ancestor.
Yes, so ? It's not in contradiction with what I am saying
Le 06/03/2012 14:58, 程劭非 a écrit :
> I prefer "this" to be root object. Some object could have more than
> one ancestor.
>
> 2012/3/6 Aymeric Vitte
Yes, assuming that GetBase is usable (8.9) :
var obj = {
x:{
a: GetBase(this) // obj
}
}
But it is an internal function only, there are things defined in specs
to access properties of objects but nothing the other way, because I
believe the case never happens today.
The "this
The first time I saw the "<|" symbol I found it frightening and thought
that developpers would find it frightening too.
But it is easy to get used to it if we just think about the visual
representation and it looks more friendly than other proposals along
this post.
I don't like a lot "->",
thing that is useless could be transformed to something usefull, but
right now I don't see a simple way to do it that creates more benefit
than harm.
Regards
A. Vitte
Le 15/02/2012 19:21, Aymeric Vitte a écrit :
I did not find any related subject in discussions or specs so here it
is :
var f=f
I did not find any related subject in discussions or specs so here it is :
var f=function(name) {
this._name=name;
};
f.prototype={
get nodeName() {return this._name},
get tagName() {return this._name},
get anotherNameInvention() {return this._name},
...
set nodeName() {}
90 matches
Mail list logo