Skip to content

Conversation

@gravitystorm
Copy link
Contributor

This avoids exposing the implementation internals (e.g. instance variables, additional non-dsl methods) from the Stylesheet class, that might conflict with code written by the user.

I took this approach from Ruby Ate My DSL (17 minutes).

The problem was that all the methods and instance variables in the Stylesheet class were exposed to the DSL context. That means that if a user accidentally uses an instance variable with the same name (e.g. @layers, @params etc) or uses or defines any methods that clash with anything internal in the Stylesheet class, then everything blows up. This is particularly a problem if we want to add any new instance variables, or new internal method definitions, in the future, that might conflict with what people have written in their stylesheets.

Instead, we can create a slimmed down StylesheetDSL class, that only contains the methods offered by the DSL. We then evaluate the user's code in the context of that class (@dsl.instance_eval(...)). This means that things are less likely to break. For example, the user can use any instance variables they like (except @__impl!) without breaking anything, and we can add more instance variables to the Stylesheet class without hesitation.

I intend to do something similar for the Layer class too.

This avoids exposing the implementation internals (e.g. instance
variables, additional methods) that might conflict with code written
by the user.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant