>> 
> 
> I was thinking more of the annoyance it poses when recovering lost changes 
> after you've ran tests, but sure, the performance boost is nice to have as 
> well :)
> 
> Btw, I took a short look at the RPackage code,

cool

> looked to me like quite a few of the add / addNamed: methods could be 
> rewritten so one uses the other.
> Eases maintanance if the actual adding is only defined in one place :)

Yes it was like that but I changed because I do not remember why. I duplicated 
the code because I could not find
a nice way to layer it. The version because the internal representation was 
layered. 

> Some API inconsistencies I'd like to see fixed:
> 
> - for adding classes, if you pass in  metaclass, it will add the class.

Yes this is the invariant of a RPackage: the list of classes only contain class 
not metaclasses. 
I always keep class to avoid to have 'Point class' symbol or think like that. 
This is like that in RBEnvironment.
Now the methods can be from the class and the metaclass. 

> - for adding classes by name, if you pass in a metaclass name, it will raise 
> an error.

Yes this is by design. :)
No metaclass name: I do not want to have to do string submatching ' class' kind 
of stuff

> - IIRC, atm it's sort of mix and match of what sort of argument is allowed 
> for the different things you can add by name.

Can you tell me which ones?

> - define a consistent expected argument type for the name: methods. Either 
> require them to implement the asSymbol method, or require them to be symbols. 
> 
> One last question - As far as I can see, there's no automatic removal of 
> definitions from other packages if they exist when you add something to a 
> package. 
> Is this supposed to be the resonsibility of the tools using them?

Yes because like that we can have methods belonging to multiple packages

> Either way, please, please, please, also implement Announcements for the 
> different kind of changes.

If you want to help on that please do.



_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to