Re: javascript vision thing

2017-11-27 Thread T.J. Crowder 
On Tue, Nov 28, 2017 at 6:40 AM, kai zhu  wrote:
>
> if i were asked what the vision of javascript is my current
> answer would be:
> "javascript is a tool to take JSON-input, manipulate it, and
> output it back out (via DOM, event-handling, network-socket,
> file-io, or db-driver)."

You mean, it's a tool to write computer instructions for taking input,
manipulating it, and generating output? Breaking news: That's what all
programming languages are.

If you mean *specifically* JSON, and *specifically* a DOM, and
*specifically* network I/O and DBs and...well, sorry; as you've been
repeatedly told, *your* vision is at odds with that of the JavaScript
community at large and, I believe, of the committee. JavaScript is bigger
than that. Cope. Because I don't see that changing. Harping on about that
conflict on this list is simply not useful.

> es5 was the epitomy of achieving that vision in the simplest way possible.

Great. Again: Keep using it. Nothing is stopping you or anyone else. The
committee have done a *huge* amount of work to maintain backward
compatibility. (Speaking of which: In all the harping, I don't recall
hearing a thing from you *appreciating* that hard work from the committee.
Did I just miss it?) Yes, it's 99.% instead of 100%, and code
written assuming nothing would ever change (say, values from `typeof`) was
ever-so-slightly impacted. Well, that's unfortunate, but it's very much an
exception to the rule of compatibility, the decision was not made lightly
or without research on impact, and it's not like it takes any significant
time to fix the code in question. Rather less time than complaining about
it on the list, in fact.

You have a different view from most reasonably-informed people on this.
You're entitled to it. As a reasonably-informed person, you're entitled to
express it, and you have. It's time to move on.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: javascript vision thing

2017-11-27 Thread Andrea Giammarchi 
If classes contain all the "super powers" and their instance handle their
own states it's straight forward to serialize JS these days following basic
conventions (easy to do with poisoned objects)

```js
class Serializable {

  // usable as JSON.parse(str, Serializable.fromJSON)
  static fromJSON(key, value) {
if (value.hasOwnProperty('__proto__')) {
  const Class = value.__proto__.split('.').reduce(
(o, k) => o[k],
typeof global === 'object' ? global : window
  );
  delete value.__proto__;
  return Object.create(Class.prototype, value);
}
return value;
  }

  // provide a way to retrieve your class back
  // from a namespace
  static toJSON() {
return this.name;
  }

  // serialize any instance
  toJSON() {
return Object.defineProperty(
  Object.getOwnPropertyDescriptors(this),
  '__proto__',
  {
enumerable: true,
value: this.constructor.toJSON()
  }
);
  }
}

```

Assuming the class is somehow reachable, something that is an issue with
any other language too (the class must be available to properly unserialize)

```js
window.Anything = class Anything extends Serializable {
  constructor(pub, acc) {
super();
this.public = pub;
this.accessor = acc;
  }
  get accessor() {
return this._private;
  }
  set accessor(value) {
Object.defineProperty(this, '_private', {
  configurable: true,
  value
});
  }
};
```

you can serialize and unserialize instances with ease:

```js
const before = new Anything(123, 456);

const serialized = JSON.stringify(before);

const after = JSON.parse(serialized, Anything.fromJSON);
console.log(
  after.public,
  after.accessor
);
```

There are also battle tested utilities to make recursive properties
serializable too (CircularJSON to name one).

Yet, what everyone serliazes and unserializes instead, is some data any
instance could eventually consume so having full classes/instances there
doesn't apparently bring much value.

Serialization is IMO one of those things when you come from capable
langauges you apparently cannot live without, but you forget on your way
with JS and its debugging ability across various environments.

Regards




On Mon, Nov 27, 2017 at 8:17 PM, Florian Bösch  wrote:

> On Thu, Nov 2, 2017 at 4:43 AM, kai zhu  wrote:
>
>> > the primary reason is because traditional oop skills gained from
>> c#/c++/java/python/etc translate poorly to javascript.
>>
> I've never found that to be the case.
>
> >in javascript, class-instantiated objects are inferior to plain-objects,
>> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
>> classes require needless extra serialization/deserialization routines which
>> can easily double your codebase or more (as real-world javascript-code is
>> heavily i/o based). i would say many people burn-out from
>> frontend-programming because they can’t cope with debugging all the i/o
>> edge-cases serializing/deserializing their custom classes.
>> >
>> >javascript and frontend-programming is essentially about efficiently
>> managing the program-state like a baton, constantly passing it
>> back-and-forth between the browser’s ui and various backend-servers /
>> persistent-storage. plain json-objects utilizing idiot-proof
>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>> business than writing classes with custom serializers.
>>
> I dislike many things about JS, and I've been writing JS since 2002. It
> never occured to me, not once, until 3 minutes ago, that this was in any
> way, shape or form some significant JS disadvantage, primary concern of
> anything or even any sort of impediment.
>
> ___
> 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: javascript vision thing

