On Nov 14, 2016, at 5:30 PM, Matthew Butterick <m...@mbtype.com> wrote:
> Not joking, but also not claiming to have a full-fledged idea ;) Here's a rudimentary version of moving tag functions into classes: https://gist.github.com/mbutterick/b169900fedf84810b6335365b89562e4 In this example, all the tag functions would become class methods. The `tags%` class would define the default versions. The `pdf-tags%` and `text-tags%` inherit from this class, so they get all the default tag functions, but can define overrides as well. The `current-tag-object` parameter would switch which class is being used, somehow tied to `current-poly-target`, I'm glossing over some details ... Then the actual tag functions in "pollen.rkt" would merely be stubs that dispatch into the `current-tag-object`. But I believe this produces the behavior you describe: selective override of certain tag functions, otherwise resorting to defaults. -- You received this message because you are subscribed to the Google Groups "Pollen" group. To unsubscribe from this group and stop receiving emails from it, send an email to pollenpub+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
