GroovyShell, GroovyCodeSource & InputStream vs. Reader

[Jason Dillon]

I noticed there are a bunch of deprecated bits related to use of  
InputStreams:

@deprecated Prefer using methods taking a Reader rather than an  
InputStream to avoid wrong encoding issues.

But there are no equivalent Reader methods... any reason why?

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

On Wed, Oct 28, 2009 at 12:18, Jason Dillon <jason@...> wrote:
> I noticed there are a bunch of deprecated bits related to use of
> InputStreams:
>
> @deprecated Prefer using methods taking a Reader rather than an InputStream
> to avoid wrong encoding issues.
>
> But there are no equivalent Reader methods... any reason why?

When you have String variants, you don't really need a Reader.
Just provide your own StringReader over it, read it, put that in a
String, and you're done.
So it's not really necessary.
Ideally, I wish that there had not been any InputStream variants in
the first place, and Readers should have been used instead.
But well... I've deprecated those IS ones, as they are a bit dangerous
wrt encodings, so people should avoid using them.
That said, the deprecated message is indeed wrong, and should say use
the String variants.
Or Reader variants, since you've added them now.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 29, 2009, at 3:54 PM, Guillaume Laforge wrote:

> On Wed, Oct 28, 2009 at 12:18, Jason Dillon <jason@...>  
> wrote:
>> I noticed there are a bunch of deprecated bits related to use of
>> InputStreams:
>>
>> @deprecated Prefer using methods taking a Reader rather than an  
>> InputStream
>> to avoid wrong encoding issues.
>>
>> But there are no equivalent Reader methods... any reason why?
>
> When you have String variants, you don't really need a Reader.
> Just provide your own StringReader over it, read it, put that in a
> String, and you're done.

Seems to me like using a String is more of a connivence, though sure  
internally it wants a String, but the idea of having the readers there  
to abstract is to prevent folks from having to write more boilerplate  
code to convert their readers to strings first.

Also it seems a bit odd that internally it needs a String to start  
with.  What if the input is fricken huge?  Why can't the internals use  
a Reader instead?

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

On Thu, Oct 29, 2009 at 10:12, Jason Dillon <jason@...> wrote:
> [...]
> Seems to me like using a String is more of a connivence, though sure
> internally it wants a String, but the idea of having the readers there to
> abstract is to prevent folks from having to write more boilerplate code to
> convert their readers to strings first.

Well, things like GroovyShell, and friends are very often used with
just strings, as they are use for evaluating some small scripts
(business rules, math fomulas, whatever). So a reader over these
strings are perhaps overkill too.
Often if you externalize such scripts / rules, you put them in an XML
file, in a database, etc. and often you retrieve them out-of-the-box
as strings, not as readers.
But for things like GCL, which is used by the file system compiler and
so on, there you'd probably prefer a reader.

> Also it seems a bit odd that internally it needs a String to start with.
>  What if the input is fricken huge?  Why can't the internals use a Reader
> instead?

Code smell if your input is "fricken huge"! :-P

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

I tend to use GroovyShell as an abstraction over the GCL+other muck  
needed to execute a script, and I often use streams not strings or  
files.

--jason


On Oct 29, 2009, at 4:26 PM, Guillaume Laforge wrote:

> On Thu, Oct 29, 2009 at 10:12, Jason Dillon <jason@...>  
> wrote:
>> [...]
>> Seems to me like using a String is more of a connivence, though sure
>> internally it wants a String, but the idea of having the readers  
>> there to
>> abstract is to prevent folks from having to write more boilerplate  
>> code to
>> convert their readers to strings first.
>
> Well, things like GroovyShell, and friends are very often used with
> just strings, as they are use for evaluating some small scripts
> (business rules, math fomulas, whatever). So a reader over these
> strings are perhaps overkill too.
> Often if you externalize such scripts / rules, you put them in an XML
> file, in a database, etc. and often you retrieve them out-of-the-box
> as strings, not as readers.
> But for things like GCL, which is used by the file system compiler and
> so on, there you'd probably prefer a reader.
>
>> Also it seems a bit odd that internally it needs a String to start  
>> with.
>>  What if the input is fricken huge?  Why can't the internals use a  
>> Reader
>> instead?
>
> Code smell if your input is "fricken huge"! :-P
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

