Ok so there are a number of separate concerns. I was looking at
grease core but the thread suggests the methods should be in the
platform part so that is a non issue. If they are in the platform part
then in this case they are intended to be adopted anyway. Fine
Regarding "improving the core" I assume you mean the core image. The
core image from a build point of view is just a bunch of well known
versioned packages. If another group is already maintaining a mc
package of code that is really nice to put into the core then the only
Point I was trying to make was to include it directly as a versioned
unit rather than copy and branch it. Of course if the code is not
packaged then it can go into the pharo repo naturally. The argument
wasn't at all about not including code. And the cost was not about
adding methods. It was about the mechanics of the build and
maintenance. In this case grease is special because of its philosophy
but what I'm trying to say would apply to any package that is well
maintained externally.
Cheers
Mike
On 21 Jun 2010, at 20:24, Stéphane Ducasse <[email protected]>
wrote:
The idea of marcus is that this is important to improve the core
even at the expense of adding
some methods. This is why we added the regex and in fact we could
rewrite a lot of part.
Now this is not that simple.
Stef
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?
mike
Stef
On Jun 17, 2010, at 6:42 PM, Michael Roberts wrote:
I'm missing something. Why do we need to adopt the (copy of)
methods and not just adopt the package as lukas said? I thought
we wanted core to get smaller over time and better modularised
anyway? We would just need to track a stable version rather than
maintaining our own branch. Surely it is worse to copy the
methods renamed or not but put them in a pharo specific package?
Cheers mike
On 17 Jun 2010, at 14:14, Julian Fitzell <[email protected]>
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
_______________________________________________
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
