make Ticker.ts protected

[reececomo]

Ticker is awesome, although we currently rely on (this as any)._myProperty overrides to subclass it. It would be helpful to retain types. Feel free to close PR if maintainers have an unexpectedly extreme opinion on high level encapsulation. Didn't see any prior art though. 😄

🧵 Inb4 - Arguments for/against

Arguments against

• Strong encapsulation, open-closed principle, etc. (I totally get it, but also 🤌 c'mon, I'm walking 'ere)
• Ticker is designed not to be modified on purpose (again, 🤌 c'mon, I'm walking 'ere)
• Consumers might modify it wrong (they already can)

Arguments for

• Ticker is a relatively high-level concern.
• Its fun to have extreme opinions on these things, but its also good to balance theoretical concerns with the practical/reality.
• It's not enjoyable™ as an end-user to be forced to rely on TS workarounds, or implement a custom ticker-equivalent, and provide custom emitters and custom animated sprites with modified functionality to make them compatible with those.

Description of change

• Leverage protected

Pre-Merge Checklist

• Tests and/or benchmarks are included n/a
• Documentation is changed or added n/a
• Lint process passed (npm run lint) n/a
• Tests passed (npm run test) n/a

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 0ebc9e9:

Sandbox	Source
pixi.js-sandbox	Configuration

[ivanpopelyshev]

Green light to hax!

[bigtimebuddy]

Would you mind elaborating more on what you're modifying to Ticker? Perhaps there is a feature we are missing? It's a rare request someone would want to extend Ticker so I'm curious.

My preference is to make protected only the bits you need to accomplish your inheritance/override. By making everything non-private, it changes the contract with devs that significant changes to these things would be breaking. Pixi already has a large API surface so we are mindful of not needlessly making it larger.

[reececomo]

It's a rare request someone would want to extend Ticker so I'm curious.

Absolutely. Use case is more advanced "speed" management, applied to a subset of stage items. Used for masking certain CSTS/rollback behaviors for networked multiplayer, and additionally for slow motion replays of a subset of stage objects. We don't use the autoStart/raf features.

Would not expect Ticker to support this case out-of-the-box. Just a couple very small tweaks to the built-in Ticker to integrate nicely with our other third party libs/tools.

By making everything non-private, it changes the contract with devs that significant changes to these things would be breaking. Pixi already has a large API surface so we are mindful of not needlessly making it larger.

I feel protected represents a similar contract in this instance. One would have to be making drastic changes just to use a subclassed ticker, so a breaking change would need to be pretty deliberate.

Although I agree in the broader sense, and all private static props/singleton were left as-is for the reasons you mentioned.

[bigtimebuddy]

Prior to introducing TypeScript and having formal access modifiers, Pixi did have an informal access ES5 convention that anything prefixed with "_" is not considered a stable API. If there's still a consensus around that, then I have no problem with this PR.

I'll defer to @Zyie on this one.