Actually, when I did some recent refactorings in that area (because of
encoding issues + security issues on Google App Engine), I initially
wanted to add Reader related methods (hence the wrong deprecate
message), but with all these evaluate(string) methods, I went on with
strings.

On Thu, Oct 29, 2009 at 10:40, Jason Dillon <jason@...> wrote:

> I tend to use GroovyShell as an abstraction over the GCL+other muck needed
> to execute a script, and I often use streams not strings or files.
>
> --jason
>
>
> On Oct 29, 2009, at 4:26 PM, Guillaume Laforge wrote:
>
>> On Thu, Oct 29, 2009 at 10:12, Jason Dillon <jason@...> wrote:
>>>
>>> [...]
>>> Seems to me like using a String is more of a connivence, though sure
>>> internally it wants a String, but the idea of having the readers there to
>>> abstract is to prevent folks from having to write more boilerplate code
>>> to
>>> convert their readers to strings first.
>>
>> Well, things like GroovyShell, and friends are very often used with
>> just strings, as they are use for evaluating some small scripts
>> (business rules, math fomulas, whatever). So a reader over these
>> strings are perhaps overkill too.
>> Often if you externalize such scripts / rules, you put them in an XML
>> file, in a database, etc. and often you retrieve them out-of-the-box
>> as strings, not as readers.
>> But for things like GCL, which is used by the file system compiler and
>> so on, there you'd probably prefer a reader.
>>
>>> Also it seems a bit odd that internally it needs a String to start with.
>>>  What if the input is fricken huge?  Why can't the internals use a Reader
>>> instead?
>>
>> Code smell if your input is "fricken huge"! :-P
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

I guess this raises the question of whether Groovy will integrate NIO
and NIO2 or whether it will stick with the quagmire that is the
Stream/Reader I/O system.

On Thu, 2009-10-29 at 09:54 +0100, Guillaume Laforge wrote:

> On Wed, Oct 28, 2009 at 12:18, Jason Dillon <jason@...> wrote:
> > I noticed there are a bunch of deprecated bits related to use of
> > InputStreams:
> >
> > @deprecated Prefer using methods taking a Reader rather than an InputStream
> > to avoid wrong encoding issues.
> >
> > But there are no equivalent Reader methods... any reason why?
>
> When you have String variants, you don't really need a Reader.
> Just provide your own StringReader over it, read it, put that in a
> String, and you're done.
> So it's not really necessary.
> Ideally, I wish that there had not been any InputStream variants in
> the first place, and Readers should have been used instead.
> But well... I've deprecated those IS ones, as they are a bit dangerous
> wrt encodings, so people should avoid using them.
> That said, the deprecated message is indeed wrong, and should say use
> the String variants.
> Or Reader variants, since you've added them now.
>

--

Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jochen Theodorou]

Russel Winder schrieb:
> I guess this raises the question of whether Groovy will integrate NIO
> and NIO2 or whether it will stick with the quagmire that is the
> Stream/Reader I/O system.

let me ask the other way around... if the internals supports only the
string and stream variant regardless of what the API provides, and the
stream variant is removed and/or deprecated now... does it really make
sense to talk about reader or NIO without the internals having support
for that? Das an API change to let you assume that a reader will be used
instead of a string makes sense?

I would anser both with NO

If the compiler should support reader and/or NIO, then internal changes
down to where the source is actually read are needed.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:
> I tend to use GroovyShell as an abstraction over the GCL+other muck
> needed to execute a script, and I often use streams not strings or files.

In most cases you can use the file directly, or not? if it where Groovy
code getting the string it would be just calling the getText() method.
 From Java... why not simply calling a DefaultGroovyMethods#getText
variant, that fits your need. That is one import and one expression. NOt
so much work in the end.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 29, 2009, at 10:02 PM, Jochen Theodorou wrote:
> Jason Dillon schrieb:
>> I tend to use GroovyShell as an abstraction over the GCL+other muck  
>> needed to execute a script, and I often use streams not strings or  
>> files.
>
> In most cases you can use the file directly, or not?

