00:14:26  * AtumT_quit (Quit: AtumT_)
00:45:51  * jwaldenquit (Ping timeout: 240 seconds)
00:47:55  * jwaldenjoined
01:25:22  * grit2joined
01:31:54  * grit2quit (Ping timeout: 256 seconds)
01:53:05  * aki_joined
01:54:00  * akirosequit (Ping timeout: 256 seconds)
01:54:01  * aki_changed nick to akirose
02:12:50  * ddstreet7joined
02:13:06  * ddstreet7quit (Killed (Unit193 (Spam is not permitted on freenode.)))
02:23:25  * zaberdampferjoined
02:23:55  * zaberdampferquit (Killed (Sigyn (Spam is off topic on freenode.)))
02:32:32  * dodobrain0joined
02:32:49  * dodobrain0quit (Killed (Unit193 (Spam is not permitted on freenode.)))
02:33:09  <TimothyGu>Anyone knows what the DeclarationPart static semantic is for? It just seems to return what it's called on
02:33:10  <TimothyGu>https://tc39.github.io/ecma262/#sec-static-semantics-declarationpart
02:35:53  <jmdyck>not exactly.
02:36:18  <jmdyck>it returns a specific child of what it's called on.
02:36:48  <jmdyck>happens to be the only child.
02:39:45  <jmdyck>so "DeclarationPart of |Foo|" is equivalent to "the only child of |Foo|", but the latter hasn't been established as phrasing that the spec can use.
02:40:57  * bluszcz4joined
02:40:57  * bluszcz4quit (Killed (Sigyn (Spam is off topic on freenode.)))
02:41:31  <jmdyck>plus it's possible that when DeclarationPart was introduced, there was a case in which it *wasn't* the only child.
02:44:17  <jmdyck>... doesn't look like it though.
02:46:45  <TimothyGu>jmdyck: I'm not sure I understand.
02:47:15  <jmdyck>which part?
02:48:28  <TimothyGu>so it's only used in context of "Return a new List containing DeclarationPart of Declaration."
02:48:51  <TimothyGu>or with formatting, "Return a new List containing DeclarationPart of |Declaration|."
02:49:00  <TimothyGu>why can't it just say "Return a new List containing |Declaration|."
02:49:52  <TimothyGu>In fact if you look at https://tc39.github.io/ecma262/#sec-exports-static-semantics-lexicallyscopeddeclarations, DeclarationPart isn't even applied consistently
02:50:52  <jmdyck>Ah, well that's a more interesting question
02:52:43  <devsnek>when in doubt, check what engines do
02:52:50  <devsnek>then open a pr that will take a few years to merge
02:53:52  <jmdyck>ultimately, it's presumably because the consumer(s) of that List expect its elements to be the child nodes, and not |Declaration|s.
02:56:26  <TimothyGu>… yet when one says "evaluate |Statement|" the spec *really* means "evaluate 'what the |Statement| actually is'"…
02:57:01  <jmdyck>no, it actually means evaluate the |Statement| node.
02:57:30  <jmdyck>but how you do that will depend on the nature of the node.
02:58:20  <jmdyck>unless you're talking about the chain production thing.
02:58:26  <TimothyGu>chain production
02:58:55  <TimothyGu>I think
02:59:47  <TimothyGu>Ah yeah that's what I'm talking about
02:59:51  <jmdyck>that's some editorial sleight-of-hand to avoid having to define a lot of really boring rules.
03:00:42  <TimothyGu>imo DeclarationPart is one boring rule. lol.
03:01:14  <TimothyGu>actually let's just say I remove "DeclarationPart of"
03:01:24  <TimothyGu>would the spec still work?
03:02:15  <jmdyck>I don't think so.
03:02:36  <jmdyck>Well, it might be debateable.
03:02:48  <TimothyGu>lol
03:02:56  <jmdyck>E.g., see FunctionDeclarationInstantiation
03:03:13  <jmdyck>which invokes VarScopedDeclarations, which returns one of these Lists.
03:03:48  <jmdyck>it gets put in _varDeclarations_ which we then iterate over, binding each element to _d_
03:04:02  <jmdyck>Then we say "If _d_ is neither a |VariableDeclaration| nor a |ForBinding| nor a ..."
03:04:12  <TimothyGu>hmm, so it treats ForBinding and BindingIdentifier separately
03:04:33  <TimothyGu>even though ForBinding may totally be a BindingIdentifier
03:05:17  <jmdyck>so the question would be: if _d_ is (bound to) a |Declaration| whose only child is a |VariableDeclaration|, then does _d_ is a |VariableDeclaration| yield *true*?
03:06:26  <jmdyck>I think the spec generally says no, though it may not be consistent on that point.
03:07:15  <TimothyGu>I guess that's precisely what I was confused on
03:07:47  <TimothyGu>because of the chain production thing, I was under the impression that the system is like object-oriented with inheritance
03:09:01  <jmdyck>well, except a parse tree isn't an class-inheritance hierarchy
03:10:06  <TimothyGu>yeah, exactly. I thought |Declaration| :: |VariableDeclaration| was an inheritance relationship rather than a parent-child hierarchy
03:10:44  <TimothyGu>didn't realize that it's more like { type: 'Declaration', child: { type: 'Variable' } }
03:10:59  <TimothyGu>*LexicalDeclaration
03:11:14  <TimothyGu>ugh ESTree
03:11:58  <jmdyck>yeah, it's probably better to think of it that way.
03:12:21  <jmdyck>"better" = "closer to how the spec 'wants' you to think about it"
03:27:31  * th3bmwjoined
03:28:14  * th3bmwquit (Remote host closed the connection)
03:31:26  * dave492528joined
03:31:39  * dave492528quit (Remote host closed the connection)
03:59:20  * aki_joined
03:59:44  * akirosequit (Ping timeout: 244 seconds)
03:59:44  * aki_changed nick to akirose
04:23:00  * atk20joined
04:23:32  * atk20quit (Killed (Sigyn (Spam is off topic on freenode.)))
04:23:54  * swoolley27joined
04:24:33  * swoolley27quit (Killed (Sigyn (Spam is off topic on freenode.)))
04:38:38  * Guest68301joined
04:39:39  * Guest68301quit (Remote host closed the connection)
04:51:06  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
05:08:19  * jmdyckquit (Quit: Leaving.)
05:39:41  * Soni23joined
05:39:45  * Soni23quit (K-Lined)
06:05:58  * aki_joined
06:06:57  * akirosequit (Ping timeout: 248 seconds)
06:06:57  * aki_changed nick to akirose
06:25:01  * ffernand2joined
06:30:03  * ffernand2quit (Ping timeout: 260 seconds)
06:31:51  * RoBz5joined
06:32:00  * RoBz5quit (K-Lined)
06:32:14  * armin1joined
06:33:59  * armin1quit (Remote host closed the connection)
06:48:55  * percY-21joined
06:54:20  * percY-21quit (Ping timeout: 268 seconds)
07:24:57  * mathiasbynens_part
07:25:37  * mathiasbynensjoined
07:44:40  * akoserwajoined
07:55:25  * moonythedwarfjoined
07:55:36  * moonythedwarfchanged nick to Guest14210
07:56:34  * Guest14210quit (Killed (Unit193 (Spam is not permitted on freenode.)))
07:59:46  * HackMasterjoined
08:00:45  * HackMasterquit (Killed (Sigyn (Spam is off topic on freenode.)))
08:11:42  * aki_joined
08:12:58  * akirosequit (Ping timeout: 256 seconds)
08:12:58  * aki_changed nick to akirose
09:29:26  * apriljoined
09:30:32  * aprilquit (Killed (Sigyn (Spam is off topic on freenode.)))
10:18:24  * aki_joined
10:18:51  * akirosequit (Ping timeout: 240 seconds)
10:18:51  * aki_changed nick to akirose
10:59:38  * howdoijoined
11:29:51  * AtumTjoined
11:42:06  * tx14joined
11:42:59  * tx14quit (Remote host closed the connection)
12:00:09  * jmdyckjoined
12:24:30  * Remco6joined
12:25:07  * aki_joined
12:25:21  * akirosequit (Ping timeout: 240 seconds)
12:25:21  * aki_changed nick to akirose
12:25:53  * Remco6quit (Remote host closed the connection)
12:47:17  * AtumTquit (Read error: Connection reset by peer)
12:51:48  * AtumTjoined
13:07:44  * spionjoined
14:31:19  * aki_joined
14:32:31  * akirosequit (Ping timeout: 268 seconds)
14:32:32  * aki_changed nick to akirose
15:00:26  * connojoined
15:00:40  * connoquit (K-Lined)
15:14:10  * akoserwaquit (Quit: Leaving)
15:57:10  * bladernr4joined
15:57:50  * bladernr4quit (Killed (Sigyn (Spam is off topic on freenode.)))
16:27:25  * howdoiquit (Quit: Connection closed for inactivity)
16:38:21  * aki_joined
16:39:21  * akirosequit (Ping timeout: 240 seconds)
16:39:21  * aki_changed nick to akirose
17:29:26  * johnpark_pjjoined
17:29:52  * johnpark_pjquit (Killed (Sigyn (Spam is off topic on freenode.)))
18:38:37  * Sherafjoined
18:38:41  * okdasjoined
18:38:50  * okdasquit (Killed (Sigyn (Spam is off topic on freenode.)))
18:38:54  * Sherafquit (K-Lined)
18:46:18  * aki_joined
18:46:21  * akirosequit (Ping timeout: 240 seconds)
18:46:29  * aki_changed nick to akirose
19:13:32  * arkainjoined
19:14:15  <arkain>can I get someone to look at this: https://repl.it/@arkain/Non-constructible-function
19:14:28  <arkain>I want to know if this is as intended or a bug.
19:16:27  <arkain>I can't find any documentation about it, but it seems that when functions are declared on objects using the simplified notation, that function cannot be constructed.
19:35:14  <bradleymeck>yup
19:35:22  <bradleymeck>working as intended
19:36:43  <bradleymeck>also it has access to super.foo() which function declaration/expressions do not: https://repl.it/repls/DarkMundaneInterchangeability
19:54:09  * arkainquit (Ping timeout: 252 seconds)
20:12:25  * Reincarnate10joined
20:12:57  * Reincarnate10quit (Killed (Sigyn (Spam is off topic on freenode.)))
20:21:58  * jwaldenjoined
20:22:41  * arkainjoined
20:24:26  <arkain>@bradleymeck: thanks for that.
20:28:56  <TimothyGu>https://tc39.github.io/ecma262/#sec-runtime-semantics-classdefinitionevaluation step 10
20:29:05  <TimothyGu>why are their odd spaces in 10.a.i?
20:29:24  <TimothyGu>*why is there odd spacing in 10.a.i?
20:29:31  <TimothyGu>apparently can't type today
20:35:55  <arkain>realistically speaking, is it too late to provide an alternative to proposal-class-fields?
20:40:18  * arahael28joined
20:40:35  <ljharb>arkain: technically no, realistically yes, because nobody has provided an alternative that meets all the use cases and constraints, and is also better.
20:40:51  <ljharb>arkain: and since most of the desire for alternatives seems to be "the syntax is icky"
20:41:28  <ljharb>arkain: do you have something in mind?
20:42:09  <arkain>Is there any way to get a list of all the "use cases and constraints"? Better is subjective. I understand that we're left with better as defined by the TC39, but I would also expect that "better" has an at-least somewhat technical definition.
20:42:14  * arahael28quit (Read error: Connection reset by peer)
20:42:28  <arkain>yes. It's the proposal-object-members that I've been working on.
20:42:55  <arkain>I've already made it available in github and been posting to the #es-discuss mailing list
20:44:19  <arkain>https://github.com/rdking/proposal-object-members
20:48:50  <arkain>In the better category, I'm offering : doesn't awkwardly limit access notation, provides simple and singular meaning to `#` for use in accessing private data, provides well known and well understood notation for declaring privilege levels, **offers parallel support for private members on objects**, offers support for C-style static variables in functions
20:49:50  <arkain>I and others may consider these things "better", but the fact of the matter is that it depends on how the TC39 defines it. There's no way for us to know that unless you lay it out.
20:51:01  <ljharb>arkain: so, anything with `protected` i'd find unacceptable, for one.
20:51:25  <ljharb>arkain: and anything that uses `private` for declaration but not for access, a number of us have already found unacceptable (which i think is in the proposal FAQ)
20:51:35  <arkain>may I ask why? This is a critical feature that will cripple use of proposal-class-fields.
20:52:04  <ljharb>in some languages it's "access level" as public/protected/private. that's not what this is in JS, nor what it should be.
20:52:22  <ljharb>this is "accessible" or "not accessible" - just like variables are either accessible or not.
20:52:33  <ljharb>ie there's no third state, it's just "public" or "not public"
20:52:51  <ljharb>"protected" doesn't work in any scenario where classes are mutable later on, which is "basically all of JS"
20:53:07  <ljharb>(because in that scenario "protected" is "public with some work", which is identical to "public")
20:53:12  * aki_joined
20:54:08  * akirosequit (Ping timeout: 256 seconds)
20:54:09  * aki_changed nick to akirose
20:54:14  <ljharb>separately, having "private" and "protected" be required, but "public" be optional, is weird imo
20:54:28  <ljharb>(and it would be pretty untenable to require it)
20:54:46  <arkain>The way I would choose to implement it, it's precisely that, an access level. Further, your assertion that "protected" doesn't work when classes are mutable is also not true. If only the methods that were available at the time of declaration have access to private members, then that is also true for protected.
20:55:04  <ljharb>that's not how subclassing works in JS tho
20:55:24  <ljharb>if "protected" means subclasses can access it, i can (and must be able to) create a new subclass at any time
20:55:30  <ljharb>at which point i have access to it, at which point it's public.
20:56:09  <ljharb>(please note that i'm only speaking for myself here, not the whole committee; the proposal FAQ speaks for the proposal authors which mostly overlaps with my personal feelings)
20:56:55  <arkain>...It is not public in that it cannot be accessed from outside a subclass. Making it "protected" is like saying "join my club or you can't use my services".
20:57:25  <arkain>That's a pretty common model for business
20:57:34  <arkain>Also a common model for development.
20:57:36  <ljharb>it's public because the subclass can choose to expose it.
20:57:56  <ljharb>if i make something private, it means only i can expose it
20:57:59  <arkain>By the same logic, a base class can choose to expose private members.
20:58:02  <ljharb>if i make something protected, it means anyone can get at it
20:58:09  <ljharb>which is the same definition as for public.
20:58:21  <ljharb>which means it's not actually protected from *anything*, which means why does it exist?
20:59:22  <arkain>There's major flaw in your argument.
21:00:11  <arkain>If a subclass exposes something that was inherited as "protected" then that is as intended, just as if the base class had exposed the member itself. Since this only affects instances, there is no real leak.
21:01:59  <arkain>The point of doing such a thing is to limit who has access to what.
21:02:38  <ljharb>right but protected doesn’t limit anything
21:02:49  <ljharb>since i can do class extends at any time
21:02:51  <arkain>From your point of view, protected can be considered a form of "soft private", which is needed to ensure that APIs have as little exposure as possible while still sharing what needs to be shared.
21:03:07  <ljharb>Totally! I agree with that.
21:03:17  <ljharb>but soft private is already easy with symbols or with underscores
21:03:35  <arkain>and yet not clear as to the intention.
21:03:38  <ljharb>i don’t think it deserves special syntax
21:03:42  <bradleymeck>symbols are clear
21:03:42  <arkain>underscores provide nothing
21:03:50  <bradleymeck>what isnt clear about symbols?
21:03:57  <ljharb>symbols imo mean precisely that. Otherwise why use a symbol?
21:04:12  <arkain>Symbols are still on the public interface and require almost no work to access.
21:04:30  <arkain>The point is to keep such data off the public interface.
21:04:51  <ljharb>protected is the public interface too
21:04:53  <bradleymeck>but you could extend the class and get them off the interface anyway for your protected stuff it looks like?
21:04:59  <ljharb>Everything reachable is public, full stop
21:05:05  <ljharb>There is no smaller interface.
21:05:08  <arkain>ljharb: public only to sub classes.
21:05:19  <ljharb>Everyone can subclass. So public to everyone.
21:05:24  <bradleymeck>arkain: which we can dynamically make, so anyone can get em?
21:06:05  <arkain>That much will always be true, but it's not as if that's going to be something people aren't aware of when they use protected.
21:06:15  <ljharb>again, public is binary. Either it’s accessible or it’s not.
21:06:16  <arkain>That's part and parcel of the language
21:06:31  <bradleymeck>i don't understand those last few comments
21:06:37  <ljharb>the best way to prove they know that is not to make syntax that’s deceptive.
21:06:54  <ljharb>protected syntax would wrongly imply that it’s offering protection - which it’s not.
21:06:56  * catfuneraljoined
21:06:58  * catfuneralquit (K-Lined)
21:07:18  <bradleymeck>we could call it something else, that seems possible
21:07:26  <bradleymeck>but i'd still go back to asking why not use symbols
21:07:33  <arkain>protected syntax implies that someone cannot do x#.y on your instance unless they've joined your club.
21:07:50  <bradleymeck>but everyone can join your club if they extend your class
21:07:55  <arkain>basically "membership has it's privileges"
21:08:02  <bradleymeck>but membership is free
21:08:10  <arkain>That's not an isue
21:08:12  <arkain>issue
21:08:21  <ljharb>sure. But then the argument for consistency with classical inheritance access levels withers.
21:09:00  <bradleymeck>arkain: that is an issue. your stating that someone cannot do X unless Y happens, but also stating that everyone is able to do Y
21:09:13  <bradleymeck>it is some form of indirection but doesn't seem to be gainful
21:09:26  <arkain>Not really trying to offer that. ES is dynamic, so that kind of consistency is impossible. Just the fact that you can do x.y where y didn't previously exist on x breaks that consistency.
21:10:37  <arkain>I want to continue this discussion, but I've got to leave now. Can this be continued on es-discuss?
21:11:04  * arkainpart
21:11:17  <bradleymeck>i'll be off on business for a while, but i'm not really looking to discuss this at length as i don't understand what is to be gained currently
21:17:31  * tigermousr16joined
21:17:39  * tigermousr16quit (K-Lined)
22:08:25  * walle303joined
22:13:21  * walle303quit (Ping timeout: 240 seconds)
22:36:25  * james41382joined
22:38:12  * james41382quit (Killed (Unit193 (Spam is not permitted on freenode.)))
22:43:34  * arkainjoined
22:50:09  * arkainquit (Ping timeout: 252 seconds)
22:59:44  * aki_joined
23:01:04  * akirosequit (Ping timeout: 256 seconds)
23:01:05  * aki_changed nick to akirose
23:01:06  * arkainjoined
23:16:33  * arkainquit (Ping timeout: 252 seconds)
23:20:55  * arkainjoined
23:24:17  <arkain>@ljharb: I've made it back from errands and had a little time to think about the issue of protected from both ends. If I understand it, your argument is that since a subclass can be dynamically created that is capable of leaking the state of a protected member, then that member is no different than a public member. Is this right?
23:24:38  <ljharb>arkain: yep
23:24:52  <arkain>... more accurately, leaking the state of a protected member on any instance of the type...
23:24:55  <ljharb>yes
23:25:15  <ljharb>and i can .call things on an object that has Symbol.hasInstance set to return true, for example
23:25:21  <ljharb>so i don't even have to actually subclass.
23:25:49  <ljharb>you could use a combination of private state and protected to stop that; but that still wouldn't stop a simple `class extends` to extract the "protected" stuff.
23:26:58  <arkain>The more I think about it, the more I'm inclined to agree... Protected for data may indeed be useless.
23:27:14  <arkain>What about protected for functions? Is that equally useless?
23:27:53  <ljharb>what would that even mean
23:28:02  * vegii5joined
23:28:05  <ljharb>also, functions already have private - closed-over variables
23:28:53  * vegii5quit (Killed (Unit193 (Spam is not permitted on freenode.)))
23:42:42  * bernalex22joined
23:42:57  * arkainquit (Ping timeout: 252 seconds)
23:45:24  * arkainjoined
23:45:47  <arkain>I hate how the web chat bumps you if you're afk for a moment....
23:46:19  <arkain>It means that a class will be able to share some of its internal API with subclasses. I get that this is also subject to the subclass leak. However, it is superior to the current '_' convention in that it does not allow the protected members to appear at all on the public interface.
23:47:13  <arkain>This is something that cannot be accomplished with Symbols.
23:47:27  * bernalex22quit (Ping timeout: 240 seconds)
23:56:39  <arkain>@ljharb: so my question is this - Given an object containing private members, is there any approach that can successfully reduce the likelihood of a developer using an API that is not meant to be public but needs to be shared while still allowing inheriting objects to access the shared API? This is the desire of those who need "protected" support.
23:57:32  <arkain>Or, if that's not possible, is there any non-convoluted approach to achieve the same?