[Lang] Increasing its role [was: Re: [Reflect] Summary of points and relationship with BeanUtils]

[sc...@btopenworld.com]

>  from:    Henri Yandell <ba...@generationjava.com>
> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> > c) decide on whether the naming convention in [Lang] is xxxs as with Strings
> > at present, or xxxUtils as with StringUtils (ie. what [Collections] adopted.
> 
> It used to be all xxxUtils and the decision was made to go away from it
> when they broke out of the Util sub-project.

OK. Like collections will have, there should be a note somewhere in the project (developers guide?) to say that is the naming convention.


> > d) consider other additions to [Lang]
> >    - a Serialization class, with a method that clones via serialization
> 
> Heh. Someone wrote an article on this a year or so back and it's
> languished in my xxx.lang package ever since. Am happy to begin by
> committing that unless someone has a version they've nurtured into
> something more useful.

My version is at 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/joda/Joda/JodaUtils/src/org/joda/util/

Note that the serialize and deserialize methods on Objects should probably be moved to Serialization if the class is to be created. Else put the serialization clone method on Objects.

The Identifiable interface and Identifier class should also be considered (from the above link), this came up in a Bewtixt thread. (although Identifier would need to be made pluggable)

> >    - a StringBuffer class, with the same methods as Strings, but for a
> > StringBuffer.
> 
> Sounds good. Seems to me there is a better way though. java.lang.String
> and StringBuffer don't share that many functionalities from memory. In
> Strings the code either manipulates it as a String, or turns it to a
> StringBuffer. I would hope that despite having two classes, there would
> really only be one implementation method and one method that redirects.
> However these methods would not all live in Strings, or all live in
> StringBuffers.
> 
> I imagine that the StringBuffer methods would pass in a StringBuffer
> expecting that to be modified and not to have a StringBuffer returned?? Or
> if one is returned [as often is the case in java.lang.StringBuffer] that
> it would return the one passed in.

No, what I meant was an instantiable StringBuffer, not a StringBufferUtils. Thus you write
UStringBuffer buf = new UStringBuffer();
thus the buffer can be manipulated accordingly. (UStringBuffer would implement all the methods of StringBuffer for compatability). BTW, there is probably a better name!

Also, there was a discussion on JavaLobby recently where direct manipulation of char arrays was requested. So maybe there should be a Chars utility class with all the functionality, which Strings and UStringBuffer delegate to.


> > e) release [Lang] as a full commons project
> 
> Won't argue. Lang seems to be cropping up as a project that a few others
> are dependant on, so having a release would be nice.
> 
> It would be nice to have more unit tests, mavenise it, doc more, hack out
> ugly String overloads. The biggest issue I'm finding as I use the methods
> is that a lot aren't null safe.
> 
> Once Lang is released, then I can release a 1.0 of String taglib depending
> on it. So time for me to focus hard on Lang I think.

All makes sense. Hopefully when my CVS is confirmed I can contribute?

Stephen

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[Lang] Serialization [was: Increasing its role]

[Stephen Colebourne <sc...@btopenworld.com>]

I've committed the serialization changes I suggested as new classes. I
haven't removed the methods from Objects at the moment, because the
functionality is slightly different.

The code in Objects allowed you to serialize to and from a byte[]. If an
error occurred it was silently absorbed. In the code I have committed,
errors are thrown as SerializationException (runtime exception, as this
error should be picked up during testing). Full test cases added as well.

If I hear nothing back, I will remove the old methods from Objects.

Stephen

----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 19, 2002 6:45 PM
Subject: Re: [Lang] Increasing its role


> From: "Henri Yandell" <ba...@generationjava.com>
> > On Wed, 19 Jun 2002 scolebourne@btopenworld.com wrote:
> > Do you want to start by pushing your serialisation cloner
> > in? I haven't checked it yet, but it sounds far more mature than the one
> > I have.
>
> To confirm, I should create a new Serialization class and move the methods
> about serialization from Objects.
>
>  Are we worried about deprecation, or is this truly sandbox? (I'm hoping
its
> truly sandbox ;-)
>
> Stephen
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Lang] Increasing its role

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Henri Yandell" <ba...@generationjava.com>
> On Wed, 19 Jun 2002 scolebourne@btopenworld.com wrote:
> Do you want to start by pushing your serialisation cloner
> in? I haven't checked it yet, but it sounds far more mature than the one
> I have.

To confirm, I should create a new Serialization class and move the methods
about serialization from Objects.

 Are we worried about deprecation, or is this truly sandbox? (I'm hoping its
truly sandbox ;-)

Stephen




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Lang] Increasing its role

[Henri Yandell <ba...@generationjava.com>]

On Wed, 19 Jun 2002 scolebourne@btopenworld.com wrote:

> OK. Like collections will have, there should be a note somewhere in
> the project (developers guide?) to say that is the naming convention.

Sounds good.

> No, what I meant was an instantiable StringBuffer, not a StringBufferUtils. Thus you write
> UStringBuffer buf = new UStringBuffer();
> thus the buffer can be manipulated accordingly. (UStringBuffer would implement all the methods of StringBuffer for compatability). BTW, there is probably a better name!
>
> Also, there was a discussion on JavaLobby recently where direct manipulation of char arrays was requested. So maybe there should be a Chars utility class with all the functionality, which Strings and UStringBuffer delegate to.

Both sound good. I'm just chomping at maintaining the same functionality
three times.

> > Once Lang is released, then I can release a 1.0 of String taglib depending
> > on it. So time for me to focus hard on Lang I think.
>
> All makes sense. Hopefully when my CVS is confirmed I can contribute?

Would be great. Do you want to start by pushing your serialisation cloner
in? I haven't checked it yet, but it sounds far more mature than the one
I have.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>