2017-11-27 Thread Florian Bösch 
On Thu, Nov 2, 2017 at 4:43 AM, kai zhu  wrote:

> > the primary reason is because traditional oop skills gained from
> c#/c++/java/python/etc translate poorly to javascript.
>
I've never found that to be the case.

>in javascript, class-instantiated objects are inferior to plain-objects,
> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
> classes require needless extra serialization/deserialization routines which
> can easily double your codebase or more (as real-world javascript-code is
> heavily i/o based). i would say many people burn-out from
> frontend-programming because they can’t cope with debugging all the i/o
> edge-cases serializing/deserializing their custom classes.
> >
> >javascript and frontend-programming is essentially about efficiently
> managing the program-state like a baton, constantly passing it
> back-and-forth between the browser’s ui and various backend-servers /
> persistent-storage. plain json-objects utilizing idiot-proof
> JSON.stringify/JSON.parse, are naturally better at this baton-passing
> business than writing classes with custom serializers.
>
I dislike many things about JS, and I've been writing JS since 2002. It
never occured to me, not once, until 3 minutes ago, that this was in any
way, shape or form some significant JS disadvantage, primary concern of
anything or even any sort of impediment.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

2017-11-27 Thread Sylon Zero 
Sorry, looks like I've posted this in the wrong spot. I will move it to the
WHATWG  group, as recommended.

On Mon, Nov 27, 2017 at 3:49 PM, Sylon Zero  wrote:

> *Core Problem Statement* Processor functions that subscribe to events via
> a topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener *Options*
>  configuration object. These options control how the JS execution
> environment controls the throttling/firing of event handler instances in
> response to events that match the topic string of the subscription created
> by addEventListener.
>
> Proposed options:
>
>- maxInstances [Number / Function] used to decide how many event
>listeners can be invoked before throttling occurs. Throttling does not lose
>events but simply queues them.
>- throttlingQueueLength [Number] used to maintain an in-memory queue
>of un-processed events per Topic string, after throttling kicks in.
>- throttlingQueuePolicy [String] Values could be exception - throws an
>exception when the queue length is exceeded, rolling - drops the
>oldest events and pushes newer ones into the queue, expand- allow the
>queue to expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime Vidas) 
> could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Definition mixins

2017-11-27 Thread dante federici 
I'm having a little trouble parsing your proposed syntax. Can you formalize
it a bit better? Am I write in guessing that it's more like sugar around
bind and composition?

Like, what's going on here?

  mixin obj, mixinFunc1 as method1: privateState, privateStateObj;

I guess I'm wondering why this would be a part of the language and not just
helper functions and a library? Maybe it'd be helpful to represent your
chess example using your proposed syntax...?

Some questions (that may be moot once I actually understand your syntax):
* How does it actually prevent colliding names?
* How does it interact with closures?
* How does it prevent mixins from colliding over shared state?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

2017-11-27 Thread Oriol _ 
`addEventListener` in not part of ECMAScript. It's defined in the DOM spec. You 
should send your proposal to the WHATWG.

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

Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

2017-11-27 Thread Sylon Zero 
*Core Problem Statement* Processor functions that subscribe to events via a
topic string may need to be prioritized for processing based on the topic
itself. Conversely, certain events may be more numerous but should not
limit the ability of the JS environment to respond and process other
events, that may be more critical to either the User Experience (UX) or
integrity of the system (e.g. events that trigger saving data to a
back-end).

*Background Information* As Browser/CommonJS environments bring paradigms
like UI event handling and back-end event handling into the same problem
space, it is useful to apply common patterns used in Message-based
Publish-Subscribe environments with message brokers, which is what the JS
execution context often behaves as. The use case here is to ensure that one
kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
massive differences in event volume or conversely, expensive operations
that block the execution thread in question.

*Proposed Solution* Add metering options to the addEventListener
*Options* configuration
object. These options control how the JS execution environment controls the
throttling/firing of event handler instances in response to events that
match the topic string of the subscription created by addEventListener.

Proposed options:

   - maxInstances [Number / Function] used to decide how many event
   listeners can be invoked before throttling occurs. Throttling does not lose
   events but simply queues them.
   - throttlingQueueLength [Number] used to maintain an in-memory queue of
   un-processed events per Topic string, after throttling kicks in.
   - throttlingQueuePolicy [String] Values could be exception - throws an
   exception when the queue length is exceeded, rolling - drops the oldest
   events and pushes newer ones into the queue, expand- allow the queue to
   expand to cover all events.

*Additional Options* It might be even more useful if the options allowed
targeting or creation of Web Workers (or Node child processes, depending on
the execution context) based on the event handler configuration. This could
potentially target CPU cores and/or O/S child processes / threads
(depending on the O/S terminology for parallel execution).

