This leads to several questions: - Is something like this feasible/already possible in Pharo? - Any pointers on how Opal does optimizations? Do we have similar optimizations (removing code that could not be reached) that could be used. - How do you usually deal with additional tracing code when you do not want to have too much runtime overhead.
Does Pharo have pool *constants* or only pool *variables* ? I don't think a variable can/should affect compilation.
They are the same as Globals: there is an association in the literal frame whose value is pushed to read or stored into for write.
I like Eliot's approach of a variable holding a NullLogger, but if you have expensive arguments to marshall and you need absolute performance, perhaps an alternative proposal would be to consider expanding the semantic that pragmas affect compilation, such that you can use angle bracket blocks throughout the method that look up a variable during compilation <compileThis: [Log this: 'error'] when: DebugFlag>
Another alternative may be to use MetaLinks to install & remove the debugging code, plus something like the pragma syntax so these can be written inline like this... myMethod x := y + 1. < metalink: #debugging installWhenActive: [Log this: y] > z := x + y. Then you can enable debugging with... MetaLink activate: #debugging.
I am a bit sceptical to have meta links show up as syntax⦠I see two possibilities one could experiment with: 1) just add a Global + put a link. someMethod ... LogHere ⦠Opal does not compile the pushLititeralVariable/pop, it only put the association in the literal frame. Then you could put a link on this global. LogHere link: myLink. after which all methods that have LogHere would be recompiled with the code if the link compiled in. The link could reify everything needed. 2) we could add the concept of a #delete link and just annotate all sends to the Logger with that. Marcus