Nope, most abstractions I deal with are not files, InputStreams or  
Readers.

> if it where Groovy code getting the string it would be just calling  
> the getText() method.

Not from Groovy.

> From Java... why not simply calling a DefaultGroovyMethods#getText  
> variant, that fits your need. That is one import and one expression.  
> NOt so much work in the end.

Java folks who are integrating small bits of Groovy for the most part  
don't like these sorts of magical methods.

What is your objection to exposing Readers?  This is a common pattern,  
understood by everyone, and used everywhere.

--jason


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 29, 2009, at 9:59 PM, Jochen Theodorou wrote:

> Russel Winder schrieb:
>> I guess this raises the question of whether Groovy will integrate NIO
>> and NIO2 or whether it will stick with the quagmire that is the
>> Stream/Reader I/O system.
>
> let me ask the other way around... if the internals supports only  
> the string and stream variant regardless of what the API provides,  
> and the stream variant is removed and/or deprecated now... does it  
> really make sense to talk about reader or NIO without the internals  
> having support for that? Das an API change to let you assume that a  
> reader will be used instead of a string makes sense?

The InputStream methods simply got a string out of it anyways... so  
the internals are actually only using a String... why I wonder is  
that.  Does the parser only accept a String (I know that is not the  
case)?  Why is this particular bit of API using strings and not  
Readers (or streams for that matter)?

--jason


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:
> On Oct 29, 2009, at 10:02 PM, Jochen Theodorou wrote:
>> Jason Dillon schrieb:
>>> I tend to use GroovyShell as an abstraction over the GCL+other muck
>>> needed to execute a script, and I often use streams not strings or
>>> files.
>>
>> In most cases you can use the file directly, or not?
 >
> Nope, most abstractions I deal with are not files, InputStreams or Readers.

Then Strings or something completely different? If something different
in what can you convert it easily?

>> if it where Groovy code getting the string it would be just calling
>> the getText() method.
>
> Not from Groovy.

You mean you don't read from Groovy I guess, ok.

>> From Java... why not simply calling a DefaultGroovyMethods#getText
>> variant, that fits your need. That is one import and one expression.
>> NOt so much work in the end.
>
> Java folks who are integrating small bits of Groovy for the most part
> don't like these sorts of magical methods.

but they like if a reader is read into a string behind the scenes with
exactly the same magical method? I don't understand.. Well looks like I
simply have to accept it.

> What is your objection to exposing Readers?  This is a common pattern,
> understood by everyone, and used everywhere.

That was just the first reaction on seeing the addition of so many new
public method in groovy.lang/groovy.util I would prefer the restriction
to String, but if you provide tests then I let us keep them.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:

> On Oct 29, 2009, at 9:59 PM, Jochen Theodorou wrote:
>> Russel Winder schrieb:
>>> I guess this raises the question of whether Groovy will integrate NIO
>>> and NIO2 or whether it will stick with the quagmire that is the
>>> Stream/Reader I/O system.
>>
>> let me ask the other way around... if the internals supports only the
>> string and stream variant regardless of what the API provides, and the
>> stream variant is removed and/or deprecated now... does it really make
>> sense to talk about reader or NIO without the internals having support
>> for that? Das an API change to let you assume that a reader will be
>> used instead of a string makes sense?
>
> The InputStream methods simply got a string out of it anyways...

now, yes. Not in the past.

> so the
> internals are actually only using a String... why I wonder is that.  

because of problems with rereading the source later, like powerasserts
need it. Streams have the encoding issue, but frankly I think in 99% of
the cases that is none. You can give the encoding in the
CompilerConfiguration, so unless multiple files with different encodings
are provided I see no real problem. I didn't say anything against that
change, but now I wonder if that is really a good decision. Also this is
new in 1.7... maybe we should consider changing it again... only.. how
do I read from a stream, that does not support reading from it from a
different position? A possible solution for that would be to test if the
Stream supports rereading and if not cache the contents... What do
others think of that?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email