Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-4815

Enable migration to new scope implementation in 3.x functions and ERB

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Ready for Engineering
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: PUP 5.y
    • Component/s: None
    • Labels:
      None
    • Template:
    • Epic Link:
    • Team:
      Puppet Developer Experience
    • Story Points:
      5

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            henrik.lindberg Henrik Lindberg
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:

                Zendesk Support