> Your proposal boils down to simply keeping this flag around forever, for this particular feature.
Kind of. The harmony flag is used to enable the feature. I was thinking about a flag to disable the feature after it leaves harmony. It could be just a matter of renaming the flag and changing the default though. > By the way, this would be good feedback for the proposal champions. Please post it on the proposal repo if you haven't already. Yes, we are engaging in the repo to discuss possible legitimate Node.js use cases which would be affected by this proposal :) We have an issue to discuss the ability to disable the directive (which would essentially be the flag I'm proposing here): https://github.com/tc39/proposal-function-implementation-hiding/issues/25 Thanks! On Thursday, September 26, 2019 at 2:11:13 AM UTC-7, Mathias Bynens wrote: > > Once they reach stage 3, new language features are initially implemented > behind a --harmony-* flag. Your proposal boils down to simply keeping this > flag around forever, for this particular feature. > > By the way, this would be good feedback for the proposal champions. Please > post it on the proposal repo > <https://github.com/tc39/proposal-function-implementation-hiding/issues> > if you haven't already. Thanks! > > On Wed, Sep 25, 2019 at 10:55 PM 'Matheus Marchini' via v8-dev < > [email protected] <javascript:>> wrote: > >> There's a proposal on stage 2 to add a "function hiding" directive: >> https://github.com/tc39/proposal-function-implementation-hiding. That >> would allow library authors to hide implementation details of internal >> functions and classes, and it has some benefits (described in the >> proposal). This proposal also has a side-effect of making observability >> tools less accurate, and it could hide bugs in libraries where the >> functions are hidden, making it harder to detect those bugs in production. >> Tools like Sentry <https://sentry.io/welcome/> would become less >> valuable in these scenarios. >> >> Stripping out the directive from libraries with a tool like babel could >> be possible, but many Node.js applications don't use those tools. >> >> If the proposal goes to Stage 3, would it be possible to have a flag (or >> maybe an API) on V8 to bypass that directive, so that Error.prototype.stack >> and Error.prototype.captureStackTrace would show the original stack trace >> instead of the redacted one? A flag would probably be more appropriate and >> performant. If the V8 team is open to have this flag but is not >> interested/doesn't have the bandwidth to implement it, I'd be happy to help. >> >> -- >> -- >> v8-dev mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/74bffe27-f0e8-467e-b361-46a103650f29%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/74bffe27-f0e8-467e-b361-46a103650f29%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/0e44c4df-78da-4255-b262-2240859b9e35%40googlegroups.com.
