Issue 2560 : Convenient methods from Grease for Strings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Issue 2560 : Convenient methods from Grease for Strings

Adrien BARREAU
Hello all,

The trim* messages defined in Grease are really useful.
I suggest to integrate them in the String class.

Take a look: http://code.google.com/p/pharo/issues/detail?id=2560

Adrien.



Vous voulez protéger votre vie privée ? La solution avec Internet Explorer 8
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

SergeStinckwich
Hi Adrien,

i think it's much better if you include some tests also.

Regards,

2010/6/17 Adrien BARREAU <[hidden email]>:

> Hello all,
>
> The trim* messages defined in Grease are really useful.
> I suggest to integrate them in the String class.
>
> Take a look: http://code.google.com/p/pharo/issues/detail?id=2560
>
> Adrien.
>
>
> ________________________________
> Vous voulez protéger votre vie privée ? La solution avec Internet Explorer 8
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Lukas Renggli
I've tried to post a message on the bug-tracker, but it seems to have
some troubles at the moment. So I post it here:

- 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.

- If included with Pharo I suggest to also include the tests from Grease-Tests.

- The #trim protocol is just a subset of various related string
manipulation methods. It is kind of a pity to take that apart. Why not
keep Grease-Core as an externally loadable package? It has no other
dependencies.

Lukas

On 17 June 2010 11:57, Serge Stinckwich <[hidden email]> wrote:

> Hi Adrien,
>
> i think it's much better if you include some tests also.
>
> Regards,
>
> 2010/6/17 Adrien BARREAU <[hidden email]>:
>> Hello all,
>>
>> The trim* messages defined in Grease are really useful.
>> I suggest to integrate them in the String class.
>>
>> Take a look: http://code.google.com/p/pharo/issues/detail?id=2560
>>
>> Adrien.
>>
>>
>> ________________________________
>> Vous voulez protéger votre vie privée ? La solution avec Internet Explorer 8
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Marcus Denker-4

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?

Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Lukas Renggli
> - 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?

I agree, from Pharo point of view. However, for any software built on
top of Pharo it means troubles if Pharo suddenly implements the same
methods.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Julian Fitzell-2
In reply to this post by Marcus Denker-4
2010/6/17 Marcus Denker <[hidden email]>:

>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Schwab,Wilhelm K
In reply to this post by Lukas Renggli
+1 on the idea that this should be a whole lot slicker than it is.  That said, Lukas' idea of keeping the relevant methods in an external package is certainly a way around the problem, and not even a bad way either.  In fact, Dolphin's package system is VERY picky, and the way one usually gets it to relax is to create what I call "yet another package" so that things can load in the correct order.

FWIW, I am still trying to figure out whether MC is superior (more flexible) to (than) Dolphin's package load mechanism, or if I simply haven't yet been burned by what it fails to prevent.

Bill




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Lukas Renggli [[hidden email]]
Sent: Thursday, June 17, 2010 7:25 AM
To: [hidden email]
Subject: Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for    Strings

> - 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?

I agree, from Pharo point of view. However, for any software built on
top of Pharo it means troubles if Pharo suddenly implements the same
methods.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Dale Henrichs
In reply to this post by Julian Fitzell-2
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 <[hidden email]>:
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Michael Roberts-2
In reply to this post by Julian Fitzell-2
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 <[hidden email]> wrote:

> 2010/6/17 Marcus Denker <[hidden email]>:
>>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Lukas Renggli

On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote:

> I've tried to post a message on the bug-tracker, but it seems to have
> some troubles at the moment. So I post it here:
>
> - 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.

why?
you cannot have a Pharo package for grease where these methods are not present?

> - If included with Pharo I suggest to also include the tests from Grease-Tests.
>
> - The #trim protocol is just a subset of various related string
> manipulation methods. It is kind of a pity to take that apart. Why not
> keep Grease-Core as an externally loadable package? It has no other
> dependencies.

why not

>
> Lukas
>
> On 17 June 2010 11:57, Serge Stinckwich <[hidden email]> wrote:
>> Hi Adrien,
>>
>> i think it's much better if you include some tests also.
>>
>> Regards,
>>
>> 2010/6/17 Adrien BARREAU <[hidden email]>:
>>> Hello all,
>>>
>>> The trim* messages defined in Grease are really useful.
>>> I suggest to integrate them in the String class.
>>>
>>> Take a look: http://code.google.com/p/pharo/issues/detail?id=2560
>>>
>>> Adrien.
>>>
>>>
>>> ________________________________
>>> Vous voulez protéger votre vie privée ? La solution avec Internet Explorer 8
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> Every DSL ends up being Smalltalk
>> http://doesnotunderstand.org/
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Lukas Renggli
Why
you just adapt your package to the version of pharo that includes the changes.
We do that all the time so I do not understand where is the problem?

>> - 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?
>
> I agree, from Pharo point of view. However, for any software built on
> top of Pharo it means troubles if Pharo suddenly implements the same
> methods.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Julian Fitzell-2

On Jun 17, 2010, at 3:14 PM, Julian Fitzell wrote:

> 2010/6/17 Marcus Denker <[hidden email]>:
>>
>> 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?

because you were planning to have only one grease for all the platform.
Ok this was not obvious.

> 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...

But did you try metacello?
Because I thought it was good for that kind of managament
Stef
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Michael Roberts-2
but do we want all grease?

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 <[hidden email]> wrote:
>
>> 2010/6/17 Marcus Denker <[hidden email]>:
>>>
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Michael Roberts-2


On 21 Jun 2010, at 14:30, Stéphane Ducasse <[hidden email]>  
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?
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 <[hidden email]> wrote:
>>
>>> 2010/6/17 Marcus Denker <[hidden email]>:
>>>>
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Julian Fitzell-2
In reply to this post by Stéphane Ducasse
On Fri, Jun 18, 2010 at 4:43 AM, Stéphane Ducasse
<[hidden email]> wrote:

>
> On Jun 17, 2010, at 3:14 PM, Julian Fitzell wrote:
>
>> 2010/6/17 Marcus Denker <[hidden email]>:
>>>
>>> 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?
>
> because you were planning to have only one grease for all the platform.
> Ok this was not obvious.

No, there are packages for each platform. What we don't yet have is
separate packages for different *versions* of a platform. But that may
be unavoidable over time...

Julian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Julian Fitzell-2
In reply to this post by Michael Roberts-2
On Mon, Jun 21, 2010 at 9:38 AM, Michael Roberts <[hidden email]> wrote:

>
>
> On 21 Jun 2010, at 14:30, Stéphane Ducasse <[hidden email]>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Julian Fitzell-2
In reply to this post by Dale Henrichs
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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Michael Roberts-2
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 <[hidden email]> wrote:
>>>
>>>> 2010/6/17 Marcus Denker <[hidden email]>:
>>>>>
>>>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Stéphane Ducasse
In reply to this post by Julian Fitzell-2
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 <[hidden email]> wrote:
>>
>>
>> On 21 Jun 2010, at 14:30, Stéphane Ducasse <[hidden email]>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 2560 : Convenient methods from Grease for Strings

Dale Henrichs
In reply to this post by Julian Fitzell-2
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 <[hidden email]> 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 <[hidden email]>:
>>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12