On Nov 14, 2016, at 1:49 PM, Joel Dueck <[email protected]> wrote: > > When you talk about functions transparently overriding other functions in > some kind of inheritance hierarchy, are you talking about ... classes? > > http://docs.racket-lang.org/guide/classes.html > > I'm familiar with inheritance and overloading from OOP days, but didn't have > anything like that in mind! > > Assuming you weren't joking, I think I'd say yes to "functions transparently > overriding other functions" but strike out "in some kind of inheritance > hierarchy". I haven't dug into Pollen's internals so I wouldn't presume to > know the best route to take, though.
Not joking, but also not claiming to have a full-fledged idea ;) Personally, I avoid classes because I find them exhausting. But maybe they would be a helpful way of getting the "fallback" behavior you describe. FWIW when I was putting in the poly functionality some months ago, I thought a lot about how to organize the different sets of functions (because I figured that would be the most annoying part). For instance, I considered putting the per-target tag functions into specially-named submodules, like the `setup` submodule, or separate files. In the end, I went with the `current-poly-target` parameter because it felt like it made the fewest demands on the organization of a project. If you want all the poly functions for a certain tag to be in one function, you can do that. If you want them in submodules, or separate files, you can do that instead (and bring them back together with a macro). This way, everyone's "lazy subconscious assumptions" can be accommodated. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
