On 12 Dec 2013, at 08:22, Marcus Denker <[email protected]> wrote:
> > On 12 Dec 2013, at 08:14, Tudor Girba <[email protected]> wrote: > >> Hi, >> >> >> On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <[email protected]> >> wrote: >> >> On 12 Dec 2013, at 06:31, Tudor Girba <[email protected]> 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
