June 21, 2010
8:16 p.m.
Julian, I am very close to adding version specific attributes for Pharo1.0 and Pharo1.1 to make this sort of specialization a little easier, but even now an individual project can add fine-grained attributes that could allow code to be conditional on a build by build basis ... if needed. Dale Julian Fitzell wrote: > Hmm... Why did I only receive this email today...? > > Anyway, I agree that those methods should probably be in the > platform-specific package. I guess we were originally trying to > minimize the amount of implementation required on each platform. As > long as no platform implements a method and the implementation is the > same on all platforms, it is convenient to have it in only one place. > As soon as a platform chooses to implement it, though, we will simply > have to move it to the platform-specific package. At this point we run > into the issue of having different platform packages for, say, Pharo > 1.1 and 1.2. > > Perhaps in the end it is simpler just to keep extensions always in the > platform packages and insist that the generic packages contain only > GR* classes and grease* extension methods. > > I'm not sure about Grease providing reference implementations of all > methods it tests, though. I'm not convinced that a "gold standard" > always exists, nor that it will necessarily be implemented by Grease. > In many cases, we have standardized on methods that already exist in > Squeak/Pharo or in some other platform. > > On Thu, Jun 17, 2010 at 9:30 AM, Dale Henrichs <dhenrich@vmware.com> wrote: >> Julian, >> >> The Grease-Core package contains a mixture of things (for convenience): the >> GR* family of classes using a naming convention that is unlikely to collide >> with platform classes and a collection of extensions to well-known classes >> using names that could very easily collide with platform methods (or prevent >> a platform from implementing that method in their base system). >> >> The well-known class extension methods could easily be moved to the >> platform-side, then as platforms adopt the Grease extensions (an obvious >> goal of Grease in the first place) the platform extensions can be adjusted >> accordingly...the Grease-Tests for those methods should remain so that from >> the Grease-Users perspective the behavior for those methods will remain >> consistent (relative to Grease) over time... >> >> It _would be convenient_ to preserve the current well-known class extension >> method implementations so that when Grease is ported to a new platform the >> "standard implementation" can be used as a bootstrap. In fact if the >> well-known class extension methods were moved into a separate platform >> package, then you'd have the gold standard implementation and the initial >> pharo/squeak implementation rolled into one. >> >> In the end this doesn't sound that awful... >> >> Dale >> >> Julian Fitzell wrote: >>> 2010/6/17 Marcus Denker <marcus.denker@inria.fr>: >>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>> >>>> - If included with Pharo I suggest to rename all the methods, >>>> otherwise we will run into big troubles with Seaside and other >>>> projects that depend on Grease. >>>> >>>> >>>> From a philosophical standpoint, I *hate* that. this means that as a >>>> plattform, we can not >>>> grow and improve our libraris anymore? >>>> Shouldn't be the goal that useful extensions gets adopted by the core? >>> We will need to find a way to allow platforms to adopt Grease methods >>> - I do think this is the end goal. It's a bit of a nightmare from our >>> point of view because we end up having to have different Grease >>> versions for different versions of the platforms, but isn't that sort >>> of unavoidable in the long run anyway? Part of the reason that's so >>> awful is simply due to the lack of good branching and management tools >>> in our version control systems... >>> >>> Julian >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project