yes I understand On Jun 21, 2010, at 8:18 PM, Julian Fitzell wrote:
> On Mon, Jun 21, 2010 at 9:38 AM, Michael Roberts <[email protected]> wrote: >> >> >> On 21 Jun 2010, at 14:30, Stéphane Ducasse <[email protected]> >> wrote: >> >>> but do we want all grease? >>> >> >> Well. Not sure. Grease core is not that big. It has other useful stuff in. I >> was in part commenting on the philosophy markus was referring to. I have a >> different point of view. If we just copy the extensions we have to >> maintain our own branch. And we can not use any extensions that reference >> grease classes. Then what happens if we really want an extension like that? >> We copy classes too?that would not make a lot of sense to me. >> >> So what do you think? > > Philosophically, Grease does not desire to provide implementation but > tests of available functionality. The tests are common to all > platforms and it is up to the platforms to ensure the tests pass. The > ideal is that each platform simply provides the needed functionality > (that's why we try to keep the size of Grease relatively small) and > that in cases where they do not wish to do so they will provide a > platform-specific Grease package that provides the functionality. > > The question here is regarding methods that we have provided in our > Pharo-specific Grease package and whether some or all of them should > be moved under Pharo's responsibility instead. As with all the other > platforms, I encourage the adoption of Grease extensions that are > considered generally useful and sane. Having these methods managed as > part of the Pharo process means that the correct version will always > be available in each Pharo release and that the methods are more > widely available for use. > > It seems like the specific methods in question are currently in > Grease-Core instead of Grease-Pharo-Core and I agree this is probably > not ideal (I'll respond separately to Dale's email about this). > Assuming they were in Grease-Pharo-Core, though, it would be a matter > of *moving* them into Pharo, not *copying* them (with the added > wrinkle of dealing with different Pharo versions, some of which have > them and some of which do not). > > Julian > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
