Conditional assign operator

[Sultan]

The following would assign to the address foo in obj if and only if it has
not already been assigned.

var obj = {}
var foo = Math.random()
obj[foo] ?= 1

The same can be said for:

var undef
undef ?= 1

Which could both be transpired to

type obj[foo] === 'undefined' && obj[foo] = 1

or

type a === 'undefined' && undef = 1

respectively.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Sultan]

The pattern matching proposal does not handles the mentioned case:

switch(type) { case 0...5: } being the equivalent of switch(type) { case 0:
case 1: case 2: case 3: case 4: case 5: }

On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
wrote:

> I agree with Oriol.
> We already have the proposal pattern matching, that has a very similar
> effect.
> I think that is better to improve pattern matching proposal in order to be
> able to match using ranges (or at least check if it's good to do) instead
> of create a new proposal.
>
> On Fri, 31 Jan 2020 at 14:08, Oriol _  wrote:
>
>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>
>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>
>> For example, the following:
>>
>> switch (value) {
>> case 0...9: break
>> case 'a'...'z': break
>> }
>>
>>
>> ___
>> es-discuss mailing 
>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

syntax for case ranges

[Sultan]

For example, the following:

switch (value) {
case 0...9: break
case 'a'...'z': break
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Sultan]

Can you currently do this with the "super" keyword outside of classes?

On Fri, Sep 6, 2019 at 9:16 PM Jordan Harband  wrote:

> `var itself = 3;` means that your choice of keyword wouldn't be an option;
> you'd be limited to something that was currently a syntax error.
>
> On Fri, Sep 6, 2019 at 2:53 AM Cyril Auburtin 
> wrote:
>
>> also optional-chaining will help
>> ```js
>> return {
>> ...state,
>> child: {
>> ...state?.child,
>> subchild: {
>> ...state?.child?.subchild,
>> property: (state?.child?.subchild?.property ?? 0) + 1
>> }
>> }
>> }
>> ```
>>
>> @Herby yes that's interesting, works in any order actually `const {child,
>> child: {subchild}} = state;`
>>
>> On Fri, Sep 6, 2019 at 11:23 AM Herby Vojčík  wrote:
>>
>>> On 6. 9. 2019 10:34, Cyril Auburtin wrote:
>>> > You could currently do
>>> > ```js
>>> > object.child.property /= 5
>>> > ```
>>> >
>>> > with destructuring:
>>> > ```js
>>> > const {child: {subchild}, child} = state;
>>>
>>> Wow, I didn't know I can do that. Nice.
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Symbol.inspect

[Sultan]

Like Symbol.iterator, a Symbol.inspect symbol for use in implementing
cross-platform console display introspection.

Currently node has something akin to this with a magic inspect method on
objects.

This would pave a cow path for how different platforms can afford this
ability to consumers without each inventing their own heuristic, i.e in the
browser i might have an exotic object that i want console.error to display
a toString payload instead of the objects shape.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Static Typing

[Sultan]

Counter proposal: A uniform signature for types, denoted by:

const name: primitive-type?;

Where primitive types are denoted as:

const name: symbol;
const name: string;
const name: number;
const name: object;
const name: boolean;
const name: function;

And types can later be extended to afford additional meta data as needed:

const name: string<10>; // string of length 10
const name: number; // floating point number, as opposed to BigInt

const name: object<[]>; // array object
const name: object; // Node object

Union types can get added later, and denoted as:

const name: union;

Functions can later be afforded return and argument types as denoted by:

function fn (a: object<[], number>, b: string<10>?) {
return
}

const fn: function = (a: object<[], number>, b: string<10>?) => {
return
}

On Sun, Mar 24, 2019 at 3:19 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Just my personal thoughts on this.
>
> The way PHP migrated to types has been thought incremental steps, and it
> worked pretty well.
>
> Since types have been demanded by the JS community for a while, I think
> it'd be key to approach JS types not all at once, but through smaller
> iterations.
>
> As example, a proposal with a whole section entitled "Other useless
> things" would easily diverge focus to stuff the is really not necessary at
> this point.
>
> Since types are also pretty much only a tooling convention, starting just
> with the most basic need/help, and iterate more complex cases later on,
> would be probably the best way to go.
>
> Reading though all suggestions, I personally think these would be a no
> brainer to specify and ship as first iteration:
>
>- primitives mean primitives (i.e. `string` means `typeof "string"`,
>no strings attached)
>- Classes and Built-ins mean classes and built-ins (i.e` String` means
>any `instanceof String`)
>- enum could be a new primitive (as in `typeof "enum"`, since static
>and immutable) but also an expression (like classes), for enums defined as
>properties/fields of literals and classes
>- I actually like the `auto` name more than `any`, but without
>signature overloads/rides the use case would be too broad, so that maybe we
>should have a way to also define multiple types (i.e. `const notFullyAuto:
>String|Object|string = value;`)
>- while I know it's pretty common to have `number[]` as type to define
>an array of numbers, I also don't understand why a new syntax should have
>already two different ways to define typed array, i.e. `const
>list:number[]` and `const list:[number]`, so since the latter one is more
>powerful/flexible, to define also multiple key/value pairs, maybe that's
>all we need
>
> With these basics, the JS world would already have a huge change.
>
> Things we might consider, but me might also don't care about, since these
> behaviors are part of the specs:
>
>- `object` would accept `null`, but since there is no `typeof "null"`,
>the way to ensure `null` won't be there is to use `Object` instead. Are we
>OK with that?
>- `number` would accept `NaN` and `-/Infinity`, but IMO that's the
>case also without types, if a number is expected. Are we OK with that?
>- to avoid confusion with binary `|` operations, maybe multiple types
>could be wrapped in brackets, so that `const index:{number|string}` might
>look better?
>
> That's it for my idea on how this could start moving forward.
>
> Best Regards
>
>
>
>
>
> On Sat, Mar 23, 2019 at 9:37 PM IdkGoodName Vilius <
> viliuskubilius...@gmail.com> wrote:
>
>> This is a proposal for static typing. Here is the github repository link:
>> https://github.com/CreatorVilius/Proposal-Static-Typing
>> I think it would be great thing in JS.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Destructuring for Array-like objects

