Re: Proposal: Typeof Trap

On one hand, I agree with Jordan. Don't grief the language due to a bad 3rd party API. Whether we accept it or not, a browser's API is a 3rd party API with respect to Javascript. Otherwise, node would have to include that API to be spec compliant. On the other hand, let's be a little more

Re: Promise resolution handler fires before synchronous constructor stack has finished.

Isn't it always the case that `Promise.resolve()` returns an immediately resolved Promise? That means that the `.then` clause would get executed immediately as well, which is before you have a chance to set `this.foo`. Seems like what you need to do is something more like this: ```js // class Foo

Re: Proposal: Typeof Trap

What good is the reliability of something that is more often than not useless? Should there be a typeof hook like Symbol.hasInstance? No. `instanceof` was always sketchy due to the ability to exchange prototypes on an object. When `class` came along, it became effectively broken since `class`

Re: First-class Multi-threading support

Devil's Advocate time What can you get from threading that you can't already get on a single thread? If I subclass Promise, make all of the relevant functions return this customized promise, I can create fairly easy to debug code that behaves as though it is multithreaded. I can even go 1

Re: Proposal: Static Typing

Similar but not the same. Within any given scope, a Type declared within that scope would need to be "set-in-stone" to be of any value. Furthermore, for a variable to honor that type, it must be able to carry around an unmodified reference to the tyoe as it existed at the time the variable was

Re: Proposal: Static Typing

ot have mutated > prototype, and so cannot the `num`. > > Typed values will be all shortcuts that behave like a Typed instance. > > That should solves all cases, right? > > > > > > On Thu, Apr 4, 2019 at 8:52 PM Ranando King wrote: > >> > if we bas

Re: Proposal: Static Typing

throw errors > on prototype set attempts. > > > > On Thu, Apr 4, 2019 at 6:11 AM Ranando King wrote: > >> > - If you allow user-defined types, objects can spontaneously change >> their type by mutating their prototype. Thus, you can declare a variable x >> to have

Re: Proposal: Static Typing

> - If you allow user-defined types, objects can spontaneously change their type by mutating their prototype. Thus, you can declare a variable x to have type Foo and check that you're assigning an instance of Foo to it, but the value x can become a Bar (different from a Foo) spontaneously without

Re: Proposal: Static Typing

> Would an error at runtime or compiletime occur here? There's no "compile time" per se in ES, but setting b += '1' when b is strictly typed shouldn't throw an error at all. The type of the '1' would be coerced to a number first, then added to b. If instead it was something like ```js let a:

Re: Proposal: Static Typing

Doesn't V8 already use such a concept to manage optimization? When a reference's structure mutates, V8 generates a new type by extending the previous one with the changes, then kills any affected optimizations around the mutated object, forcing re-optimization. Static types would essentially

Re: Proposal: Static Typing

One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees. On

Re: Destructuring for Array-like objects

Why is that any different or better than const [a, b] = [a, b] ? On Tue, Mar 19, 2019 at 7:59 PM Sultan wrote: > Afford array destructuring to Array-like objects. > > const [a, b] = {0: a, 1: b, length: 2} > > > ___ > es-discuss mailing list >

Re: Proposal For A New Alternative Keyword To “this” For Classes

t; So no, those don't quite reify classes, either. (If something can be fully > transpiled or polyfilled, it doesn't create or reify any new primitives.) > > On Tue, Mar 12, 2019 at 09:51 Ranando King wrote: > >> I get what you're after. I touched on the same things when creating m

Re: Proposal For A New Alternative Keyword To “this” For Classes

I get what you're after. I touched on the same things when creating my private members proposal. The best of approaches for what you want is indeed relying on the lexical scope to act as a binding for all class members. There's just a couple of problems with doing things that way: 1. ES is a

Re: Proposal: throw null operator

Wasn't there a proposal that tend to allow for optional access of undefined fields? ```js let a = { foo: "bar" }; let b = a.bar?.alpha; // b == undefined ``` The point, I believe, was to eliminate the field testing sometimes required to find a nested sub-element, and simply return undefined if

Re: Proposal: Default object method

