On 2/16/07, Roel Wuyts Roel.Wuyts@ulb.ac.be wrote:
You can put it there, yes.
But there is an important design question lurking there. If you put the unification method on these classes, what you are really saying is: this Smalltalk object can be unified with that Smalltalk object. So you are then extending the Smalltalk language with unification.
That's exactly right
The alternative is to only have unification methods un your own 'unifiable objects' hierarchy. In that hierarchy you will probably have a class called: CWNumber, which represents numbers in your language and which will hold a Smalltalk number.
Which alternative to choose depends on whether, and how deep, you want to integrate Smalltalk and your own language. Unless you really want to mingle Smalltalk objects within your language, or want unification directly accessible at the Smalltalk level without having to pass through your language, I would advise the second option.
I understand. If I did choose the second option (make my own classes - CWNumber, CWString, CSList etc), would I then have to use a tool like SmaCC to construct instances. The advantage of extending the existing classes ("extending the language") seems to me that no parsing / compiling is required to make
5 unifiesWith: 5 in: emptyEnv
work.
I would be very interested in your work on this subject.
Thanks again for the help.