[Sultan]

Afford array destructuring to Array-like objects.

const [a, b] = {0: a, 1: b, length: 2}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Name-spaced cross-realm objects

[Sultan]

The following is currently possible with setTimeout from the browser

const i = setTimeout(() => {})

Where "i" is a number from 0 incrementing towards infinity.

This however has the issue that it is entirely global, and as the title of
the post suggests the idea is to strike a middle ground between global and
name-spaced; That is the ability to create/access your own name-spaced
state similar to Symbol.for. As an example – a name-spaced incrementing
number:

// a.js
const fn = UID.for('namespace')

assert(fn() === 0)
assert(fn() === 1)

// b.js

const fn = UID.for('namespace')

assert(fn() === 2)
assert(fn() === 3)

This however would be implemented in user-land on top of a more general
proposal for creating cross realm name-spaced objects:

// a.js
const obj = Object.for('namespace')

// b.js
const obj = Object.for('namespace')

Where both objects "obj" in the files a.js and b.js would point to the same
object.

Disclaimer: I'm aware all of the above can be implemented with global state
if you disregard the cross-realm requirement.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Introspect bind function targets

[Sultan Tarimo]

For example given a set of values. A function that checks whether the values of 
the object are equal could shallow compare the values of each property in the 
object. However this heuristics falls short for inline/bound functions that 
share the same target/backing but are only different with respect to the 
function “objects" equality.

Consider the following:

function foo (props) {
return shallowCompare(props) ? expensiveOperation(props) : 
memorizedOperation(props)
}

for (var i = 0; i < 10; i++) {
foo({ handleClick: () => {} })
}

The function `handleClick` passed to “foo” always points to the same function 
target even though the closure object passed may be different on each iteration.

Function.isSameTarget(a, b)

Would expose some level of introspection to identify when the function is 
either a bound function referencing the same function target or a closure 
object referencing the same function target.

This would also allow things like:

class A {fn = () => {}}

Function.isSameTarget((new A).fn, (new A).fn) 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Introspect bind function targets

[Sultan]

A way to determine if two bound functions reference the same target
function.

For example:

function proto () {}

const a = proto.bind(null, 1)
const b = proto.bind(null, 2)

console.assert(Function.isSameTarget(a, b))
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Named factory functions

[Sultan]

Where there any attempts to allow factory functions the ability to assume
the name of the binding they are assigned to?

Consider the following:

function factory () { return function () {} }
var foo = factory()
console.assert(foo.name === 'foo')
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Promise.resolve

[Sultan]

Was there any reason Promise.resolve was not afforded the ability to
dispatch outside of `this` pointing to the `Promise` constructor?

For example:

const {resolve} = Promise
resolve(1234)

This currently throws.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dash-case keys

[Sultan Tarimo]

