Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Message-ID: <555F447D.3040507@asert.com.au>
Date: Sat, 23 May 2015 01:00:13 +1000
From: Paul King <paulk@asert.com.au>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dev@groovy.incubator.apache.org
Subject: Re: CharSequence.count(Closure)
References: 
 <CANBeYQQMiPe8DhdwcFVaf5W2M2oQ45xWz6CPxfRdiowKJ+x3zQ@mail.gmail.com>
 <CABfyjjfmcgZxduMzszhGf6A32TF5DPr7j5bkj1BAgTfVNSy1TQ@mail.gmail.com>
In-Reply-To: 
 <CABfyjjfmcgZxduMzszhGf6A32TF5DPr7j5bkj1BAgTfVNSy1TQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


There is certainly nothing stopping useful library classes from being
worked on outside Groovy core. There are big (GPars, Spock) and small
(e.g. http://grengine.ch/) examples of this.

We should certainly make this as easy as possible to do. There are
certainly some things on our TODO list which would make this easier
such as some additional metadata around minimum Groovy/Java versions
that an extension module supports for instance.  But within the
community it would be great to lower all the other barriers to
making such libraries easily deployable and findable.

Having said, we still want Groovy bundled with some base useful
libraries  and we want those to be consistent.  So, in this instance
I would probably just recommend adding a few extra methods.

Cheers, Paul.

On 23/05/2015 12:19 AM, David Dawson wrote:
> Apols for hijacking this a little, but it's related! (honest)
>
> I've been thinking recently about the setup of Groovy and particularly the extension methods. For questions like this, it would seem sensible to build an extension method to do it, but currently the expected place is to put it into Groovy itself. Therefore needing a release of Groovy to incorporate it.
>
> Now that the extension method API is well understood and seemingly stable, would it be feasible to separate the lifecycle of the extension methods/ GDK out from the Groovy runtime itself?
>
> That way Peters proposed extension could be implemented there without needing an upgrade of Groovy itself, and could then be usable on older versions of the language.
>
> Sound sane at all?
>
>
>
> On 22 May 2015 at 15:13, Peter Ledbrook <peter@cacoethes.co.uk <mailto:peter@cacoethes.co.uk>> wrote:
>
>     Hi,
>
>     One of the things I really like about Groovy is how strings can be treated as sequences of characters. Unfortunately this seems to break down in some cases. For example, there is no `count()` method that takes a closure. In my case I'm trying to count vowels, but you might want to count upper case letters or anything else like that.
>
>     Does it make sense to extend all the Iterable methods and properties to CharSequence as well? Or should developers turn a string into a list, perform the processing and then convert it back? Either way, the current setup seems a bit inconsistent.
>
>     Peter
>
>
>
>
> --
> David Dawson
> CEO
> Simplicity Itself Limited
> Tel +44 7866 011 256
> Skype: davidadawson
> david.dawson@simplicityitself.com <mailto:david.dawson@simplicityitself.com>
> http://www.simplicityitself.com


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com