for the odd construction. On Mon, Jan 28, 2019 at 6:46 AM J Decker wrote: > > > On Sun, Jan 27, 2019 at 10:46 PM Ranando King wrote: > >> Jordan's right. This one is best handled by a function. But if there is >> some reason you need to create callable objects, it's still

Re: Proposal: Default object method

Jordan's right. This one is best handled by a function. But if there is some reason you need to create callable objects, it's still doable, even with ES as-is. Just extend your classes from something like this: ```js class Callable { constructor(defaultFn) { return (...args) => { return

Re: NumberFormat maxSignificantDigits Limit

Here's a wikipedia link for what it's worth. https://en.wikipedia.org/wiki/Extended_precision Look at the *Working Range* section. On Sat, Jan 26, 2019 at 2:03 PM Ranando King wrote: > There's another possibility. C++ was the language of choice back then. It > had a type "long do

Re: NumberFormat maxSignificantDigits Limit

There's another possibility. C++ was the language of choice back then. It had a type "long double", a 80-bit extended double type. It was meant to match Intel's implementation of IEEE 754. This number format can be safely and reversibly converted back and forth with 21 significant digits. On Thu,

Re: Re: Proposal: Class Templates

It can still be made to work... ```js const Abc = (function() { const cache = new Map; function readCache(c, arg, val=new Map) { if (!c.has(a)) c.set(a, val); return c.get(arg); } return (a, b, c) => { // ...optionally do something with a, b,

Re: New Proposal: ES Call Stack

, 2019 at 3:57 PM Ranando King wrote: > We agree trying to learn about the caller should not affect how the caller > works. That's why I was thinking more on the lines of an "id" carried > around by every function object. As long as that "id" uniquely identified >

Re: New Proposal: ES Call Stack

's how you deal with permissions like that: have A know what data B is > allowed to access, then pass B an object with only that data. If necessary, > make the exposed methods form a closure over the relevant private data. > > On Mon, Jan 14, 2019 at 00:50 Ranando King wrote: > &g

Re: Bind function without thisArg

oops forgot to return retval! On Mon, Jan 14, 2019 at 12:01 AM Ranando King wrote: > Bind is just a wrapper function provided by the engine. You can always > create your own: > > ```js > function myBind(fn, ...args) { > let retval = Object.defineP

Re: Bind function without thisArg

Bind is just a wrapper function provided by the engine. You can always create your own: ```js function myBind(fn, ...args) { let retval = Object.defineProperties(function(...a) { console.assert(typeof(fn) == "function"); return fn(...args, ...a) }, { name: { configurable:

Re: New Proposal: ES Call Stack

e and restore global data as needed. > On Sun, Jan 13, 2019 at 22:05 Isiah Meadows > wrote: > >> You may be interested in this: >> https://github.com/tc39/proposal-error-stacks >> On Sun, Jan 13, 2019 at 22:02 Ranando King wrote: >> >>> ES used to have Fu

New Proposal: ES Call Stack

ES used to have Function.caller for traversing the call stack, but apparently this was very problematic for engine development and prevented various optimizations. So now it doesn't work in strict mode which makes it useless for code involving `"use strict"` or `class`. One of the main use cases

Re: Proposal: Array.prototype.count

Either way it goes, there's a lot of ways to do this that are all trivial. On Mon, Jan 7, 2019 at 1:31 PM Pier Bover wrote: > If you need to find the length of a filtered array IMO it makes more sense > and is more obvious to just use filter(). > > On Mon, Jan 7, 2019 at 1:12 PM Засим Александр

Re: Proposal: Array.prototype.count

Isn't that just a specific case of Array.prototype.reduce? ```js const evenNumberCount = [1,2,3,4,5].reduce((acc, val) => { !(val % 2) && ++acc; }); ``` On Mon, Jan 7, 2019 at 1:12 PM Засим Александр wrote: > Hi everyone. This is proposal for Array.prototype.count (or countOf) > method which

Re: Callable objects protocol

uld follow the classes > behavior, IMO > > On Wed, Dec 5, 2018 at 10:46 PM Ranando King wrote: > >> That's the kind of thing I was shooting for with static lexical scope >> variables. There's 2 problems with it given the way things are going >> though. Take a l

Re: Callable objects protocol

ut they need a handleEvent method, own or inherited, >>> in that object). >>> >>> There is at least another use case I can't remember now, but I do >>> remember doing the Proxy dance before ending up realizing that the apply >>> hook needs ob

Re: Callable objects protocol

Maybe I asked it wrong. How is making an ordinary object callable at all useful for anything that can't already be easily handled via objects and functions? (looking for use cases here) How does this make coding easier to do and understand? (for the AST parser and for the human) On Tue, Dec 4,

Re: Callable objects protocol

> > class prototype { > [Symbol.callable](...args) { return args.length ? this.value = args[0] : > args[0] } > } > > const a = new prototype() > > assert(a(1) === 1, a() === 1) > > On Wed, Dec 5, 2018 at 1:15 AM Ranando King wrote: > >> Thinking again, this might b

Re: Callable objects protocol

Thinking again, this might be a request for static lexical scope variables such that: ```js function obj() { static value = { test: 42 }; return obj.value; } var a = obj(); assert(obj() === a); ``` On Tue, Dec 4, 2018 at 4:05 PM Ranando King wrote: > Ok maybe I'm thinking a lit

Re: Callable objects protocol

Ok maybe I'm thinking a little to literally, but isn't a function already a callable object? ```js function obj() { return obj.value; } obj.value = "value"; assert(obj() === "value"); ``` On Tue, Dec 4, 2018 at 1:16 PM Isiah Meadows wrote: > Edit: the wrapper needs to be a function, so

Re: What is holding back Decorators ?

Thanks for the links T.J. I'm glad to see they're going forward with decorators though I'm a bit confused as to why they'd want to do `@dec export`. That makes it look like the `export` directive is the target of the decorator. Weird. There was something I saw that disturbed me deeply. > DH: I

Re: What is holding back Decorators ?

I'm not from TC39, but I can hazard a guess. Decorators are somewhat useless without data properties to modify. Currently, class-fields is the proposal du jour, but even while in stage 3, it has issues, requiring trade-offs that many have voiced an unwillingness to accept. The awful syntax is

Re: New: proposal-class-modifiers

s constructors being the sole exception. That > complicates the mechanism tremendously, since prototype-based inheritance > alone can't enforce this unless you make `Object.setPrototypeOf(obj, > parent)` no longer directly equivalent to `obj.[[Prototype]] = parent`. > >> On Sun, Dec 2,

Re: New: proposal-class-modifiers

uct`, and > `Object.setPrototypeOf`? > On Sun, Dec 2, 2018 at 16:16 Ranando King wrote: > >> This proposal is intended to add `abstract` and `final` to `class` >> definitions so as to modify the inheritability of a class. >> >> https://github

Re: New: proposal-common-member-modifiers

e it seems like a good feature. Also I'm not a TC39 > member, it's my opinion based in similar discussions in the past, > maybe some real member can clarify it better or correct me if I'm > wrong. > > [1] https://github.com/rdking/proposal-common-member-modifiers#motivation > [2] https://tc

New: proposal-class-modifiers

This proposal is intended to add `abstract` and `final` to `class` definitions so as to modify the inheritability of a class. https://github.com/rdking/proposal-class-modifiers ___ es-discuss mailing list es-discuss@mozilla.org

Re: New: proposal-common-member-modifiers

s what decorators are for. > > > > On Sun, Dec 2, 2018, 01:49 Ranando King >> > >> Since some form of data is going to land in ES class syntax, it would > be a good idea if the capabilities of a property descriptor were also > exposed for

New: proposal-common-member-modifiers

Since some form of data is going to land in ES class syntax, it would be a good idea if the capabilities of a property descriptor were also exposed for all public properties. https://github.com/rdking/proposal-common-member-modifiers ___ es-discuss

Re: New: proposal-safe-prototype

> Should the last line trigger copy-on-write around `a.__proto__`? Yes. I get that you think of this as "dreadful action-at-a-distance", but that kind of thing already happens any time the primitive value (including root-level object references) of a property on the prototype changes. The intent

Re: Proposal for faster this assignments in constructor functions

Arguments is only deprecated in strict mode. ```js F(arg) { let {par1, par2, ..., parN} = arg; Object.assign(this, arg); } ``` This version works in strict mode, but it's less clear what parameters should be passed. I used `Object.assign` because I assumed that `F` was called with `new`,

Re: Proposal for faster this assignments in constructor functions

; F({par1, par2, ..., parN}) { > Object.assign(this, arguments); > } > ``` > This is briefly explained on github, anyway you'll get an undesired > 'length' property. > > Il giorno mer 28 nov 2018 alle ore 22:20 Ranando King > ha scritto: > >> What abo

Re: Proposal for faster this assignments in constructor functions

What about this: ```js F({par1, par2, ..., parN}) { Object.assign(this, arguments[0]); } ``` On Wed, Nov 28, 2018 at 2:20 PM Simo Costa wrote: > @Claude > > Your suggestion is still too much verbose/ripetitive in my opinion because > you repeat the `this`keyword. I agree with the "limited use

Re: New: proposal-safe-prototype

e *used with* existing code can't break. It's totally > fine for existing code that works with objects produced by new code to > break. > > On Tue, Nov 27, 2018 at 11:05 AM Ranando King wrote: > >> Is this to say that no new feature is allowed to introduce breaking >> cha

Re: New: proposal-safe-prototype

type object exhibits the new behavior. Will that suffice? On Tue, Nov 27, 2018 at 1:05 PM Ranando King wrote: > Is this to say that no new feature is allowed to introduce breaking > changes in existing code? > > On Tue, Nov 27, 2018 at 1:00 PM Jordan Harband wrote: > >> Wh

Re: New: proposal-safe-prototype

pply to new code that > explicitly opts in to it. > > On Tue, Nov 27, 2018 at 10:55 AM Ranando King wrote: > >> > Not something you'd want to do often... >> >> Or ever. This is the foot-gun behavior. The same result can be achieved >> with a simple fact

Re: New: proposal-safe-prototype

mple(); const e2 = new Example(); console.log(e2.constructor.counter); // 0 ++e1.constructor.counter; console.log(e2.constructor.counter); // 1 ``` On Tue, Nov 27, 2018 at 10:30 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Tue, Nov 27, 2018 at 3:34 PM Ranando King

Re: New: proposal-known-keys

inherited copies also own > properties. > > > > On Tue, Nov 27, 2018 at 8:36 AM T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > >> On Tue, Nov 27, 2018 at 5:14 AM Ranando King >> wrote: >> >> Do you have any evidence to back up the assertions in t

Re: New: proposal-safe-prototype

.@farsightsoftware.com> wrote: > On Tue, Nov 27, 2018 at 3:24 AM Ranando King > wrote: > > ...and from a class POV, the prototype serves the role of the > > class template... > > Not in a prototypical language. Again, prototypes are living objects > (even thou

Re: New: proposal-known-keys

Forgot to addd the link https://github.com/rdking/proposal-known-keys On Mon, Nov 26, 2018 at 11:11 PM Ranando King wrote: > This proposal adds 7 new static methods to `Object` that add support for > dealing with all of the enumerable properties of objects with prot

New: proposal-known-keys

This proposal adds 7 new static methods to `Object` that add support for dealing with all of the enumerable properties of objects with prototypes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: New: proposal-safe-prototype

I've always understood the purpose of a prototype to be a means of including pre-defined data and behavior in an object. Classes are just a convenient means of defining those things in a prototype-oriented language, and from a class POV, the prototype serves the role of the class template. You did

New: proposal-safe-prototype

The general idea is to eliminate the foot-gun of objects on a prototype by providing copy on write semantics to properties on the prototype that contain an object. The property must be a data property. Accessors and functions are ignored. https://github.com/rdking/proposal-safe-prototype

Re: Destructuring instances with private fields

that's a no-go as well. On Thu, Sep 6, 2018 at 10:45 AM Isiah Meadows wrote: > BTW, this just falls out of the grid with my private symbols suggestion > https://github.com/tc39/proposal-class-fields/issues/115 > > On Thu, Sep 6, 2018 at 10:14 Ranando King wrote: > >>

Re: Destructuring instances with private fields

I can understand why this would be wanted. It would save some excess typing. However, doesn't it also lead to the potential foot-gun of forgetting to assign any modifications back to the original private field? Also, since private fields aren't actually own properties of the instance, how could

Re: constructor, super, and data members issue

ctly in a class field is extremely > niche, and by doing that, the user "should know what they've done" too. > > On Mon, Sep 3, 2018 at 3:44 PM, Ranando King wrote: > >> That scenario is intentional. I see no need to ban it. I would only want >> to ban the conf

Re: constructor, super, and data members issue

Jordan Harband wrote: > `field = (function () { return class { }; }())` - how exactly would you > propose banning creating a class inside class fields? > > On Mon, Sep 3, 2018 at 12:05 PM, Ranando King wrote: > >> I've been thinking about the problems around this some more. At fi

Re: constructor, super, and data members issue

be by the time they are needed in the code. On Mon, Sep 3, 2018 at 2:05 PM Ranando King wrote: > I've been thinking about the problems around this some more. At first I > couldn't get past the dissenting arguments from issue #123, but I've since > come up with a solution that might w

Re: constructor, super, and data members issue

I've been thinking about the problems around this some more. At first I couldn't get past the dissenting arguments from issue #123, but I've since come up with a solution that might work. What if: * Make it illegal to define a class directly on a class field in a class declaration. * Move the

Re: __line_number__ and __filename__

Realistically, the engine would give back file name and line number (and hopefully character offset) of the code from the fully translated, fully minified, actual logic that the engine loaded. Source maps could be used to convert that obscure value back into actual original source code locations.

Re: constructor, super, and data members issue

Aaron, congratulations! You just tripped over a new reason for me to revive issue #123. The only way to get that to work is to have the default values on the prototype. The problem comes because `this` doesn't even have a value until the last call to `super()` returns. If a `class` doesn't have a

Re: proposal: Object Members

for a different proposal. On Sun, Aug 5, 2018 at 9:41 AM Ranando King wrote: > Just released the POC code for review. Using the `Privacy()` export, you > can now wrap any class or object definition and add `private` and > `protected` members. To add privileged members to a `class`, declare a &

Re: !Re: proposal: Object Members

> To discover what's written into the supposedly private x, just call SetX on an object that's not an instance of Foo. Actually, it's fairly trivial to avoid that issue in the engine. As long as both objects and functions know what private data they have access to, then all you need is a check to

Re: Class data member declarations proposal idea

Did you see any similarity with my proposal-object-members ? It doesn't have type annotation either. However, that's probably something best left to a separate proposal since it would affect private and public members alike. On Wed, Aug 8, 2018

RE: proposal: Object Members

Just released the POC code for review. Using the `Privacy()` export, you can now wrap any class or object definition and add `private` and `protected` members. To add privileged members to a `class`, declare a function `static [Privacy.Data]() {}` and return an object containing your `public` data

Re: !Re: proposal: Object Members

hing like > `Object.defineProperty(Foo.prototype, "bar", {value() {return 22; }, > private: true})`. > > Or when classes get instance variables: > > ``` > class Foo { > bar = 22; > ``` > > Was anything along these lines already brought up in this discuss

Re: !Re: proposal: Object Members

to Bob: Minor correction. One other thing both proposals agree on is that dynamic addition of private properties is a bad idea. So the use of Object.defineProperty() is simply a non-starter. On Sat, Aug 4, 2018 at 2:40 PM Ranando King wrote: > to Bob Myers: > This is exactly th

Re: !Re: proposal: Object Members

ught to be extensible to class notation: >> >> ``` >> class Foo ( >> bar(): { return 22; } >> } >> ``` >> >> which would end up being something like >> `Object.defineProperty(Foo.prototype, "bar", {value() {return 22; }, >> pri

Re: !Re: proposal: Object Members

not the case, then there's no point in keeping these (or indeed any) keywords in reserve. On Fri, Aug 3, 2018 at 4:24 PM Ranando King wrote: > Good argument. However, the fact that the wide adoption `private` and > `public` in other languages constitutes an immediately understood, > well-r

Re: !Re: proposal: Object Members

here.) >> >> 2. `protected` on an object literal is next to useless. I've used that >> >> kind of feature almost never. >> >> >> >> I also find it odd you're supporting private dynamic properties. It >> >> does make polyfilling next to impossib

Re: !Re: proposal: Object Members

to add and remove properties from an object at any time. I am not supporting that for private/protected members (unless someone can logically convince me it's a good idea). On Fri, Aug 3, 2018 at 1:02 PM Isiah Meadows wrote: > Inline > > On Fri, Aug 3, 2018, 11:12 Ranando King wrote: >

Re: !Re: proposal: Object Members

unique weakmap instance > for the subclass. > > I actually think it's pretty straightforward and simple. > > On Friday, August 3, 2018, Ranando King wrote: > >> > 1. It's *super incredibly boilerplatey* and verbose syntactically. >> >> I'm not sure what you

Re: !Re: proposal: Object Members

> 1. It's *super incredibly boilerplatey* and verbose syntactically. I'm not sure what you mean by "boilerplatey". As for being verbose, I'm just using the keywords everyone understands for this purpose. IMO, there's no advantage in trying to find some shorthand to do the same thing just because

Re: !Re: proposal: Object Members

Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > > On Wed, Aug 1, 2018 at 2:18 AM, Ranando King wrote: > >> If you go back a few months, what you're proposing is *very* similar, at > >> least functionally, to my previous iteration of my proposal: &

Re: !Re: proposal: Object Members

n you do things with private symbols. > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > > On Tue, Jul 31, 2018 at 3:09 PM, Ranando King wrote: > >> What use case are you referring to here? > > > > In the case of SymbolTree, the object

Re: !Re: proposal: Object Members

rete difference is >> that proxy hooks don't fire when you do things with private symbols. >> >> - >> >> Isiah Meadows >> cont...@isiahmeadows.com >> www.isiahmeadows.com >> >> >> On Tue, Jul 31, 2018 at 3:09 PM, Ranando King wrote: >>

Re: !Re: proposal: Object Members

; about wrt the object members proposal probably would be able to cover them, > though I would still tend to favor a more generic and simple solution. > > On Tue, Jul 31, 2018 at 3:09 PM Ranando King wrote: > >> > What use case are you referring to here? >> >> In

Re: !Re: proposal: Object Members

> What use case are you referring to here? In the case of SymbolTree, the objects in use are external. > I think there’s been a misunderstanding. Everybody agrees that that’s a bad pattern. It’s not what the point of private symbols would be. It’s not a target use case. That certainly puts my

Re: !Re: proposal: Object Members

/js-symbol-tree/blob/master/lib/SymbolTree.js#L28 > [3]: > https://github.com/jsdom/jsdom/blob/23d67ebec901b3471b84e63f58a96b51a36f3671/lib/jsdom/browser/Window.js#L80 > [4]: https://github.com/jsdom/jsdom/search?q=_globalProxy > [5]: > https://github.com/jsdom/jsdom/blob/a

Re: !Re: proposal: Object Members

class, because of how many "methods" there are > operating on the state.) > > [1]: https://github.com/jsdom/js-symbol-tree > [2]: https://github.com/isiahmeadows/enigma/blob/master/src/parser.ts > > - > > Isiah Meadows > cont...@isiahmeadows.com &

Re: !Re: proposal: Object Members

I meant to say if the object passed to the 3rd party function. On Mon, Jul 30, 2018 at 7:59 PM Ranando King wrote: > Just that use case alone is problematic. If the 3rd party function is not > extensible, then the new private data should not be allowed. If the library > cannot

Re: !Re: proposal: Object Members

Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > > On Mon, Jul 30, 2018 at 8:04 PM, Ranando King wrote: > > So you're wanting the ability for a 3rd-party function to be able to > store > > data private to that library on an object it didn'

Re: !Re: proposal: Object Members

So you're wanting the ability for a 3rd-party function to be able to store data private to that library on an object it didn't create, and that only that library can access? On Mon, Jul 30, 2018 at 6:36 PM Isiah Meadows wrote: > First, my private symbols are properly *private*. The only >

Re: !Re: proposal: Object Members

gt;> >> >> > the >> >> >> >> > relationships between HTMLFormElement, >> HTMLFormControlsCollection >> >> >> >> > and >> >> >> >> > the >> >> >> >> > various form

Re: !Re: proposal: Object Members

mire your dedication! I’m also digging the discussion. I > think we may be representing viewpoints at opposite extremes here, so it’s > an interesting contrast, but it also probably means we may be lacking some > context for understanding one another’s angles. I’d be curious to hear mor

Re: !Re: proposal: Object Members

two critical ways, symbol keyed > properties. That said, “real” slots would continue to have an advantage > with regard to cross-realm stuff even if private symbol keys existed. > > That such a model is radically simpler — minmax and all that — feels very > important to me, but I dunno.

Re: JSON support for BigInt in Chrome/V8

What I meant by complete is that if the value isn't an ES Number, isn't a boolean, and isn't null, it will have a string representation, or a binary representation that can be encoded as a string using base64. By using a dataUri for those cases, we can create a consistent library to handle those

Re: !Re: proposal: Object Members

In a word... wow. You've got me thinking hard here. Those are some peculiar use cases, and they do a great job of highlighting why someone might forego using `class`. One thing both proposal-class-fields and proposal-object-members have in common is that the focus is on producing instance-private

Re: JSON support for BigInt in Chrome/V8

structures could be encoded as well, but the suggestion I've just made can even be used to encode that. On Sat, Jul 28, 2018 at 10:52 AM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-07-28 16:52, Ranando King wrote: > > Why not just use DataURL syntax,

Re: JSON support for BigInt in Chrome/V8

Why not just use DataURL syntax, something like this: ```js { "field1": "data:json/bigint,12345678901234567890123456789012345678901234567890123456789012345678901234567890", ... } ``` This way, even as other objects pop up to be serialized, all that would be needed is another mime type in the

Re: proposal: Object Members

object > has an "id" private field, but access or alter its contents. > > On Fri, Jul 27, 2018 at 9:37 PM, Ranando King wrote: > >> > The proposal commingles static and instance private properties. In >> the first example, you could read or write this#.field2,

Re: proposal: Object Members

wrote: > On 07/26/2018 01:55 PM, Ranando King wrote: > > I've just finished updating my proposal with an [Existing proposals]( > https://github.com/rdking/proposal-object-members/blob/master/README.md#existing-proposals) > section that lists the major differences. > > Reading the propo

Re: proposal: Object Members

I've just finished updating my proposal with an [Existing proposals]( https://github.com/rdking/proposal-object-members/blob/master/README.md#existing-proposals) section that lists the major differences. On Thu, Jul 26, 2018 at 9:00 AM Ranando King wrote: > Thank you for the advice. Th

Re: javascript vision thing

Here's the funny part: JSON = JavaScript Object Notation If the OP wants to see improvements in JSON, why not just submit a proposal to alter what ES can do with JSON? If it makes it to stage 4, there's a pretty good chance that the standard for JSON will also change as a result. Sitting around

Re: proposal: Object Members

Thank you for the advice. Those will be the next updates I make to the proposal. On Thu, Jul 26, 2018 at 3:32 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Thu, Jul 26, 2018 at 7:28 AM, Ranando King wrote: > > Let me see if I can clarify things a bit: > &

Re: [proposal] Persistent variables in functions/methods

Even if we don't get do expressions, the proposal I've recently submitted includes this ability as a side effect. https://github.com/rdking/proposal-object-members/blob/master/README.md On Wed, Jul 25, 2018 at 6:42 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Wed, Jul 25, 2018

Re: proposal: Object Members

. On Wed, Jul 25, 2018 at 2:23 AM T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Mon, Jul 23, 2018 at 8:38 PM, Ranando King > wrote: > > I've written up a new draft proposal based on my own work with ES5 & ES6 > > compatible classes with fields. That can be

  1   2   >