Welcome. (And I know Electron has all the browser APIs. That was
implied with the "combining Node and Chrome" part.)
-----
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 19, 2018 at 9:37 PM, kai zhu <kaizhu...@gmail.com> wrote:
> appreciate the detailed counter-response and insight. fyi, electron is a
> browser.
>
> -kai
>
> On 18 Apr 2018, at 6:46 AM, Isiah Meadows <isiahmead...@gmail.com> wrote:
>
> To expand in the first, there is some functionality they have had to expose
> in the public API because people kept reading properties on those two
> internal stream properties.
>
> Similarly, jQuery has had in the past people relying so much on bugs that
> they had to turn some of them into features and document them in the source
> code. It was specifically because so many of these cases were propping up in
> the source code that they had to fork a new version (2.0) to fix all these
> bugs without breaking everyone. They also created jQuery Migrate just to
> help consumers migrate between patches, to notify people of certain bug
> fixes and minor changes that would otherwise break quite a few people's
> existing code bases.
>
> Or, in summary, as a library author, if you expose it, even if you don't
> document it, or even if you specifically warn people to not rely on it,
> people *will* inevitably find ways to depend on it, making some forms of bug
> fixes or other improvements practically impossible. In fact, this similar
> concern is why Python introduced its name mangling convention for
> `self.__foo` private variables - people clashing and/or otherwise relying of
> private data. For what it's worth, soft private (accessible via reflection,
> like Java, Ruby, etc.) is sufficient if you don't support subclassing, but
> it's when you do, that's where you need hard privacy (like C++, etc.).
>
> And don't forget: not all projects are particularly small, not all JS is
> simple glue code, and non-browser use cases aren't even obscure. (Slack for
> desktop is based on Electron, a platform combining Node and Chrome, and both
> PayPal's and Ebay's entire production backends use Node. Oh, and even NASA
> has picked it up for a few things on Earth, primarily for data processing at
> scale.) So if you're going to continue to blast and ignore it, please do
> your research first and realize they have unique needs themselves.
>
> On Tue, Apr 17, 2018, 18:12 Isiah Meadows <isiahmead...@gmail.com> wrote:
>>
>> If you don't need them, don't use them. The use for them is three-fold:
>>
>> 1. Not trusting people to avoid relying on API implementation details
>> (think: Node.js `_readableStream`/`_writableStream` used so frequently out
>> of core they've ran into issues updating it even in patch releases).
>> 2. In the face of inheritance, avoiding name collision. (This is a big one
>> at scale, not so much in a 30k web app.)
>> 3. Giving engines the ability to better structure object allocation and
>> property access. This is *very* useful for perf critical scenarios.
>>
>> Finally, if you don't need them, don't use them. But keep in mind, there
>> is a use case and a need.
>>
>> On Tue, Apr 17, 2018, 02:17 kai zhu <kaizhu...@gmail.com> wrote:
>>>
>>> as a javascript web-developer, can someone educate me on how private
>>> class methods/fields would make one's life easier (rather than harder)
>>> in getting web-projects shipped?
>>>
>>> ```
>>> /*
>>> * how is this cited example better than using a plain object in a
>>> web-project?
>>> * can someone give actual common problems in
>>> * debugging/integrating/shipping web-projects,
>>> * that private methods/fields could help simplify (rather than
>>> complicate)?
>>> */
>>> class HashTable {
>>> constructor() {
>>> private[Symbol.for('length')] = 0
>>> }
>>> set(key, value) {
>>> private[key] = value
>>> }
>>> get(key) {
>>> return private[key]
>>> }
>>> }
>>> ```
>>>
>>>
>>> On 4/17/18, Sultan <thysul...@gmail.com> 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.
>>> >
>>> > 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
