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