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 <[email protected]> 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 <[email protected]>:
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
[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


_______________________________________________
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

Reply via email to