[Pharo-project] About SourcedMethodReference

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Nov 10 12:28:29 CET 2010

> Why do you want to remove MethodReference?

To be able to have MethodReferenceWithSource which will be renamed MethodReference and in the same time 
not put the system on its knees. ;)

Right now MethodReference and friend sucks even if I already fixed a lot of Feature Envy. 
I do not like the logic to read change files
	with case statement
	#Comment ....  all the bad logic it implies.
There is a lack of real objects there. 
When you read the code of RecentMessages or recovery you can faint and re fixed a lot of Feature Envy, Duplicated code in 1.2.
A lot is happening in 1.2 under the surface and a lot more will happen in 1.3.

We want a real declarative model of source code. Veronica will start to work on that. We want to store also **all** the code of all the version
 in a database so that we can do real versions queries.

Now the changes made on MethodReference are to make sure that we can have two methodReference with the same 
selector, class, but a different timestamp and source code. Like what we see in versions and recent changes, but done in a much better way. 
Benjaman rewrote completely recentMessages and this is great we can filter recentMessages based on time, class, packages.....
and without the changes in MethodReference we had to put isKindOf and other nasty checks all over the place.

So in summary, we want to put in place an infrastructure for building next generation tools.

Ideally we will have 

and migrate all the tools to them. We will experiment with that and certainly build a robust infrastructure for that.

I hope it explains. We wrote a document explaining that. But now we should build it.


More information about the Pharo-project mailing list