|
We have a desire to make a faster and cleaner implementation of Scope. The current (3.x scope) implementation acts very much as a router for all kinds of functionality and it acts as self in 3.x function implementations and ERB templates.
In order to enable migration, the 3.x function implementation and ERB wrapper implementation must change so that self is class (Scope3xCompatibility) that responds to the same public methods as Scope and delegates those to a 3.x Scope that it has a reference to. There should probably be subclasses specific to 3.x functions and ERB.
All methods that are considered private should issue a deprecation warning. Methods considered public should not, unless there are methods we absolutely have to block. The reason for not deprecating everything is that the 3.x functions eventually will be deprecated and removed along with the ERB support.
Deprecation messaging should suggest moving to the 4.x APIs instead of just patching the 3.x implementation.
We would really like to single out implementations that are based on access to the calling scope or those that modify the contents of either calling or closure scope. Unfortunately, any variable lookup is subject to be different depending on which scope is being used - all current usage expect calling scope. One way to enforce this is to require that implementations make a distinction and call either closure_scope or calling_scope - after that it is possible to single out those that use calling_scope. Such a change will however most likely be just as unpopular as forcing users to change to the 4.x APIs and EPP. For these reasons, we should keep the deprecations and required changes to a minimum while making it possible to supply a better scope implementation.
|
