On Thu, Dec 27, 2018 at 8:43 AM Konrad Hinsen <konrad.hin...@fastmail.net>
wrote:
> Hi everyone,
>
> I am confronted with an implementation choice that I expect to be not so
> rare, and I wonder what "the Pharo way" is for dealing with it. I will
> use a toy example for illustration, my real case is more complex but not
> fundamentally different.
>
> Suppose I want to represent arithmetic expressions that support various
> operations (evaluation, simplification, compilation to whatever
> language, ...). In the textbook discussion, I'd have a class hierarchy
> such as
>
> Expression (abstract)
> IntegerExpression
> VariableNameExpression
> SumExpression
> ProductExpression
> ...
>
> What I really want is not some IntegerExpression, but plain Pharo
> integers, and for variable names I want to use plain Pharo symbols.
>
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? What was their actual representation (source code)?
16rDEADBEEF may be more meaningful than 3735928559, for example. Likewise,
2r111110111101110110101 versus 2063285. Being able to reason fully about
what was parsed will almost always be important.
I think that, in general, you will benefit from fully and consistently
modelling the parse tree. The actual evaluation is probably the smallest
part of the problem.
e.g. if every node implements #evaluate, it is easy to implement their
operations. SumExpression would answer "self leftNode evaluate + self
rightNode evaluate". IntegerExpression would implement is as "^self value"
or something similar.
> From my current understanding of Pharo, my options are
>
> 1. Use wrapper objects for integers and symbols, i.e. have a class
> IntegerExpression that stores an integer in an instance variable.
>
> 2. Add the methods of my abstract Expression class to all the classes
> representing integers and symbols.
>
> 3. Implement my own dispatch that does not rely on method lookup.
>
> None of these really looks attractive. 1) adds a lot of overhead, both
> in the code ("IntegerExpression withValue: 5" rather than just "5") and
> at runtime. 3) also adds a lot of overhead because I have to implement
> my own dispatch. 2) would probably be the least effort, but looks like a
> kludge.
>
> For comparison, in the Lisp world (CLOS, Racket, ...) that I know much
> better, I would use generic functions and provide implementations for
> integers and symbols as well as for my own Expression types.
>
> So... how would you approach this problem?
>
> Thanks in advance,
> Konrad.
>
>
