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...
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