*Related Thread* The proposal identified in the link below (by Šime
Vidas) could
be part of this solution as it defines other metering options around
debounce (which improves scale around event handling, which is in the same
problem space) and handling throttling through frequency, which should be
one of the alternatives in addition to my proposal above (as I believe they
are orthogonal): https://discourse.wicg.io/t/add-event-
throttling-and-debouncing-to-addeventlisteneroptions/2436/19

Sai Prakash
@SylonZero
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: javascript vision thing

2017-11-27 Thread Jeremy Martin 
> it becomes awkward in javascript when time comes
> around to serializing/reconstructing the custom array-type

To be honest, I've found that overriding `toJSON()` and providing some
static helpers for your `JSON.parse()` reviver lead to pretty expressive
(de)serializability:

class MySerializableArray extends Array {

  toJSON() {
return {
  $type: this.constructor.name,
  items: Object.values(this)
}
  }

  static isSerializedInstance(val) {
return typeof val === 'object' &&
val.$type === 'MySerializableArray' &&
Array.isArray(val.items);
  }

}

const reviver = (key, val) => {
  if (MySerializableArray.isSerializedInstance(val)) {
return new MySerializableArray(...val.items);
  }
  return val;
};

const instance = new MySerializableArray('a', 'b', 'c'),
  serialized = JSON.stringify(instance),
  parsed = JSON.parse(serialized, reviver);

https://jsbin.com/kasiwevobo/edit?js,console

If that's too much boilerplate for you, there's probably some low hanging
fruit for a decorator implementation that generalizes some reasonable
default serialization behavior.


On Sat, Nov 25, 2017 at 2:14 AM, kai zhu  wrote:

> it may be standard-operating-procedure to sub-class builtin arrays in
> other languages.  but it becomes awkward in javascript when time comes
> around to serializing/reconstructing the custom array-type while
> baton-passing it around frontend<->backend<->database via JSON.
>
> On 11/3/17, Andrea Giammarchi  wrote:
> > I agree with everything else you said but since you mentioned the word
> > "misinformed" I'd like to improve this misleading sentence:
> >
> >> It's 99% sugar over the existing prototype-based model
> >
> > This has been one of the most misunderstood and undertaken parts of ES6.
> >
> > Classes are *not* just sugar, thinking about classes as just sugar that
> can
> > be replicated on ES5 is FUD and even if I've pointed out Babel
> > documentation has a wrong description of classes it's still there and 99%
> > of developers believe classes are like that, just sugar over prototypal
> > inheritance.
> >
> > This is so wrong that TypeScript fails with the most basic extend:
> >
> > ```js
> > class List extends Array { method() {} }
> >
> > (new List) instanceof List; // false
> > (new List).method(); // throws because it's not a List so no method
> > ```
> >
> > To simulate ES2015 classes you need `Reflect.construct`, unavailable in
> > ES5.
> > Polyfilling Reflect.construct with ES5 features is not enough: you need
> > Symbols too.
> >
> > Symbols are technically impossible to polyfill (i've gone very close, yet
> > not a perfect poly).
> > Symbols are needed to keep the instance so that in a transpiled world:
> >
> > ```js
> > (new List).slice() instanceof List; // true
> > ```
> >
> > Most developers that went for classes have broken code out of the box
> > thanks to transpilers and yet at the end of 2017 we keep writing that ES
> > classes are just sugar on top of ES5.
> >
> > We should stop starting from this ML to keep spreading this wrong
> > information.
> >
> > Thank you all for your understanding.
> >
> > Regards
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows 
> > wrote:
> >
> >> Honestly, this entire thread reads as partially misinformed,
> >> borderline trollbait. These kinds of questions and thoughts should
> >> really be asked directly (and a bit more respectfully) to TC39
> >> representatives and/or put in blog posts wherever. es-discuss is
> >> primarily about language design, and although the subject implies it's
> >> about the language's design in the abstract, I'm not convinced the
> >> content and responses really are.
> >>
> >> 1. Claims of a language "civil war" don't belong on this list, and are
> >> objectively false. Yes, there's disagreement, but even TC39 members
> >> aren't exactly in agreement here - consider the difference between
> >> Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
> >> Please take that into account.
> >> 2. Yes, there are multiple idiomatic uses of JavaScript, but it's
> >> large enough you can carve out a subset and be done with it. You don't
> >> like classes? Don't use them. You don't like arrow functions? Don't
> >> use them. You don't like `array.map`? Don't use it. Just because they
> >> exist doesn't obligate you to use them, and they don't hurt you in any
> >> way if you don't. Also, complaints of a person's or group's choice of
> >> idiom do *not* belong on this list whatsoever. Leave that crap to a
> >> private message, a blog post (if it's a group), or whatever.
> >> 3. JavaScript "classes" are not technically class-based OOP, and TC39
> >> members have acknowledged this in blog posts. It's 99% sugar over the
> >> existing prototype-based model, just with easier native subclassing.
> >> You could in theory replicate this in the rest of the language with a
>