I was going to chip in that every class inherits what compiler it uses and so you can easily override that to do something special (like wrapping classes).
However, is this possibly an area where the meta-links kicks in so you don’t have to do this and get a more generic solution? (I haven’t played with this, but there are a few threads where people are using it, and it’s progressed quite a lot in Pharo 7). Tim Sent from my iPhone > On 28 Dec 2018, at 16:37, Ben Coman <b...@openinworld.com> wrote: > > > >> On Fri, 28 Dec 2018 at 16:30, Konrad Hinsen <konrad.hin...@fastmail.net> >> wrote: >> Richard Sargent <richard.sarg...@gemtalksystems.com> writes: >> >> > I understand your desire to utilize the existing Smalltalk mechanisms. But, >> > I think the most important thing is modelling consistency. >> > >> > What are the behaviours you expect from Expression, SumExpression, and >> > ProductExpression? Do they know their parent expression? Their children? >> > Other things? >> >> I certainly agree that this should be the main consideration, but in my >> case that's done. Each Expression subclass stored its own specific >> information, which for leaf nodes such as integer expressions is really >> just a value. All I need is integers with added behavior. >> >> > I think that, in general, you will benefit from fully and consistently >> > modelling the parse tree. >> >> I should have mentioned that my Expressions are not parse trees. They >> are used as values in symbolic computation. They are constructed and >> deconstructed all the time, which is one reason I want to eliminate >> overhead, the other reason being clarity of code. > > This may not be what you are looking for, but maybe help flesh out ideas. > Try debugging... > OpalCompiler new evaluate: '1 + 2' > > cheers -ben
