On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote:
Dear list,
I was showing off Pharo to a colleague today and was surprised that.
My quick introduction of adding new methods on existing system classes
String>>firstLetter
^self copyFrom: 1 to: 1
- extension on String worked immediately. But that:
in the MethodFinder evaluating: 'tried'.'t'
did not return my method I just added .... :-(
Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods.
What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )?
The rational is that the MethodFinder would, if it would not have a positive list, quite likely call methods that do bad things
to the state of the system. Remember that is just calls all methods to check if some leads to the return value that you gave!
e.g.
Smalltalk.true.
takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list.
It would of course be nice to be able to not need a positive list.
The question of how to control side-effects (and how to realize a secure yet reflective language in general) is�
of course a very interesting one...