Unsubscribing from this mailing list, which seems to have become a spam
platform.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> Making is a public symbol in this manner means it is almost impossible to
deny. It is still true that "util" is deniable, so this isn't necessarily
fatal. I am not yet oriented enough to understand what the consequences are
of suppressing util; but I am worried.
I wasn’t under the impression
rum so that the potential risks can be evaluated before public
> disclosure.
>
>
>
> On Mon, Sep 17, 2018, 02:19 Darien Valentine
> wrote:
>
>> > What is going on here? Can you explain?
>>
>> A C++/V8 API is used to obtain references to the target and h
more reason to prefer WeakMaps to properties when relating objects
>> and secrets.
>>
>>
>>
>> On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine
>> wrote:
>>
>>> A few weeks ago I’d commented on an open Node github issue regarding
>>> Proxies a
A few weeks ago I’d commented on an open Node github issue regarding
Proxies and inspection. While the bulk of the comment concerns an opinion
that proxies should not be treated as special case, I included an example
of a mechanism by which the current implementation allows outside code to
access
noying.
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Tue, Sep 4, 2018 at 3:32 AM Darien Valentine
> wrote:
> >
> > The following instrinsic functions invoke the ToPropertyDescriptor
> internal operation to convert JS-
On reflection (ha) I realize that there is an almost certainly safe
change which can be made to address this in the Reflect.defineProperty
case, which is to make Reflect.defineProperty alone return an object with a
null prototype. I believe this would make it behave the same as ordinary
The following instrinsic functions invoke the ToPropertyDescriptor internal
operation to convert JS-object property descriptors into "Property
Descriptors" (spec-internal object type):
- `Reflect.defineProperty`
- `Object.create`
- `Object.defineProperty`
- `Object.defineProperties`
- a `Proxy`
Herby, for those like myself who aren’t familiar with “classical let-in,”
could you explain more about the objective? It’s not clear to me from the
brief example what advantages this would provide.
___
es-discuss mailing list
es-discuss@mozilla.org
ue it tries to ducktype call
> .valueOf on the object. So the presence of [[NumberData]] changes the
> behavior even if it does not actually use this value.
>
> On Sat, Aug 4, 2018 at 10:14 PM Darien Valentine
> wrote:
>
>> Is this a question about how/if
otype for its prototype,
this will be `String.prototype.toValue`, which throws if its receiver
doesn’t have [[StringData]]. In the case of the object with
Object.prototype for its prototype, this will be `Object.prototype.toValue`.
On Sat, Aug 4, 2018 at 10:31 PM Darien Valentine
wrote:
> Oh, thanks Clau
Oh, thanks Claude, I missed that. I guess it is all replicable then.
On Sat, Aug 4, 2018 at 10:28 PM Claude Pache wrote:
>
>
> > Le 5 août 2018 à 04:14, Darien Valentine a
> écrit :
> >
> >
> > However it is ultimately not possible to replicate because
Is this a question about how/if one could replicate its behavior in theory
from ES code, or are you suggesting a change to the existing behavior for
these exotic cases?
Assuming the former:
The relevant steps are [here](
https://tc39.github.io/ecma262/#sec-serializejsonproperty). The
n containing the
> declaration.
>
> The effect of using these 2 features together is that anything within the
> same function as the declared Symbol will gain access to the internal field
> of all objects using that Symbol as a field name.
>
> On Tue, Jul 31, 2018 at 1:36 PM D
> I'd say you've identified the common pattern, but that pattern itself is
a bad use case, and the use of private symbols as you have defined them
doesn't do anything to correct the technical issue.
I think there’s been a misunderstanding. Everybody agrees that that’s a bad
pattern. It’s not what
>
> TL;DR: private symbols that proxies can't see and that can't be enumerated.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Sun, Jul 29, 2018 at 12:23 AM, Darien Valentine
> wrote:
> >> What you're essentially asking f
e API to enable inheritance
> from native objects even without using `class`. The syntax changes for
> simplifying private field declaration are just an extension of that. Even
> though it's not unusual for some developers to spend a lot of time working
> with fringe use-cases, syntax
`class` syntax to look like this:
>
> ```js
> class [] [extends ] [mixes
> [, [, ...]]] { ... }
> ```
> so that the private fields of the objects in the `mixes` list are added to
> the set of private fields provided by the `class` definition directly. That
> would also r
To put this another, much briefer way, here’s a hypothetical model for
associating private state with objects that would cover me. Privacy would
be provided...
1. in the form of symbolic keys whose presence cannot be observed (i.e.,
they would not be exposed by `getOwnPropertySymbols`)
2. and
Ranando, I share your reservations about private fields being bound too
tightly to class syntax. In my case it isn’t because I don’t want to use
classes, but rather because in the last few years, using the WeakMap
solution, a good number of times I’ve needed to do things which the private
field
> That, and that the existing builtins already impose those limitations -
and only class allows you to do those things, with them.
I’m surprised by that statement — it appeared to me that it currently
remains possible to create classes, including classes that extend
built-ins, with class syntax.
o also override `catch` (and the same for
> `finally`, which also calls into `then`).
>
> On Fri, Jul 20, 2018 at 4:29 AM, Darien Valentine
> wrote:
>
>> In `Promise.prototype.then`:
>>
>> > 1. Let promise be the this value.
>> > 2. If IsPro
In `Promise.prototype.then`:
> 1. Let promise be the this value.
> 2. If IsPromise(promise) is false, throw a TypeError exception.
> [ ... ]
In `Promise.prototype.finally`:
> 1. Let promise be the this value.
> 2. If Type(promise) is not Object, throw a TypeError exception.
> [...]
In
; };
>
> obj.demo({ x: 5 });
> obj.demo({ x: undefined });
> ```
>
> This will log twice, where it only needs to trigger it once.
>
> jhpratt
>
> On Wed, Jul 4, 2018 at 8:16 PM, Darien Valentine
> wrote:
>
>> > My thought was to have the following: this.foo ?= par
> My thought was to have the following: this.foo ?= params?.foo; which can
be desugared to if (($ref = params?.foo) !== undefined) { this.foo = $ref; }
Are there any specific advantages to the new syntax you’re describing?
Initially, it appears to me like a less powerful form of an existing
is a risk with the import operator since it's input is not part
> of an already trusted input.
>
> On Tue, Jun 19, 2018, 8:22 PM Darien Valentine
> wrote:
>
>> Mike: Ah, cool, I didn’t realize that — I had thought that nonces were
>> just for whitelisting inline script el
since it doesn't allow
> XSS unless one can already specify an import statement which typically
> means one can specify arbitrary JS. That argument doesn't extend to the
> import operator though so you'd have to tolerate assymetry there.
>
> On Tue, Jun 19, 2018, 7:57 PM Darien Valentine
Andrea: That is a really interesting approach. I would point out that using
data URIs for js means the `data:` scheme has to be a permitted source for
script-src. This allowance has roughly the same security implications as
permitting `unsafe-eval`. I know most people aren’t using CSPs yet, but
```
import getPersonType from 'data:text/javascript,\
export default function getPersonType(person) {\
switch (person) {\
case \'Teacher\': return \'A teacher\';\
case \'Director\': return \'A director\';\
}\
}';
```
okay, not a serious suggestion, but it does technically
I usually say "function function," but yeah ... it’s painful haha. I
sometimes work with devs whose experience with ES functions is limited to
methods and arrow functions, so "normal function" doesn’t really fly
anymore. I’ve considered "classic function," but that probably wouldn’t
help much.
I
> There might also be occasions when we want to do something like this:
>
>const { bar } = foo,
> { baz, blah } = bar;
>
> Here, we might find it useful to get deconstructed references to both bar
and its properties baz and blah, but we have to do it in two steps.
Unless I’m
> To clarify, I was basically proposing exposing both the MNSEO with all
export members (like * as foo) as well as live bindings from the module,
separately. Something along the lines of a combination of the two.
Though I agree it would be nice to be able to do that in a single
statement, too,
@Andrea I think we are thinking along the same lines. I meant proxy with a
lowercase p — what you described fits the bill.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
1. (Caching of same-subset namespace import) My gut feeling was that the
simplest thing to do would be to treat `import { x, y } as foo from 'foo';`
as _always_ creating a new MNSEO or — more likely? — not an MNSEO directly,
but a proxy of it whose only job is to filter access. That is, internally
> Those {} that you see in the export and import statements are not
objects, it is just syntax. Yes, I know, people confuse them with objects,
until they realize they aren’t. We probably should have chosen a different
syntax to signal that it is a binding from the module’s environment record.
Not
> tree-shaking is incompatible with class-inheritance and meta-programming
in javascript. it has negligible effect in practice, unless the majority of
your code uses static-functions instead of classes.
It’s just a form of dead code elimination that takes advantage of the fact
that imports/export
> [...] in most cases number suffixes/literals/syntaxes are just sugar, and
must
> be processed at compile-time (0xFF00 syntax is also just sugar).
Probably everybody has a different idea of what "sugar" is, but to me
something is sugar when it can be _desugared_ to some more complex thing
> To me this seems like such a no-brainer that I'm actually surprised that
this isn't possible already.
I think it’s a no-brainer now that we’ve all been using import/export in
practice for a while, but it’s understandable that it might not have been
obvious on the first pass.
I don’t know how
I think there is a pretty good case to be made for native support for
pattern-based formatting as the OP described. I believe it has prior art in
other languages and, while the highly configurable, internationalized
formatting provided by `Intl.DateTimeFormat.prototype.format` is very
valuable,
Hm, I’m sorry, but I don’t follow. The accessor + shadow property pattern
is a (rather common?) way to achieve lazy instantiation of properties,
since it provides the necessary hook for "do this on first access". But I’m
not suggesting it as a new solution in any case, I was only commenting on
the
better, I
> cannot think of a single case I've had so far that would've been
> problematic.
>
> I use the `in` operator and you should probably do the same if that's a
> concern, or maybe explain why/when/how that could be a concern.
>
> Regards
>
>
>
>
> On
I use the WeakMap approach, too. Recently I find myself writing classes
where the class has a corresponding WeakMap holding the "shadow instances"
(as opposed to having one WM per property):
const PRIV = new WeakMap();
class Foo {
constructor() {
PRIV.set(this, { bar: 0,
@logan ah, oops, that was an (incorrect) assumption about the proposed
behavior on my part
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Deferring can mean different things, but generally `then` covers this well
(specifically, pushing execution of something to the end of the current
task).
Promise.resolve().then(stuffToDefer);
I think there is a proposal for `Promise.try(stuffToDefer)`, which would
eliminate the need for the
@Alexander The idea of a generalized `map` function (etc, I’m guessing) is
appealing. From the way you talked about it, it sounds like there may have
been
past discussion on the topic. Are there any proposals for this or major
ideas
being batted around?
> Why? What's the advantage? You lose at
t-2) which is not
concerned with entries and is instead similar to lodash’s keyBy method; it
also permits supplying a target object rather than always creating a new
object.
---
_Gah, I always manage to screw up the recipient field on these threads._
On Tue, Aug 8, 2017 at 2:13 AM, Darien Valent
For a class which is not intended to be subclassable, this can be done today
with `Object.preventExtensions()` or `Object.seal()`, depending on your
intent:
class Foo {
constructor() {
this.bar = 1;
this.baz = 2;
Object.preventExtensions(this);
}
}
> forced into it as an intermediary
Fortunately, no force is involved :)
T.J. Crowder indicated an intention to draft a proposal that I believe
aligns
with your ideas for converting objects to a single object by key with an
all-in-one map+compose method. It is not necessary for there to be only
t to be useful.
Regardless of one’s thoughts on `Map` (which I use quite a bit personally),
the "entries" pattern is well established in ES. (I’d also point out that
adding a method for composition from entries does not preclude supporting
other approaches.)
On Mon, Aug 7, 2017 at 4:
an upcoming proposal
template...?
Yeah — it doesn’t exist yet, however.
On Mon, Aug 7, 2017 at 9:46 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Mon, Aug 7, 2017 at 2:23 PM, Darien Valentine
> <valentin...@gmail.com> wrote:
> > > For me, no; an unnecessa
ing the case for the map argument (in whatever form) — that
could help measure whether that’s something most people expect to see.
On Mon, Aug 7, 2017 at 5:58 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Sat, Aug 5, 2017 at 9:42 PM, Darien Valentine
> <valentin..
Awesome. I didn’t know about the upcoming template, so I may have jumped
the gun haha:
https://github.com/bathos/object-from-entries
It’s quite primitive though, no formal algorithm / ecmarkup or anything.
I’ll keep an eye on the template project and update accordingly once that’s
ready, thanks.
@Isiah I think you and I just described the identical thing (except that
I’d put `fromEntries` where you put `from`) — and it’s a subset of the
overloaded proposed solution from Crowder above. That three people
responded with the same thing or a variation of it suggests that this is
indeed a gap
FWIW, while I find needs like this common, too, where Map is sensible
instead of
Object, it does come out pretty clean:
```
const a = [
{id: "tjc", name: "T.J. Crowder"},
{id: "nc", name: "Naveen Chawla"},
{id: "lh", name: "Lachlan Hunt"}
];
const index = new Map(a.map(member => [
I was checking out the notes at https://esdiscuss.org/notes/2017-07-25 and
got pretty confused:
> We (TC39) have a love / hate relationship with Jaswanth Sreeram.
> There are some things that Jaswanth Sreeram does that is different to the
way other software works [...]
> Browsers are already
> their concerns were dismissed with no argument
I’m curious what the concerns were. You mentioned disliking the syntax, but
I’m guessing there’s more to it than that?
I’ve been experimenting with ES Modules over HTTP 2 for a few months. I
used rollup to create my dep graph without actually
> Both the value and key arguments are equal for Sets
Derp, forgot about that, you’re right. The internal algorithm references
the indices, but they aren’t exposed.
> [examples of unordered reduce]
There are quite a few I think — in fact reductions that are order-agnostic
are a pretty
> Sets are unordered, so actually having `forEach` (without the index
parameter) makes more sense than `reduce`.
When we work with sets, we do often treat them as unordered, like one would
in math I suppose, but the ES data structure does have a defined iteration
order, and its `forEach` method
Here are some related threads from the past:
https://esdiscuss.org/topic/negative-indices-for-arrays
https://esdiscuss.org/topic/array-slice-syntax
https://esdiscuss.org/topic/javascript-language-feature-idea
I think I’ve seen it mentioned a few other times too.
The `arr[-1]` syntax is a
@Vinnymac the distinction is that the `tap` proposed here is not called
per-member, I think.
It has nothing _specifically_ to do with arrays (or iterables generally);
they just happen to be the most common chaining targets. (See the example
implementation from Bob Myers above).
Because tap isn’t
xpect `{+} === {+}` as there is no sense in
> allocating a fresh function object each time it is encountered. Ideally,
> these would be frozen functions that are created once per realm and have
> the same semantics as an arrow function (i.e. [[Call]] but no
> [[Construct]], etc.).
>
>
>
> R
I've often found myself re-implementing this functionality and I am a big
fan of this proposal, minor reservations that I expressed way back about
`Set.prototype.union` vs `Set.union` (etc) aside. Nice work on beginning
the formal spec, I really hope this picks up steam.
Out of curiosity, what is
Minor point regarding the syntax given here: introducing `(/)` would likely
be problematic because it breaks the constraint that there are no positions
in the grammar where both a division operator and a regular expression
literal could be valid continuations.
(Perhaps new built-ins like
I’m not entirely certain of this, but I don’t think that the semantics of
resolving a module specifier string are themselves a facet of the ES spec.
However, I think the issue you’re describing may already be addressed in
the implementations so far (Safari 10.1, Chrome Canary, FF Nightly) because
Looks like the link got cut off:
https://bterlson.github.io/proposal-flatMap/
https://github.com/bterlson/proposal-flatMap
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ing an arbitrary type order if those were the two choices.
On Thu, Apr 13, 2017 at 12:56 AM, felix <feli...@gmail.com> wrote:
> On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine <valentin...@gmail.com>
> wrote:
> >> One common JS problem is NaNs ending up in unexp
ng non-matching types return undefined while
> >> matching types is a Boolean.
> >>
> >> Object.* could just defer to the prototype implementation of the first
> >> value.. null or undefined always returning undefined.
> >>
> >> --
> >>
of ES5 because we know
>>> from context that it's not the `for` statement. But I assume (not being a
>>> parser guy) that it's more complex to handle the above (those "weird line
>>> terminator conditions on the left" Eich mentioned).
>>>
>>> ## Semantics
Although I’m unsure if this is wise given there are already eleven symbols
that are combinations of `=` and `<`/`>`, for symmetry with `==` and `===`
I’d imagine something like this:
```
COERCIVE STRICT
> =>=
< =<=
>==>==
<==<==
```
Could also follow the pattern
Thanks for explaining, Michael. That does make sense, there are indeed
plenty of places where such distinctions must be made for syntactic
productions. I’m not sure why I was assumed the lexical grammar was special
in this regard; it just happens to be that the only other similar case has
the
> On Sun, Apr 9, 2017, 17:13 Darien Valentine <valentin...@gmail.com> wrote:
>
>> I am curious about this lexical production, because if I understand
>> correctly, it seems to imply either backtracking or a lookahead that isn’t
>> made explicit.
>>
I am curious about this lexical production, because if I understand
correctly, it seems to imply either backtracking or a lookahead that isn’t
made explicit.
```
MultiLineComment ::
/* MultiLineCommentChars[opt] */
MultiLineCommentChars ::
MultiLineNotAsteriskChar MultiLineCommentChars[opt]
72 matches
Mail list logo
