On 5 May 2014, at 00:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
as generic global utility it would be also nice to make it compatible with
all strings.
For backwards compatibility reasons, `atob`/`btoa` should probably continue to
work in exactly the same way they work now (i.e
Le 5 mai 2014 à 09:54, Mathias Bynens math...@qiwi.be a écrit :
On 5 May 2014, at 00:00, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
as generic global utility it would be also nice to make it compatible with
all strings.
For backwards compatibility reasons, `atob`/`btoa`
On 2 May 2014 14:45, Claude Pache claude.pa...@gmail.com wrote:
The algorithm given in [Bug 1908, comment 2]
(https://bugs.ecmascript.org/show_bug.cgi?id=1908#c2) is problematic, as a
property name blacklisted by an `@@unsopables` anywhere on the prototype
chain will also be blacklisted
On 5 May 2014, at 10:48, Claude Pache claude.pa...@gmail.com wrote:
In my view, if `atob` and `btoa` were to enter in ES, it should be in
Appendix B (the deprecated legacy features of web browsers), where it would
be in good company with the other utility that does an implicit confusion
Le 5 mai 2014 à 12:03, Mathias Bynens math...@qiwi.be a écrit :
On 5 May 2014, at 10:48, Claude Pache claude.pa...@gmail.com wrote:
In my view, if `atob` and `btoa` were to enter in ES, it should be in
Appendix B (the deprecated legacy features of web browsers), where it would
be in good
On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
+1 and as generic global utility it would be also nice to make it
compatible with all strings.
A language with modules does not need nor should it rely on stuff more
favorite features onto global. We need
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal Object.getPrototypeOf().
For example:
var aPrototype = {foo: 'foo'};
var handler = {
get: function(target, name, receiver) {
@john I don't really care about the namespace/module as long as this matter
moves from W3C spec to ES one.
@mathias didn't mean to change atob and btoa rather add two extra methods
such encode/decode for strings (could land without problems in the
String.prototype, IMO) with less silly names
not sure I understand but ...
that makes no sense as hasProxyAsProto is not a Proxy
it's inheriting from a Proxy so where is the surprise? it does what I'd
expect it to do, pass through the inherited Proxy same as you pass through
inherited get/set methods when creating from an object that has
On May 5, 2014, at 10:40 AM, John Barton wrote:
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal Object.getPrototypeOf().
For example:
var aPrototype = {foo: 'foo'};
I'd like highlight the fact that binary data handling in JS these days is
mainly done via ArrayBuffers and TypedArrayViews. To that end, I've written
a base64 to Uint8Array decoder like so:
https://gist.github.com/pyalot/4530137
I don't quite see how atob/btoa without a usable binary type
2014-05-05 19:40 GMT+02:00 John Barton johnjbar...@google.com:
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal Object.getPrototypeOf().
There's no such equivalence, even for
On Mon, May 5, 2014 at 11:44 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On May 5, 2014, at 10:40 AM, John Barton wrote:
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal
On 5/5/14, 4:21 PM, John Barton wrote:
Let me rephrase my question: why is the Proxy get even called in this case?
Because the way __proto__ works is as if the JS implementation had done:
(function() {
protoGetter = Object.getPrototypeOf;
Object.defineProperty(Object.prototype, __proto__,
but that's exactly what I've replied to you already?
Once again, `__proto__` is spec'd in the `Object.prototype` like this:
```javascript
Object.defineProperty(
Object.prototype,
'__proto__',
{
configurable: true,
get: function () {
return Object.getPrototypeOf(this);
},
everything else passes through the `Object.prototype`
of course, unless not intercepted or shadowed as shown already in my
previous reply ... `Object.defineProperty(anyObject, '__proto__', {value:
false})`
On Mon, May 5, 2014 at 4:57 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Since you ask for a response:
On Mon, May 5, 2014 at 11:30 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
not sure I understand but ...
that makes no sense as hasProxyAsProto is not a Proxy
it's inheriting from a Proxy so where is the surprise? it does what I'd
expect it to
that code is wrong and I don't know why or who would assume that
accordingly with specs
I'd rather file a bug in there, pointing at specs ... there are two places
about __proto__, everything else/other interpretations are evil indeed
take care
On Mon, May 5, 2014 at 6:48 PM, John Barton
18 matches
Mail list logo