This is expected and by design. For example obj[‘#invalidPrivateSigil’] is also 
not invalid. The affordances would be the same.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dash-case keys

[Sultan Tarimo]

That might have been the case, but the expectation that an unquoted form should 
equally have a quoted form or vice-versa is not an issue in practice given the 
presence of a similar but opposite semantic in the private sigil access 
notation proposal: object.#validPrivateSigil -> object[‘#invalidPrivateSigil’].

In kind, this would exploit the same grammar affordances to be born from this. 

That is obj.font-size would rightly be invalid. The more common interfacing 
with this notation would be through iterators. That is: 

for (var key in object) {
style.setProperty(key, object[key])
}

The addition of which would see to improve the ergonomics with using dash-case 
keys common in the CSS grammar within the object literals syntax.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Dash-case keys

[Sultan Tarimo]

The former as the following is equally invalid syntax errors:

const font = 1
const size = 1

const a = {
font-size: 10
}
const b = {
font+size: 10
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Dash-case keys

[Sultan]

Is there any reason that dash-case keys are not supported in the object
literal syntax.

For example:

const style = {
font-size: 10
}

Compared to what one needs to do today:

const style = {
'font-size': 10
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

De-structuring array arguments

[Sultan]

Consider the following is not possible today:

function foo ([a, b] = [1, 2]) {}

foo([2, 3])

While the the following is outside of function arguments:

const arr = [1, 2]
const [a, b] = arr

Is there any reason for the current status quo?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Named de-structuring arguments.

[Sultan]

The ability to both name and de-structure an argument.

Relying on the spread operator does not archive the same effect considering
that the spread operator "by design" has some short-comings related to
exotic objects when the objects in question have a rich prototype you want
to preserve.

Consider the following proposal:

function fn (arg pick {a, b = arg.b = 'value'}) {}

This would allow four fundamental things of note missing from current
de-structuring status-quo:

1. The ability to have both named arguments and de-structuring.

2. The ability to reference the named argument within the de-structure.
This allows the above pattern of setting a default value on the passed
argument when it doesn't exist.

3. This in turn also affords you the ability to de-structure while also
preserving the exotic nature of an object when it is not a POJO object.

That is when "arg" is an exotic use-defined object using the spread
operator "{...arg}" will discard its prototype.

For example:

function a ({a, ...b}) { return b }

a([1, 2])

Returns a object with index-able keys instead of the array.

4. Consequently this addition would also afford the avoidance of any
overhead that one might want to avoid with the rest spread operation: {a,
b, ...arg} in hot paths.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bind function without thisArg

[Sultan]

The use case was to use bind to avoid closures such that "foo" is attached
to an object on demand.

var obj = {}
// some place else
obj.foo = fn.bind(, 1, 2, 3)

Where the function "fn" relies on this being the "obj" it is attached to,
this considering that calling a bound functions with:

fn.call(thisArg)

Doesn't change the thisArg.

On Mon, Jan 14, 2019 at 9:27 AM Jordan Harband  wrote:

> ```
> var foo = function(a) { console.assert(this === obj) };
> var obj = { foo() { return foo.apply(this, arguments); } };
> ```
> ?
>
> On Sun, Jan 13, 2019 at 10:01 PM 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.defineProperties(function(...a) {
>> console.assert(typeof(fn) == "function");
>> return fn(...args, ...a)
>>   }, {
>> name: {
>>   configurable: true,
>>   value: fn.name
>> },
>> length: {
>>   configurable: true,
>>   value: fn.length
>> },
>> prototype: {
>>   configurable: true,
>>   writable: true,
>>   value: fn.prototype
>> }
>>   });
>> }
>> ```
>>
>> This should apply your bound arguments before any arguments supplied by
>> the caller without affecting the context object.
>>
>> On Sun, Jan 13, 2019 at 11:39 PM Sultan  wrote:
>>
>>> Consider the following example:
>>>
>>> var foo = (function(a) { console.assert(this === obj) }).bind(undefined,
>>> 1)
>>> var obj = {foo: foo}
>>>
>>> Calling foo from obj:
>>>
>>> obj.foo(1)
>>>
>>> Would result in an assertion. How does one go about preserving the this
>>> reference of the caller. That is i want to use .bind to only bind
>>> "arguments" and not "thisArg".
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Bind function without thisArg

[Sultan]

Consider the following example:

var foo = (function(a) { console.assert(this === obj) }).bind(undefined, 1)
var obj = {foo: foo}

Calling foo from obj:

obj.foo(1)

Would result in an assertion. How does one go about preserving the this
reference of the caller. That is i want to use .bind to only bind
"arguments" and not "thisArg".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Placeholder operator

[Sultan]

>empty space with a comma?

I think that only works with trailing params. For example this is not
possible:

const foo = (a,  , c) => {}

>Today, you can write: const foo = (a, b, _) => {}

However that does throw with:

const foo = (a, _, _) => {}

>You can already write: const [ , setState] = useState(0)

Thanks i forgot about that.

On Fri, Jan 11, 2019 at 5:31 PM Claude Pache  wrote:

>
>
> > Le 11 janv. 2019 à 14:02, Sultan  a écrit :
> >
> > Placeholder operator: !
> >
> > Use in function parameters(maintains arity without creating a named
> binding):
> >
> > const foo = (a, b, !) => {}
>
> Today, you can write:
>
> ```js
> const foo = (a, b, _) => { }
> ```
>
> Is the complexity added to the language worth the feature?
>
> >
> > Use in de-structuring(allows you to capture further along a tuple
> without creating a named binding):
> >
> > const [!, setState] = useState(0)
>
> You can already write:
>
> ```js
> const [ , setState] = useState(0)
> ```
>
> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Placeholder operator

[Sultan]

Placeholder operator: !

Use in function parameters(maintains arity without creating a named
binding):

const foo = (a, b, !) => {}

Use in de-structuring(allows you to capture further along a tuple without
creating a named binding):

const [!, setState] = useState(0)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Syntax operator for "default assignment if value doesn't exits"

[Sultan]

An operator syntax for the the "typeof" pattern used to detect if a
environment/object has a value:

if (typeof variable === 'undefined') {...}
if (typeof object.key === 'undefined') {...}

This could manifest in destructuring as the following

var fn = ({ key ||= 1 }) => {
}

And with variables as:

var global ||= {}

Equivalent code:

(arg) => {
if (typeof arg.key === 'undefined') {
arg.key = 1
}
}

if (typeof global === 'undefined') {
var global = {}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.create and Function.create

[Sultan]

>what're the benefits over a object indexed by numbers `const o =
Object.create(null); o[0] = 12; ...`?

Better "optimisable" heuristics in a similar vain to `TypedArrays`. Most
engines have perf cliffs with indexed objects after a certain threshold,

Memory: at some point indexed objects have to grow by some factor(* N of
the current size) until it reaches and exceeds your desired size resulting
in more memory use that you bargained for or at some point the engine could
downgrade it to dictionary-mode for any one reason.

It is a fickle round to cross when you want predictable throughput
performance, TypedArrays afford this, but they are not generic(support any
value).

>About the other function proposal (`Function.create`) I don't see any
benefits in day to day use having a function without prototype

Both the Array.create and Function.create are not meant as day-to-day
data-structures.
They are meant as low-level building blocks for abstraction that might be
used on a day-to-day, abstractions that wish to guarantee better
predictable performance.

>and there'd be no way to get the length or iterate over it if you did.

You don't need a length property to iterate the array if you own and manage
the data-strucure:

Exhibit A:
var len = 10
var arr = Array.create(null, len)
for (var i = 0; i < len; i++) arr[i]

Exhibit B: (tuple)

var arr = Array.create(null, 2)
arr[0] = 'a'
arr[1] = 'b'
return a

In both examples you don't need a length property to access/visit all the
elements in the array given they are both statically known at creation time.


On Fri, Jan 11, 2019 at 12:20 AM Jordan Harband  wrote:

> Sorry if I was unclear; it's *impossible* to have an array without a
> `.length` own property, and there'd be no way to get the length or iterate
> over it if you did. I'm also not clear on why you'd want to store named
> properties on an array, especially if you can't iterate it because it
> doesn't have a length?
>
> On Thu, Jan 10, 2019 at 11:04 AM T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> On Thu, Jan 10, 2019 at 1:54 PM Augusto Moura
>>  wrote:
>> >
>> > If you don't want the iterable features neither the own properties,
>> > what're the benefits over a object indexed by numbers `const o =
>> > Object.create(null); o[0] = 12; ...`?
>>
>> Exactly.
>>
>> And re functions, using them as state containers without their usual
>> features seems like a bad idea^H^H^H^H^H^H^H^H edge case best handled
>> by `setPrototypeOf` and `delete`. :-)
>>
>> -- T.J. Crowder
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.create and Function.create

[Sultan]

>Why would this be better than `const a = []; Object.setPrototypeOf(a,
null)`?

In that example "a" value would still have "own" properties like length.

a = Array.create(null, 10)

Wouldn't have any own or prototype properties by design; It is mean to be
"bare-bones" or as close to a C-like:

a = malloc(sizeof(void*)*10)

as JavaScript could potentially get.

On Thu, Jan 10, 2019 at 11:54 AM Jordan Harband  wrote:

> Why would this be better than `const a = []; Object.setPrototypeOf(a,
> null)`?
>
> On Thu, Jan 10, 2019 at 12:09 AM Sultan  wrote:
>
>> >An array with no prototype wouldn't have any of the iteration methods on
>> it...
>>
>> Yes, that is what is intended with this, similar to an
>> Object.create(null) object with number-ed keys.
>>
>> Alternatively one could look at the objects created from this to be the
>> "bare-bones" structure around these data-structures.
>>
>> That is the in-existence of prototypes and own properties like "length"
>> makes it clear that these "flat" objects are intended as author managed
>> objects.
>>
>> There are is no visible default prototype or own properties because the
>> author will create, expose and managed these for the data-structure
>> explicitly if need be or more commonly choose to not expose the
>> data-structure at all and use these for low-level internal book keeping for
>> other abstractions.
>>
>> This would create a new ceiling(or ground-level) for how "low-level" one
>> could go with JavaScript if these where part for the language and as a
>> secondary consequence allow engines to make stronger assumptions with
>> regards to operations on these structs.
>>
>> On Thu, Jan 10, 2019 at 9:48 AM Jordan Harband  wrote:
>>
>>> An array with no prototype wouldn't have any of the iteration methods on
>>> it; a function with no prototype wouldn't have .call/.bind/.apply - length
>>> and name are own properties of functions, and length is an own property of
>>> an array, so you'd get those regardless.
>>>
>>> (`Array.from({ length: 1000 })` already creates an array of length 1000
>>> without holes, fwiw)
>>>
>>> On Wed, Jan 9, 2019 at 10:43 PM Sultan  wrote:
>>>
>>>> Identical to Object.create but for Arrays and Functions.
>>>>
>>>> This method will allow you to create arrays with no prototype.
>>>>
>>>> This would allow authors the ability to use array objects as state
>>>> containers without the need to resort to index-based objects with
>>>>
>>>> Object.create(null, length)
>>>>
>>>> When you want to both use an array-like struct as both a property and
>>>> index-able map.
>>>>
>>>> A side-effect of this would afford engines a strong heuristic for
>>>> avoiding holey-array look-ups operations when there's no prototype to walk.
>>>>
>>>> For example the following would create an array with a length of 1000
>>>> without "holes".
>>>>
>>>> const arr = Array.create(null, 1000)
>>>>
>>>> In addition this could also apply to functions with
>>>>
>>>> Function.create(null, () => {})
>>>>
>>>> When you want to use functions as state-containers but don't want any
>>>> of the implicit properties(length, name) etc.
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.create and Function.create

[Sultan]

>An array with no prototype wouldn't have any of the iteration methods on
it...

Yes, that is what is intended with this, similar to an Object.create(null)
object with number-ed keys.

Alternatively one could look at the objects created from this to be the
"bare-bones" structure around these data-structures.

That is the in-existence of prototypes and own properties like "length"
makes it clear that these "flat" objects are intended as author managed
objects.

There are is no visible default prototype or own properties because the
author will create, expose and managed these for the data-structure
explicitly if need be or more commonly choose to not expose the
data-structure at all and use these for low-level internal book keeping for
other abstractions.

This would create a new ceiling(or ground-level) for how "low-level" one
could go with JavaScript if these where part for the language and as a
secondary consequence allow engines to make stronger assumptions with
regards to operations on these structs.

On Thu, Jan 10, 2019 at 9:48 AM Jordan Harband  wrote:

> An array with no prototype wouldn't have any of the iteration methods on
> it; a function with no prototype wouldn't have .call/.bind/.apply - length
> and name are own properties of functions, and length is an own property of
> an array, so you'd get those regardless.
>
> (`Array.from({ length: 1000 })` already creates an array of length 1000
> without holes, fwiw)
>
> On Wed, Jan 9, 2019 at 10:43 PM Sultan  wrote:
>
>> Identical to Object.create but for Arrays and Functions.
>>
>> This method will allow you to create arrays with no prototype.
>>
>> This would allow authors the ability to use array objects as state
>> containers without the need to resort to index-based objects with
>>
>> Object.create(null, length)
>>
>> When you want to both use an array-like struct as both a property and
>> index-able map.
>>
>> A side-effect of this would afford engines a strong heuristic for
>> avoiding holey-array look-ups operations when there's no prototype to walk.
>>
>> For example the following would create an array with a length of 1000
>> without "holes".
>>
>> const arr = Array.create(null, 1000)
>>
>> In addition this could also apply to functions with
>>
>> Function.create(null, () => {})
>>
>> When you want to use functions as state-containers but don't want any of
>> the implicit properties(length, name) etc.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Array.create and Function.create

[Sultan]

Identical to Object.create but for Arrays and Functions.

This method will allow you to create arrays with no prototype.

This would allow authors the ability to use array objects as state
containers without the need to resort to index-based objects with

Object.create(null, length)

When you want to both use an array-like struct as both a property and
index-able map.

A side-effect of this would afford engines a strong heuristic for avoiding
holey-array look-ups operations when there's no prototype to walk.

For example the following would create an array with a length of 1000
without "holes".

const arr = Array.create(null, 1000)

In addition this could also apply to functions with

Function.create(null, () => {})

When you want to use functions as state-containers but don't want any of
the implicit properties(length, name) etc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Callable objects protocol

[Sultan]

Yes function objects are already callable objects. This is meant to allow
authors the ability to make callable non-function objects with this new
protocol.

typeof nonFunctionCallableObject === 'object'. As much as Symbol.iterator
is used to determine if a non-native object is an iterator so too would
Symbol.callable with regards to non-function callables.

One of the utilities of this can be visualized in the getter/setter type
callables: fn() gets the value, fn(a) sets the value, this is normally
supplied with methods to allow an outsider the ability to be reactive to
changes of the underlining value something akin to observables.

One way to implement this is as T.J mentioned – using a closure:

function closure () {
  var value = 'value'
  return function (a) { return arguments.length ? value = a : value }
}

Another would be to treat functions as the objects they truly are:

function object () {
function value (a) { return arguments.length ? this.value = a : this.value }
value.value = null
}

Or as this proposal would allow;

An idiomatic class-based implementation with a shared callable protocol
that is extendable by other classes:

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 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 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 ignore that last email.
>>> It's wrong.
>>>
>>> -
>>>
>>> Isiah Meadows
>>> cont...@isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>>> On Tue, Dec 4, 2018 at 2:14 PM Isiah Meadows 
>>> wrote:
>>> >
>>> > BTW, there are proxies [1], and one of the proxy hooks is to intercept
>>> > calls [2].
>>> >
>>> > [1]:
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
>>> > [2]:
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/apply
>>> >
>>> > Your "callable object" proposal would be literally as simple as this
>>> > to implement:
>>> >
>>> > ```js
>>> > const callable = Symbol.for("callable")
>>> > const handler = {
>>> > apply(target, thisArg, argsList) {
>>> > return Reflect.apply(target[callable], thisArg, argsList)
>>> > },
>>> > }
>>> > function makeCallable(obj) { return new Proxy(obj, handler) }
>>> >
>>> > // Your example, ported
>>> > const obj = makeCallable({
>>> > [callable]: function (...args) { return this[Symbol.for('value')]
>>> },
>>> > [Symbol.for(''value')]: 'value',
>>> > })
>>> >
>>> > assert(obj() === 'value')
>>> > obj[callable] = () => 1
>>> > assert(obj() === 1)
>>> > ```
>>> >
>>> > -
>>> >
>>> > Isiah Meadows
>>> > cont...@isiahmeadows.com
>>> > www.isiahmeadows.com
>>> > On Tue, Dec 4, 2018 at 12:02 PM Sultan  wrote:
>>> > >
>>> > > Something along the lines of Symbol.iterator protocol for defining
>>> callback objects i.e: Symbol.callable:
>>> > >
>>> > > const obj = {
>>> > > [Symbol.callable]: function (...args) { return
>>> this[Symbol.for('value')] },
>>> > > [Symbol.for(''value')]: 'value',
>>> > > }
>>> > >
>>> > > assert(obj() === 'value')
>>> > > ___
>>> > > es-discuss mailing list
>>> > > es-discuss@mozilla.org
>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Callable objects protocol

[Sultan]

Something along the lines of Symbol.iterator protocol for defining callback
objects i.e: Symbol.callable:

const obj = {
[Symbol.callable]: function (...args) { return
this[Symbol.for('value')] },
[Symbol.for(''value')]: 'value',
}

assert(obj() === 'value')
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow methods

[Sultan]

Consistency and sugar. Changing from arrow and non-arrow method is a diff
between `=>` where:

foo() {} mirrors foo: function () {}
foo() => {} mirrors foo: () => {}

Also the "this" reference in the second variant is not the class instance
i.e it is part of the shared prototype.

It has an added reach in usefulness when you consider nested classes:

class A {
  foo() {
return class B {
  bar() => {
return this // refers to instance A
  }
}
  }
}

This is not possible today without creating a self-like variable for bar to
reference A's instance; Which is one of the points arrow functions
addressed.

On Fri, Nov 16, 2018 at 11:15 PM Isiah Meadows 
wrote:

> Not sure what the benefit here is:
>
> - You can do `foo: () => bar` for objects
> - You can do `foo = () => bar` for class instances using the public fields
> proposal.
>
> This leaves out self-binding, but you could always use a local variable if
> necessary. (It's like one extra line, maybe 3, and it's not common at all.)
> On Fri, Nov 16, 2018 at 15:09 Sultan  wrote:
>
>> The missing colon ":" is intentional.
>>
>> On Fri, Nov 16, 2018 at 10:57 PM J Decker  wrote:
>>
>>>
>>>
>>> On Fri, Nov 16, 2018 at 11:23 AM Sultan  wrote:
>>>
>>>> As the name suggests; An update to the grammar related to methods on
>>>> objects/classes to support arrow methods:
>>>>
>>>> today: {render() { return 'Hello' }}
>>>> proposed addition: {render() => 'Hello'}
>>>>
>>>> proposed addition: {render:() => 'Hello'}
>>>
>>>
>>>> This could be some-what linked to class fields in the class variant;
>>>> That is what does "this" refer to when used in a class.
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow methods

[Sultan]

The missing colon ":" is intentional.

On Fri, Nov 16, 2018 at 10:57 PM J Decker  wrote:

>
>
> On Fri, Nov 16, 2018 at 11:23 AM Sultan  wrote:
>
>> As the name suggests; An update to the grammar related to methods on
>> objects/classes to support arrow methods:
>>
>> today: {render() { return 'Hello' }}
>> proposed addition: {render() => 'Hello'}
>>
>> proposed addition: {render:() => 'Hello'}
>
>
>> This could be some-what linked to class fields in the class variant; That
>> is what does "this" refer to when used in a class.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Arrow methods

[Sultan]

As the name suggests; An update to the grammar related to methods on
objects/classes to support arrow methods:

today: {render() { return 'Hello' }}
proposed addition: {render() => 'Hello'}

This could be some-what linked to class fields in the class variant; That
is what does "this" refer to when used in a class.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: defer keyword

[Sultan]

What stops you from doing this with try...finally?

function doSomeDbWork() {
try { return databasepool.getConnection(); } finally {
connection.release(); }
}


On Thu, Sep 20, 2018 at 1:01 PM, Ayush Gupta  wrote:

> Apologies, I meant to use `async-await` in the example but I missed it.
>
> Also, cleanup can be needed in all code, no matter if it's synchronous,
> uses promises, callbacks, or `async-await`.  I personally believe that
> while we can have different mechanisms for doing cleanup  in all different
> cases, having a single standard mechanism is better.
>
> On Thu, Sep 20, 2018 at 3:09 PM Ben Wiley 
> wrote:
>
>> If you don't need to do anything in the catch block, you can make it a
>> no-op and put your cleanup statement afterward.
>>
>> However framing this in terms of a synchronous use case seems odd given
>> that synchronous database operations (your example) are extremely rare and
>> in JavaScript. It seems to me like promises would fit this case pretty
>> well, but I may have missed something.
>>
>> Ben
>>
>> Le jeu. 20 sept. 2018 05 h 32, Ayush Gupta  a
>> écrit :
>>
>>> It can be covered, but then I'll have to duplicate the
>>> `connection.release()` call in both the try and catch blocks, (and
>>> remember, there can be multiple resources to be cleaned up).
>>>
>>> Plus, in case that I have a function with multiple if-else branches with
>>> returns from multiple branches, I will have to duplicate that in all the
>>> branches.
>>>
>>> Another benefit of this is that this will help us logically group
>>> allocation and deallocation of resources together, for better readability
>>> and debuggability.
>>>
>>> On Thu, Sep 20, 2018 at 2:57 PM Ben Wiley 
>>> wrote:
>>>
 Hey Ayush,

 That's an interesting language feature I hadn't heard of before.

 Any reason your use case couldn't be covered by a try/catch in the
 synchronous case, and a promise.finally() in the async case?

 Ben

 Le jeu. 20 sept. 2018 05 h 21, Ayush Gupta  a
 écrit :

> Hi,
>
> I would like to propose a `defer` keyword(or something else  as the
> keyword name) which would allow   us to "defer" a function which will be
> executed once the current function either returns or throws.
>
> The idea for this is taken from the Go programming language.
>
> It would allow us to perform cleanup activities in a function which
> has multiple branches in a single place.
>
> For example, a sample server side code can look  like:
>
> ```  js
> function doSomeDbWork() {
> const connection = databasepool.getConnection();
> defer function () { connection.release(); } // function would be
> called no matter when/if the function returns or throws
> //   do your work
> }
> ```
>
> Regards
> Ayush Gupta
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline ES Modules

[Sultan]

They would act akin to hoisted functions declarations in that regard, For
example

```
import {getPersonType} from School

if (Math.random() < 0.5) {
  module School {
export function getPersonType() {}
  }
}
```

Largely yes, the utility is in providing bundlers and authors with a
encapsulated order-independent "concat-able" standard format to output to,
considering the hurdles presented with the "waterfall of requests" problem
that can afflict current native ES modules.

Additionally there are aspects that bundlers have a hard time replicating
when using ES modules as an authoring format. Consider the following
example, where ES modules might maintain a "live" binding.

```
// a.js
import {b} from './b.js'

setTimeout(() => console.log(b), 400)

// b.js
export var b = 1

setTimeout(() => b++, 200)
```

A bundler on the other hand might be forced to produce static bindings.

```
var $b1 = 1

setTimeout(() => $b1++, 200)

var $b2 = $b1

setTimeout(() => console.log($b1), 400)
```




On Mon, Jun 18, 2018 at 4:04 PM, Mike Samuel  wrote:

> How would an inline module be imported?  Module descriptors are roughly
> relative URLs so can refer to a JavaScript source file, but it sounds like
> you'd need something more fine-grained to refer to an inline module.  Using
> fragments to refer to a passage within a document instead of a location
> might have unintended effects.
>
> Also, assuming that problem is solved, does the below mean anything
> if (Math.random() < 0.5) {
>   module School {
> export function getPersonType() {}
>   }
> }
>
> If not, if inline modules are defined eagerly, what advantages, besides
> making life easier for transpiler writers, would inline modules have over
> exporting frozen namespaces?
>
>
>
> On Sun, Jun 17, 2018 at 10:34 AM Sultan  wrote:
>
>> Are there any open proposals/discussions related to creating ES modules
>> inline? For example:
>>
>> ```
>> import getPersonType from School
>>
>> module School {
>>   export function getPersonType (person) {
>>   switch (person) {
>>   case 'Teacher': return 'A teacher'
>>   case 'Director': return 'A director'
>>   }
>>   }
>> }
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Inline ES Modules

[Sultan]

Are there any open proposals/discussions related to creating ES modules
inline? For example:

```
import getPersonType from School

module School {
  export function getPersonType (person) {
  switch (person) {
  case 'Teacher': return 'A teacher'
  case 'Director': return 'A director'
  }
  }
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: allow primitives to be explicitly returned from constructors

[Sultan]

One of the use case for this is – given a function that is either one that
returns an instance or one that returns an explicit return value, but would
otherwise throw if invoked without the "new" keyword.

Always being able to safely invoke it with "new" is a nice guarantee to
have that wouldn't require you to explicitly know before hand whether a
function is a constructor or function.

Now since this does not reflect well on the variants that return primitives
it means you cannot currently always use "new".

Broadly put this could touch on every use case thats involves the need to
know whether a function is a constructor or not before you decide to call
it with "new" or not because not calling it with "new" might throw an error.

On Fri, Apr 20, 2018 at 4:49 PM, Naveen Chawla 
wrote:

> What's the use case? Maybe there's a nice way of doing what you want
>
> On Fri, 20 Apr 2018 at 19:17 T.J. Crowder 
> wrote:
>
>> On Fri, Apr 20, 2018 at 2:23 PM, Oriol _
>>  wrote:
>> > No, `typeof` is not reliable, because it's implementation-defined
>> > for non-standard non-callable exotic objects.
>> >
>> > For example, old IE used to return `"unknown"` in various cases.
>>
>> Also `"object"` for host-provided functions (such as
>> `document.createElement`); IE8 still does that. (Thankfully IE11 doesn't.)
>> (I suppose that would have passed Isiah's `isObject` test anyway, but the
>> point is that `typeof` is, sadly, a weak reed...)
>>
>> -- T.J. Crowder
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

>Do you limit classes to creating only the private fields declared in the
class, or can they create arbitrarily named ones?

Yes, just as you could write arbitrary named fields with the mentioned WeakMap
approach, for example –

[...] private[key] = value
[...] private(this)[key] = value
[...] registry.get(this)[key] = value

and retrieve arbitrary fields

[...] private[key]
[...] private(this)[key]
[...] registry.get(this)[key]

>The full form is expr.#foo, where expr can be `this` or some other
expression appropriate in front of a dot. The #foo binds to the innermost
enclosing class that has a private field called foo. If expr doesn't
evaluate to an instance of that class, you fail and throw.

Is this what you meant?

class A {
  #foo = 1
  constructor() {
let self = this

this.B = class B {
  constructor() {
self.#foo = 2
  }
}
  }
  get() {
return this.#foo
  }
  run(program) {
return eval(program)
  }
}

let a = new A()
let b = new instance.B()

Would this return 1 or 2 or would the previous statement throw?

console.log(a.get())

Additionally would this work

a.run('this.#foo = 3')

---

A similar symmetry can be remarked with regards to:

class A {
  private foo = 1
  constructor() {
const self = this

this.B = class B {
  constructor() {
private(self)["foo"] = 2
  }
}
  }
  get() {
return private.foo
  }
  ...
}

On Wed, Apr 18, 2018 at 2:32 AM, Waldemar Horwat <walde...@google.com>
wrote:

> On 04/17/2018 02:26 PM, Sultan wrote:
>
>> In the transpilation you created the field using "registry.set(this, {id:
>>> 0})"
>>> in the constructor.  If you then claim that any write to the field can
>>> also create it, then you get the hijacking behavior which you wrote doesn't
>>> happen.
>>>
>>
>> The difference between
>>
>> class A {
>>private id = 0
>> }
>>
>> and
>>
>> class A {
>>constructor() {
>> private.id <http://private.id> = 0
>>}
>> }
>>
>> is the likened to the difference between
>>
>> (function (){
>>var registry = WeakMap()
>>
>>function A () {
>>  registry.set(this, {id: 0})
>>}
>>
>>return A
>> })()
>>
>> and
>>
>> (function () {
>>var registry = WeakMap()
>>
>>function A () {
>>  registry.set(this, {})
>>  registry.get(this)["id"] = 0
>>}
>>
>>return A
>> })
>>
>> I don't see how this permits the hijacking behavior previously mentioned,
>> that is –
>>
>> (new A()).write.call({}, 'pawned');
>>
>> Would still fail in the same way for both of these variants.
>>
>
> OK; you split creation into two phases.  That's fine.  Do you limit
> classes to creating only the private fields declared in the class, or can
> they create arbitrarily named ones?
>
> They just lexically scope the private names in their own separate
>>> namespace.  #foo refers to the innermost enclosing class that has a private
>>> field called foo.
>>>
>>
>> I'm not sure i understand, Does #foo refer to this.#foo? Can you post a
>> fleshed out example of this?
>>
>
> The full form is expr.#foo, where expr can be `this` or some other
> expression appropriate in front of a dot.  The #foo binds to the innermost
> enclosing class that has a private field called foo.  If expr doesn't
> evaluate to an instance of that class, you fail and throw.
>
> Read the proposals.
>
> Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

> In the transpilation you created the field using "registry.set(this, {id:
0})"
>in the constructor.  If you then claim that any write to the field can
also create it, then you get the hijacking behavior which you wrote doesn't
happen.

The difference between

class A {
  private id = 0
}

and

class A {
  constructor() {
private.id = 0
  }
}

is the likened to the difference between

(function (){
  var registry = WeakMap()

  function A () {
registry.set(this, {id: 0})
  }

  return A
})()

and

(function () {
  var registry = WeakMap()

  function A () {
registry.set(this, {})
registry.get(this)["id"] = 0
  }

  return A
})

I don't see how this permits the hijacking behavior previously mentioned,
that is –

(new A()).write.call({}, 'pawned');

Would still fail in the same way for both of these variants.

>They just lexically scope the private names in their own separate
namespace.  #foo refers to the innermost enclosing class that has a private
field called foo.

I'm not sure i understand, Does #foo refer to this.#foo? Can you post a
fleshed out example of this?

On Wed, Apr 18, 2018 at 12:09 AM, Waldemar Horwat <walde...@google.com>
wrote:

> On 04/17/2018 01:50 PM, Sultan wrote:
>
>>  >That would contradict your previous answer to the hijacking question.
>>
>> Can you point out the contradiction? The private field is still being
>> written to by the providing class.
>>
>
> In the transpilation you created the field using
>
>   registry.set(this, {id: 0})
>
> in the constructor.  If you then claim that any write to the field can
> also create it, then you get the hijacking behavior which you wrote doesn't
> happen.
>
> Class B is lexically nested inside class A. You want to refer to one of
>>> A's privates from within B's body.
>>>
>>
>> Can you provide an example of what this looks like with the current
>> public/private fields proposals?
>>
>
> They just lexically scope the private names in their own separate
> namespace.  #foo refers to the innermost enclosing class that has a private
> field called foo.
>
> Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

>That would contradict your previous answer to the hijacking question.

Can you point out the contradiction? The private field is still being
written to by the providing class.

>Class B is lexically nested inside class A. You want to refer to one of
A's privates from within B's body.

Can you provide an example of what this looks like with the current
public/private fields proposals?

On Tue, Apr 17, 2018 at 11:20 PM, Waldemar Horwat <walde...@google.com>
wrote:

> On 04/16/2018 05:47 PM, Sultan wrote:
>
>>  >An instance has a fixed set of private fields which get created at
>> object creation time.
>>
>> The implications of this alternative does not necessarily limit the
>> creation of private fields to creation time, for example writing to a
>> private field in the constructor or at any arbitrary time within the
>> lifecycle of the instance.
>>
>
> That would contradict your previous answer to the hijacking question.
>
>  >How do you deal with inner nested classes wanting to refer to outer
>> classes' private fields?
>>
>> Not sure i understood what you mean by this?
>>
>
> Class B is lexically nested inside class A.  You want to refer to one of
> A's privates from within B's body.
>
> Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

>An instance has a fixed set of private fields which get created at object
creation time.

The implications of this alternative does not necessarily limit the
creation of private fields to creation time, for example writing to a
private field in the constructor or at any arbitrary time within the
lifecycle of the instance.

class HashTable {
  constructor() {
private[Symbol.for('length')] = 0
  }
  set(key, value) {
private[key] = value
  }
  get(key) {
return private[key]
  }
}

>How do you deal with inner nested classes wanting to refer to outer
classes' private fields?

Not sure i understood what you mean by this?


On Tue, Apr 17, 2018 at 1:43 AM, Waldemar Horwat <walde...@google.com>
wrote:

> On 04/13/2018 09:41 PM, Sultan wrote:
>
>>  >Writing your private field to an object that's not an instance of your
>> class.
>>  >and then invoking the above write method with a this value that's not
>> an instance of A, such as a proxy.
>>
>> Given:
>>
>> class A {
>>private id = 0;
>>private method(value) {
>>  return value;
>>}
>>write(value) {
>>  private(this)["id"] = private["method"](value);
>>}
>> }
>>
>> I imagine this means trying to do something along the lines of:
>>
>> (new A()).write.call({}, 'pawned');
>>
>> This would fail. The private syntax call site would be scoped to the
>> provider class. For example imagine the current possible transpilation of
>> this:
>>
>> ;(function (){
>>var registry = WeakMap();
>>
>>function A () {
>>  registry.set(this, {id: 0})
>>}
>>A.prototype.write: function () {
>>  registry.get(this)["id"] = 
>> registry.get(this.constructor)["method"].call(this,
>> value);
>>}
>>
>>// shared(i.e private methods)
>>registry.set(A, {
>>  method: function (value) {
>>return value;
>>  }
>>});
>>
>>return A
>> })();
>>
>> Trying to do the the afore-mentioned forge here would currently fail
>> along the lines of cannot read property "id" of  "undefined".
>>
>
> OK, so that aspect of the proposal looks the same as the existing private
> proposals — an instance has a fixed set of private fields which get created
> at object creation time.  There are tricky additional wrinkles when it
> comes to inheritance, but you can look them up in the existing proposals.
>
> Are the only significant changes the different property naming syntax and
> that you provide a way to map strings to private slots?  How do you deal
> with inner nested classes wanting to refer to outer classes' private fields?
>
> Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

>Writing your private field to an object that's not an instance of your
class.
>and then invoking the above write method with a this value that's not an
instance of A, such as a proxy.

Given:

class A {
  private id = 0;
  private method(value) {
return value;
  }
  write(value) {
private(this)["id"] = private["method"](value);
  }
}

I imagine this means trying to do something along the lines of:

(new A()).write.call({}, 'pawned');

This would fail. The private syntax call site would be scoped to the
provider class. For example imagine the current possible transpilation of
this:

;(function (){
  var registry = WeakMap();

  function A () {
registry.set(this, {id: 0})
  }
  A.prototype.write: function () {
registry.get(this)["id"] =
registry.get(this.constructor)["method"].call(this, value);
  }

  // shared(i.e private methods)
  registry.set(A, {
method: function (value) {
  return value;
}
  });

  return A
})();

Trying to do the the afore-mentioned forge here would currently fail along
the lines of cannot read property "id" of  "undefined".



On Sat, Apr 14, 2018 at 1:49 AM, Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> I'd imagine that would fail the same way proxies fail on typed arrays.
>
> > On Apr 13, 2018, at 6:26 PM, Waldemar Horwat <walde...@google.com>
> wrote:
> >
> >> On 04/13/2018 01:38 AM, Sultan wrote:
> >> The proposal is an explainer with regards to an alternative sigil-less
> syntax to back private fields/methods.
> >>> What does private(this)[property] do?
> >> "private(this)[property]" and alternatively "private[property]" or
> "private.property" all invoke access of a private "property" on the "this"
> instance of the class, symmetrical to thesyntax/function nature of both the
> "super" and"import" keywords.
> >>> How do private fields come into existence?
> >> Unless i've misunderstood what is meant by "come into existence" the
> proposals makes use of the reserved "private" keyword to define private
> fields i.e "private id = 1".
> >
> > I was asking about what creates those fields.
> >
> >>> What's private about private fields?
> >> Outside of a private fields provider class, private fields/methods
> would not be accessible.
> >>> How do you prevent them from being forged or stuck onto unrelated
> objects?
> >> What do you mean by this?
> >
> > Writing your private field to an object that's not an instance of your
> class.
> >
> > class A {
> >  private id = ...;
> >  private foo = ...;
> >  write(value) {
> >private(this)["id"] = value;
> >private(this)["foo"] = ... my private secret that anyone outside the
> class must not learn ...;
> >  }
> > }
> >
> > and then invoking the above write method with a this value that's not an
> instance of A, such as a proxy.
> >
> >Waldemar
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

The proposal is an explainer with regards to an alternative sigil-less
syntax to back private fields/methods.

>What does private(this)[property] do?

"private(this)[property]" and alternatively "private[property]" or
"private.property" all invoke access of a private "property" on the "this"
instance of the class, symmetrical to the syntax/function nature of both
the "super" and "import" keywords.

>How do private fields come into existence?

Unless i've misunderstood what is meant by "come into existence" the
proposals makes use of the reserved "private" keyword to define private
fields i.e "private id = 1".

>What's private about private fields?

Outside of a private fields provider class, private fields/methods would
not be accessible.

>How do you prevent them from being forged or stuck onto unrelated objects?

What do you mean by this?

On Fri, Apr 13, 2018 at 1:16 AM, Waldemar Horwat 
wrote:

> I read that proposal but don't understand what the proposal actually is.
> At this point it's a bit of syntax with no semantics behind it.  What does
> private(this)[property] do?  How do private fields come into existence?
> How do you prevent them from being forged or stuck onto unrelated objects?
> What's private about private fields?
>
> Waldemar
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

This is specifically an alternative to the current proposals around private
methods/fields. Specifically motivated by some of the issues discussed in
https://github.com/tc39/proposal-private-methods/issues/28

On Fri, Apr 13, 2018 at 12:13 AM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> This is already being worked on:
>
> - Instance private fields/methods: https://github.com/tc39/
> proposal-class-fields
> - Static private fields/methods:
> https://github.com/tc39/proposal-static-class-features/
> - Recent TC39 meeting:
> https://esdiscuss.org/notes/2018-03-21#10ivb-javascript-classes-11
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Thu, Apr 12, 2018 at 2:11 PM, Sultan <thysul...@gmail.com> wrote:
> > [Strawman] Private methods and fields for JavaScript:
> > https://github.com/thysultan/proposal-private-methods-and-fields
> >
> > ```js
> >
> > class A {
> >   private id = Symbol('unique')
> >   equal(instance, property) {
> > return private(this)[property] == private(instance)[property]
> >   }
> > }
> >
> > const x = new A()
> >
> > x.equal(x, 'id')
> >
> > ```
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

[Strawman] Private methods and fields for JavaScript: https://github.
com/thysultan/proposal-private-methods-and-fields

```js

class A {
  private id = Symbol('unique')
  equal(instance, property) {
return private(this)[property] == private(instance)[property]
  }
}

const x = new A()

x.equal(x, 'id')

```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss