Re: [IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Gary Gregory]

On Tue, Oct 3, 2017 at 11:47 AM, Benedikt Ritter  wrote:

> Hello Gary,
>
> > Am 03.10.2017 um 15:07 schrieb Gary Gregory :
> >
> > On Oct 3, 2017 03:47, "Benedikt Ritter"  wrote:
> >
> > Hello Gary,
> >
> >> Am 02.10.2017 um 19:00 schrieb Gary Gregory :
> >>
> >> Hi Benedikt,
> >>
> >> First, thank you for being the RM here.
> >>
> >> Granted, I might have documented this new class better (and made the
> ctor
> >> private.)
> >>
> >> That said, while it is a new class for 2.6, we cannot RERO and change
> the
> >> class name later.
> >
> > Sorry I meant I can roll out another RC to polish this API.
> >
> >>
> >> I do believe that in this case, the narrow class name of "Factory" is
> >> better but I will not -1 the release. Maybe ByteOrderParser would be
> even
> >> better.
> >>
> >> If other operations are needed in the future, like some conversion
> > gadgets,
> >> then a good class name should be created for that, and not dumped in a
> > Util
> >> class. But, hey, that's just me, YMMV. I just like clear names that
> >> demonstrate intent.
> >
> > I have been to fast changing this class without giving others the chance
> to
> > review and comment my changes. For this reason I canceled the release of
> IO
> > 2.6. Let’s find a class design that everybody is happy with.
> >
> >
> > Thank you Benedikt. I created the class based on code I had at work. So
> it
> > is based on a real life use case.
> >
> > IMO, the most narrow name for the class would be (1) ByteOrderParser,
> based
> > on the current code. The widest name would be (2) ByteOrderUtil. The in
> > between name I picked was (3) ByteOrderFactory. These are the three
> options
> > IMO. I like (3) but could live with (1). (2) is a code smell IMO for the
> > reasons stated previously.
>
> I see your point here and I agree. Utils tend to become a dumping ground
> for everything. I’m not to fond of the name Factory, because factories are
> objects which help with complicated object constructions. This class
> creates a ByteOrder instance from a string so I’d say it’s a parser. If you
> can live with this name, lets take it.
>

OK, I can live with ByteOrderParser just fine :-)


>
> Can you please elaborate some more on the use case you have in your
> application? I don’t understand why we need the handling of „Little“ and
> „Big“ Strings. This feels kind of random/specific to a single application
> to me.
>

The JRE's ByteOrder class (sadly it's not an enum) defines LITTLE_ENDIAN
and BIG_ENDIAN and I just wanted something less wordy. But you are right,
it feels somewhat arbitrary to allow for "Big" and "Little". Feel free to
remove support for "Big" and "Little", I'll adapt on my end once 2.6 is out.

Gary


> Regards,
> Benedikt
>
> >
> > Gary,
> >
> >
> > Cheers,
> > Benedikt
> >
> >>
> >> Cheers,
> >> Gary
> >>
> >>
> >> Gary
> >>
> >>
> >>
> >>
> >> On Mon, Oct 2, 2017 at 10:42 AM, Benedikt Ritter 
> > wrote:
> >>
> >>> Hey Gary,
> >>>
>  Am 02.10.2017 um 16:15 schrieb Gary Gregory :
> 
>  I am not happy about the change of class name from ByteOrderFactory to
>  ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go
> by
>  but I have in the middle of moving.
> 
>  - A ByteOrderFactory creates ByteOrder objects and that's it. The
> intent
> >>> is
>  clear and focused.
>  - The use of ByteOrder "Utils" does not have any use ATM, there are no
>  other "util" methods.
>  - The use of ByteOrder "Utils" leads to the same problems we have seen
> >>> with
>  [lang]'s StringUtils: An endless, unorganized, dumping ground.
>  - Granted there is less room for expansion with ByteOrder than with
>  Strings. But, having dealt with byte order code in the past, I can
> tell
> >>> you
>  from experience it can grow a plenty to deal with all sorts of funky
> >>> cases.
>  Ever heard of middle-endian? ;-)
> >>>
> >>> Thank you for your feedback! To be honest I was confused when I came
> > along
> >>> that class. My observations were:
> >>>
> >>> - Only static methods, but instantiable
> >>> - It is really a parser but it was called factory (okay, „utils" isn’t
> >>> better…)
> >>> - strange special handling of Strings „Little“ and „Big“ with no
> >>> explanation
> >>>
> >>> So I tried to change it in a way, that it makes more sense to me, but
> > that
> >>> doesn’t seem to make sense for everybody :-)
> >>>
> >>> I have no problem with RERO, if this class need more polishing.
> >>>
> >>> Regards,
> >>> Benedikt
> >>>
> 
>  Gary
> 
>  On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
> 
> > Author: sebb
> > Date: Sat Mar 17 00:28:40 2012
> > New Revision: 1301835
> >
> > URL: http://svn.apache.org/viewvc?rev=1301835=rev
> > Log:
> > Move changes.xml to location expected by CP24
> > Add previous release 

Re: [IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Benedikt Ritter]

Hello Gary,

> Am 03.10.2017 um 15:07 schrieb Gary Gregory :
> 
> On Oct 3, 2017 03:47, "Benedikt Ritter"  wrote:
> 
> Hello Gary,
> 
>> Am 02.10.2017 um 19:00 schrieb Gary Gregory :
>> 
>> Hi Benedikt,
>> 
>> First, thank you for being the RM here.
>> 
>> Granted, I might have documented this new class better (and made the ctor
>> private.)
>> 
>> That said, while it is a new class for 2.6, we cannot RERO and change the
>> class name later.
> 
> Sorry I meant I can roll out another RC to polish this API.
> 
>> 
>> I do believe that in this case, the narrow class name of "Factory" is
>> better but I will not -1 the release. Maybe ByteOrderParser would be even
>> better.
>> 
>> If other operations are needed in the future, like some conversion
> gadgets,
>> then a good class name should be created for that, and not dumped in a
> Util
>> class. But, hey, that's just me, YMMV. I just like clear names that
>> demonstrate intent.
> 
> I have been to fast changing this class without giving others the chance to
> review and comment my changes. For this reason I canceled the release of IO
> 2.6. Let’s find a class design that everybody is happy with.
> 
> 
> Thank you Benedikt. I created the class based on code I had at work. So it
> is based on a real life use case.
> 
> IMO, the most narrow name for the class would be (1) ByteOrderParser, based
> on the current code. The widest name would be (2) ByteOrderUtil. The in
> between name I picked was (3) ByteOrderFactory. These are the three options
> IMO. I like (3) but could live with (1). (2) is a code smell IMO for the
> reasons stated previously.

I see your point here and I agree. Utils tend to become a dumping ground for 
everything. I’m not to fond of the name Factory, because factories are objects 
which help with complicated object constructions. This class creates a 
ByteOrder instance from a string so I’d say it’s a parser. If you can live with 
this name, lets take it.

Can you please elaborate some more on the use case you have in your 
application? I don’t understand why we need the handling of „Little“ and „Big“ 
Strings. This feels kind of random/specific to a single application to me.

Regards,
Benedikt

> 
> Gary
> 
> 
> Cheers,
> Benedikt
> 
>> 
>> Cheers,
>> Gary
>> 
>> 
>> Gary
>> 
>> 
>> 
>> 
>> On Mon, Oct 2, 2017 at 10:42 AM, Benedikt Ritter 
> wrote:
>> 
>>> Hey Gary,
>>> 
 Am 02.10.2017 um 16:15 schrieb Gary Gregory :
 
 I am not happy about the change of class name from ByteOrderFactory to
 ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go by
 but I have in the middle of moving.
 
 - A ByteOrderFactory creates ByteOrder objects and that's it. The intent
>>> is
 clear and focused.
 - The use of ByteOrder "Utils" does not have any use ATM, there are no
 other "util" methods.
 - The use of ByteOrder "Utils" leads to the same problems we have seen
>>> with
 [lang]'s StringUtils: An endless, unorganized, dumping ground.
 - Granted there is less room for expansion with ByteOrder than with
 Strings. But, having dealt with byte order code in the past, I can tell
>>> you
 from experience it can grow a plenty to deal with all sorts of funky
>>> cases.
 Ever heard of middle-endian? ;-)
>>> 
>>> Thank you for your feedback! To be honest I was confused when I came
> along
>>> that class. My observations were:
>>> 
>>> - Only static methods, but instantiable
>>> - It is really a parser but it was called factory (okay, „utils" isn’t
>>> better…)
>>> - strange special handling of Strings „Little“ and „Big“ with no
>>> explanation
>>> 
>>> So I tried to change it in a way, that it makes more sense to me, but
> that
>>> doesn’t seem to make sense for everybody :-)
>>> 
>>> I have no problem with RERO, if this class need more polishing.
>>> 
>>> Regards,
>>> Benedikt
>>> 
 
 Gary
 
 On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
 
> Author: sebb
> Date: Sat Mar 17 00:28:40 2012
> New Revision: 1301835
> 
> URL: http://svn.apache.org/viewvc?rev=1301835=rev
> Log:
> Move changes.xml to location expected by CP24
> Add previous release notes to end of .vm file so we keep history when
> regenerating
> 
> Added:
>  commons/proper/io/trunk/src/changes/
>- copied from r1178270, commons/proper/io/trunk/src/changes/
>  commons/proper/io/trunk/src/changes/changes.xml
>- copied unchanged from r1300447, commons/proper/io/trunk/src/
> changes/changes.xml
>  commons/proper/io/trunk/src/changes/release-notes.vm   (with props)
> Modified:
>  commons/proper/io/trunk/RELEASE-NOTES.txt
> 
> Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
> URL: http://svn.apache.org/viewvc/commons/proper/io/trunk/
> RELEASE-NOTES.txt?rev=1301835=1301834=1301835=diff

Re: [IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Gary Gregory]

On Oct 3, 2017 03:47, "Benedikt Ritter"  wrote:

Hello Gary,

> Am 02.10.2017 um 19:00 schrieb Gary Gregory :
>
> Hi Benedikt,
>
> First, thank you for being the RM here.
>
> Granted, I might have documented this new class better (and made the ctor
> private.)
>
> That said, while it is a new class for 2.6, we cannot RERO and change the
> class name later.

Sorry I meant I can roll out another RC to polish this API.

>
> I do believe that in this case, the narrow class name of "Factory" is
> better but I will not -1 the release. Maybe ByteOrderParser would be even
> better.
>
> If other operations are needed in the future, like some conversion
gadgets,
> then a good class name should be created for that, and not dumped in a
Util
> class. But, hey, that's just me, YMMV. I just like clear names that
> demonstrate intent.

I have been to fast changing this class without giving others the chance to
review and comment my changes. For this reason I canceled the release of IO
2.6. Let’s find a class design that everybody is happy with.


Thank you Benedikt. I created the class based on code I had at work. So it
is based on a real life use case.

IMO, the most narrow name for the class would be (1) ByteOrderParser, based
on the current code. The widest name would be (2) ByteOrderUtil. The in
between name I picked was (3) ByteOrderFactory. These are the three options
IMO. I like (3) but could live with (1). (2) is a code smell IMO for the
reasons stated previously.

Gary


Cheers,
Benedikt

>
> Cheers,
> Gary
>
>
> Gary
>
>
>
>
> On Mon, Oct 2, 2017 at 10:42 AM, Benedikt Ritter 
wrote:
>
>> Hey Gary,
>>
>>> Am 02.10.2017 um 16:15 schrieb Gary Gregory :
>>>
>>> I am not happy about the change of class name from ByteOrderFactory to
>>> ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go by
>>> but I have in the middle of moving.
>>>
>>> - A ByteOrderFactory creates ByteOrder objects and that's it. The intent
>> is
>>> clear and focused.
>>> - The use of ByteOrder "Utils" does not have any use ATM, there are no
>>> other "util" methods.
>>> - The use of ByteOrder "Utils" leads to the same problems we have seen
>> with
>>> [lang]'s StringUtils: An endless, unorganized, dumping ground.
>>> - Granted there is less room for expansion with ByteOrder than with
>>> Strings. But, having dealt with byte order code in the past, I can tell
>> you
>>> from experience it can grow a plenty to deal with all sorts of funky
>> cases.
>>> Ever heard of middle-endian? ;-)
>>
>> Thank you for your feedback! To be honest I was confused when I came
along
>> that class. My observations were:
>>
>> - Only static methods, but instantiable
>> - It is really a parser but it was called factory (okay, „utils" isn’t
>> better…)
>> - strange special handling of Strings „Little“ and „Big“ with no
>> explanation
>>
>> So I tried to change it in a way, that it makes more sense to me, but
that
>> doesn’t seem to make sense for everybody :-)
>>
>> I have no problem with RERO, if this class need more polishing.
>>
>> Regards,
>> Benedikt
>>
>>>
>>> Gary
>>>
>>> On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
>>>
 Author: sebb
 Date: Sat Mar 17 00:28:40 2012
 New Revision: 1301835

 URL: http://svn.apache.org/viewvc?rev=1301835=rev
 Log:
 Move changes.xml to location expected by CP24
 Add previous release notes to end of .vm file so we keep history when
 regenerating

 Added:
   commons/proper/io/trunk/src/changes/
 - copied from r1178270, commons/proper/io/trunk/src/changes/
   commons/proper/io/trunk/src/changes/changes.xml
 - copied unchanged from r1300447, commons/proper/io/trunk/src/
 changes/changes.xml
   commons/proper/io/trunk/src/changes/release-notes.vm   (with props)
 Modified:
   commons/proper/io/trunk/RELEASE-NOTES.txt

 Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
 URL: http://svn.apache.org/viewvc/commons/proper/io/trunk/
 RELEASE-NOTES.txt?rev=1301835=1301834=1301835=diff
 
 ==
 --- commons/proper/io/trunk/RELEASE-NOTES.txt (original)
 +++ commons/proper/io/trunk/RELEASE-NOTES.txt Sat Mar 17 00:28:40 2012
 @@ -1,8 +1,7 @@
 -$Id$

 -Commons IO Package
 -   Version 2.1
 -  Release Notes
 + Commons IO Package
 +Version 2.2
 +   Release Notes

 INTRODUCTION:

 @@ -17,31 +16,39 @@ file comparators and endian transformati
 Commons IO Package Version 2.2
 
 ==

 +The Commons IO library contains utility classes, stream
>> implementations,
 file filters, file comparators and 

Re: [IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Benedikt Ritter]

Hello Gary,

> Am 02.10.2017 um 19:00 schrieb Gary Gregory :
> 
> Hi Benedikt,
> 
> First, thank you for being the RM here.
> 
> Granted, I might have documented this new class better (and made the ctor
> private.)
> 
> That said, while it is a new class for 2.6, we cannot RERO and change the
> class name later.

Sorry I meant I can roll out another RC to polish this API.

> 
> I do believe that in this case, the narrow class name of "Factory" is
> better but I will not -1 the release. Maybe ByteOrderParser would be even
> better.
> 
> If other operations are needed in the future, like some conversion gadgets,
> then a good class name should be created for that, and not dumped in a Util
> class. But, hey, that's just me, YMMV. I just like clear names that
> demonstrate intent.

I have been to fast changing this class without giving others the chance to 
review and comment my changes. For this reason I canceled the release of IO 
2.6. Let’s find a class design that everybody is happy with.

Cheers,
Benedikt

> 
> Cheers,
> Gary
> 
> 
> Gary
> 
> 
> 
> 
> On Mon, Oct 2, 2017 at 10:42 AM, Benedikt Ritter  wrote:
> 
>> Hey Gary,
>> 
>>> Am 02.10.2017 um 16:15 schrieb Gary Gregory :
>>> 
>>> I am not happy about the change of class name from ByteOrderFactory to
>>> ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go by
>>> but I have in the middle of moving.
>>> 
>>> - A ByteOrderFactory creates ByteOrder objects and that's it. The intent
>> is
>>> clear and focused.
>>> - The use of ByteOrder "Utils" does not have any use ATM, there are no
>>> other "util" methods.
>>> - The use of ByteOrder "Utils" leads to the same problems we have seen
>> with
>>> [lang]'s StringUtils: An endless, unorganized, dumping ground.
>>> - Granted there is less room for expansion with ByteOrder than with
>>> Strings. But, having dealt with byte order code in the past, I can tell
>> you
>>> from experience it can grow a plenty to deal with all sorts of funky
>> cases.
>>> Ever heard of middle-endian? ;-)
>> 
>> Thank you for your feedback! To be honest I was confused when I came along
>> that class. My observations were:
>> 
>> - Only static methods, but instantiable
>> - It is really a parser but it was called factory (okay, „utils" isn’t
>> better…)
>> - strange special handling of Strings „Little“ and „Big“ with no
>> explanation
>> 
>> So I tried to change it in a way, that it makes more sense to me, but that
>> doesn’t seem to make sense for everybody :-)
>> 
>> I have no problem with RERO, if this class need more polishing.
>> 
>> Regards,
>> Benedikt
>> 
>>> 
>>> Gary
>>> 
>>> On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
>>> 
 Author: sebb
 Date: Sat Mar 17 00:28:40 2012
 New Revision: 1301835
 
 URL: http://svn.apache.org/viewvc?rev=1301835=rev
 Log:
 Move changes.xml to location expected by CP24
 Add previous release notes to end of .vm file so we keep history when
 regenerating
 
 Added:
   commons/proper/io/trunk/src/changes/
 - copied from r1178270, commons/proper/io/trunk/src/changes/
   commons/proper/io/trunk/src/changes/changes.xml
 - copied unchanged from r1300447, commons/proper/io/trunk/src/
 changes/changes.xml
   commons/proper/io/trunk/src/changes/release-notes.vm   (with props)
 Modified:
   commons/proper/io/trunk/RELEASE-NOTES.txt
 
 Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
 URL: http://svn.apache.org/viewvc/commons/proper/io/trunk/
 RELEASE-NOTES.txt?rev=1301835=1301834=1301835=diff
 
 ==
 --- commons/proper/io/trunk/RELEASE-NOTES.txt (original)
 +++ commons/proper/io/trunk/RELEASE-NOTES.txt Sat Mar 17 00:28:40 2012
 @@ -1,8 +1,7 @@
 -$Id$
 
 -Commons IO Package
 -   Version 2.1
 -  Release Notes
 + Commons IO Package
 +Version 2.2
 +   Release Notes
 
 INTRODUCTION:
 
 @@ -17,31 +16,39 @@ file comparators and endian transformati
 Commons IO Package Version 2.2
 
 ==
 
 +The Commons IO library contains utility classes, stream
>> implementations,
 file filters, file comparators and endian classes.
 +
 +$release.description.replaceAll("  ", "
 +")
 +
 +Changes in this version include:
 +
 New features:
 -o Use terabyte (TB) , petabyte (PB) and exabyte (EB) in FileUtils.
>> byteCountToDisplaySize(long
 size)  Issue: IO-287. Thanks to Ron Kuris, Gary Gregory.
 -o FileUtils.listFiles() doesn't return directories  Issue: IO-173.
>> Thanks
 to Marcos Vinícius da Silva.
 -o CharSequenceInputStream to efficiently 

Re: [IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Gary Gregory]

Hi Benedikt,

First, thank you for being the RM here.

Granted, I might have documented this new class better (and made the ctor
private.)

That said, while it is a new class for 2.6, we cannot RERO and change the
class name later.

I do believe that in this case, the narrow class name of "Factory" is
better but I will not -1 the release. Maybe ByteOrderParser would be even
better.

If other operations are needed in the future, like some conversion gadgets,
then a good class name should be created for that, and not dumped in a Util
class. But, hey, that's just me, YMMV. I just like clear names that
demonstrate intent.

Cheers,
Gary


Gary




On Mon, Oct 2, 2017 at 10:42 AM, Benedikt Ritter  wrote:

> Hey Gary,
>
> > Am 02.10.2017 um 16:15 schrieb Gary Gregory :
> >
> > I am not happy about the change of class name from ByteOrderFactory to
> > ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go by
> > but I have in the middle of moving.
> >
> > - A ByteOrderFactory creates ByteOrder objects and that's it. The intent
> is
> > clear and focused.
> > - The use of ByteOrder "Utils" does not have any use ATM, there are no
> > other "util" methods.
> > - The use of ByteOrder "Utils" leads to the same problems we have seen
> with
> > [lang]'s StringUtils: An endless, unorganized, dumping ground.
> > - Granted there is less room for expansion with ByteOrder than with
> > Strings. But, having dealt with byte order code in the past, I can tell
> you
> > from experience it can grow a plenty to deal with all sorts of funky
> cases.
> > Ever heard of middle-endian? ;-)
>
> Thank you for your feedback! To be honest I was confused when I came along
> that class. My observations were:
>
> - Only static methods, but instantiable
> - It is really a parser but it was called factory (okay, „utils" isn’t
> better…)
> - strange special handling of Strings „Little“ and „Big“ with no
> explanation
>
> So I tried to change it in a way, that it makes more sense to me, but that
> doesn’t seem to make sense for everybody :-)
>
> I have no problem with RERO, if this class need more polishing.
>
> Regards,
> Benedikt
>
> >
> > Gary
> >
> > On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
> >
> >> Author: sebb
> >> Date: Sat Mar 17 00:28:40 2012
> >> New Revision: 1301835
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1301835=rev
> >> Log:
> >> Move changes.xml to location expected by CP24
> >> Add previous release notes to end of .vm file so we keep history when
> >> regenerating
> >>
> >> Added:
> >>commons/proper/io/trunk/src/changes/
> >>  - copied from r1178270, commons/proper/io/trunk/src/changes/
> >>commons/proper/io/trunk/src/changes/changes.xml
> >>  - copied unchanged from r1300447, commons/proper/io/trunk/src/
> >> changes/changes.xml
> >>commons/proper/io/trunk/src/changes/release-notes.vm   (with props)
> >> Modified:
> >>commons/proper/io/trunk/RELEASE-NOTES.txt
> >>
> >> Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
> >> URL: http://svn.apache.org/viewvc/commons/proper/io/trunk/
> >> RELEASE-NOTES.txt?rev=1301835=1301834=1301835=diff
> >> 
> >> ==
> >> --- commons/proper/io/trunk/RELEASE-NOTES.txt (original)
> >> +++ commons/proper/io/trunk/RELEASE-NOTES.txt Sat Mar 17 00:28:40 2012
> >> @@ -1,8 +1,7 @@
> >> -$Id$
> >>
> >> -Commons IO Package
> >> -   Version 2.1
> >> -  Release Notes
> >> + Commons IO Package
> >> +Version 2.2
> >> +   Release Notes
> >>
> >> INTRODUCTION:
> >>
> >> @@ -17,31 +16,39 @@ file comparators and endian transformati
> >> Commons IO Package Version 2.2
> >> 
> >> ==
> >>
> >> +The Commons IO library contains utility classes, stream
> implementations,
> >> file filters, file comparators and endian classes.
> >> +
> >> +$release.description.replaceAll("  ", "
> >> +")
> >> +
> >> +Changes in this version include:
> >> +
> >> New features:
> >> -o Use terabyte (TB) , petabyte (PB) and exabyte (EB) in FileUtils.
> byteCountToDisplaySize(long
> >> size)  Issue: IO-287. Thanks to Ron Kuris, Gary Gregory.
> >> -o FileUtils.listFiles() doesn't return directories  Issue: IO-173.
> Thanks
> >> to Marcos Vinícius da Silva.
> >> -o CharSequenceInputStream to efficiently stream content of a
> >> CharSequence  Issue: IO-297. Thanks to Oleg Kalnichevski.
> >> -o The second constructor of Tailer class does not pass 'delay' to the
> >> third one  Issue: IO-304. Thanks to liangly.
> >> -o TeeOutputStream does not call branch.close() when main.close() throws
> >> an exception  Issue: IO-303. Thanks to fabian.barney.
> >> -o ArrayIndexOutOfBoundsException in BOMInputStream when reading a file
> >> without BOM multiple times  Issue: IO-302. Thanks to 

[IO] Design of ByteOrderFactory (Was: svn commit: r1301835 - in /commons/proper/io/trunk: RELEASE-NOTES.txt src/changes/ src/changes/changes.xml src/changes/release-notes.vm)

[Benedikt Ritter]

Hey Gary,

> Am 02.10.2017 um 16:15 schrieb Gary Gregory :
> 
> I am not happy about the change of class name from ByteOrderFactory to
> ByteOrderUtils. I am also did a knee jerk -1 when I saw the commit go by
> but I have in the middle of moving.
> 
> - A ByteOrderFactory creates ByteOrder objects and that's it. The intent is
> clear and focused.
> - The use of ByteOrder "Utils" does not have any use ATM, there are no
> other "util" methods.
> - The use of ByteOrder "Utils" leads to the same problems we have seen with
> [lang]'s StringUtils: An endless, unorganized, dumping ground.
> - Granted there is less room for expansion with ByteOrder than with
> Strings. But, having dealt with byte order code in the past, I can tell you
> from experience it can grow a plenty to deal with all sorts of funky cases.
> Ever heard of middle-endian? ;-)

Thank you for your feedback! To be honest I was confused when I came along that 
class. My observations were:

- Only static methods, but instantiable
- It is really a parser but it was called factory (okay, „utils" isn’t better…)
- strange special handling of Strings „Little“ and „Big“ with no explanation

So I tried to change it in a way, that it makes more sense to me, but that 
doesn’t seem to make sense for everybody :-)

I have no problem with RERO, if this class need more polishing.

Regards,
Benedikt

> 
> Gary
> 
> On Fri, Mar 16, 2012 at 6:28 PM,  wrote:
> 
>> Author: sebb
>> Date: Sat Mar 17 00:28:40 2012
>> New Revision: 1301835
>> 
>> URL: http://svn.apache.org/viewvc?rev=1301835=rev
>> Log:
>> Move changes.xml to location expected by CP24
>> Add previous release notes to end of .vm file so we keep history when
>> regenerating
>> 
>> Added:
>>commons/proper/io/trunk/src/changes/
>>  - copied from r1178270, commons/proper/io/trunk/src/changes/
>>commons/proper/io/trunk/src/changes/changes.xml
>>  - copied unchanged from r1300447, commons/proper/io/trunk/src/
>> changes/changes.xml
>>commons/proper/io/trunk/src/changes/release-notes.vm   (with props)
>> Modified:
>>commons/proper/io/trunk/RELEASE-NOTES.txt
>> 
>> Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
>> URL: http://svn.apache.org/viewvc/commons/proper/io/trunk/
>> RELEASE-NOTES.txt?rev=1301835=1301834=1301835=diff
>> 
>> ==
>> --- commons/proper/io/trunk/RELEASE-NOTES.txt (original)
>> +++ commons/proper/io/trunk/RELEASE-NOTES.txt Sat Mar 17 00:28:40 2012
>> @@ -1,8 +1,7 @@
>> -$Id$
>> 
>> -Commons IO Package
>> -   Version 2.1
>> -  Release Notes
>> + Commons IO Package
>> +Version 2.2
>> +   Release Notes
>> 
>> INTRODUCTION:
>> 
>> @@ -17,31 +16,39 @@ file comparators and endian transformati
>> Commons IO Package Version 2.2
>> 
>> ==
>> 
>> +The Commons IO library contains utility classes, stream implementations,
>> file filters, file comparators and endian classes.
>> +
>> +$release.description.replaceAll("  ", "
>> +")
>> +
>> +Changes in this version include:
>> +
>> New features:
>> -o Use terabyte (TB) , petabyte (PB) and exabyte (EB) in 
>> FileUtils.byteCountToDisplaySize(long
>> size)  Issue: IO-287. Thanks to Ron Kuris, Gary Gregory.
>> -o FileUtils.listFiles() doesn't return directories  Issue: IO-173. Thanks
>> to Marcos Vinícius da Silva.
>> -o CharSequenceInputStream to efficiently stream content of a
>> CharSequence  Issue: IO-297. Thanks to Oleg Kalnichevski.
>> -o The second constructor of Tailer class does not pass 'delay' to the
>> third one  Issue: IO-304. Thanks to liangly.
>> -o TeeOutputStream does not call branch.close() when main.close() throws
>> an exception  Issue: IO-303. Thanks to fabian.barney.
>> -o ArrayIndexOutOfBoundsException in BOMInputStream when reading a file
>> without BOM multiple times  Issue: IO-302. Thanks to jsteuerwald, detinho.
>> -o Add IOUtils.closeQuietly(Selector) necessary  Issue: IO-301. Thanks to
>> kaykay.unique.
>> -o IOUtils.closeQuietly() should take a ServerSocket as a parameter
>> Issue: IO-292. Thanks to sebb.
>> -o Add read/readFully methods to IOUtils  Issue: IO-290. Thanks to sebb.
>> -o Supply a ReversedLinesFileReader  Issue: IO-288. Thanks to Georg
>> Henzler.
>> -o Add new function FileUtils.directoryContains.  Issue: IO-291. Thanks to
>> ggregory.
>> -o FileUtils.contentEquals and IOUtils.contentEquals - Add option to
>> ignore "line endings"
>> -Added contentEqualsIgnoreEOL methods to both classes  Issue:
>> IO-275. Thanks to CJ Aspromgos.
>> +o IO-287:  Use terabyte (TB) , petabyte (PB) and exabyte (EB) in
>> FileUtils.byteCountToDisplaySize(long size) Thanks to Ron Kuris, Gary
>> Gregory.
>> +o IO-173:  FileUtils.listFiles() doesn't return directories Thanks to
>> Marcos Vinícius da Silva.