On 12 Dec 2013, at 08:22, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Dec 2013, at 08:14, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Dec 2013, at 06:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Stephan,
Thanks for pushing the #packages problem.
But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green.
Oh, so the API classes were fixed. I should have checked before (I just did). Great.
But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package.
What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method?
Another idea: if there is #package in Grease, there should be a class GreasePackage (or Package?). Maybe the API of the class is actually good (grease apis tend to be good). So maybe that API makes sense to be provided by RPackage? The real question is: what is the implementation of #package in Grease, what does it return and what does that object do? Marcus