RE: Commons-net.FTPClient
Doing the setControlEncoding would be wonderful, I have recompiled the code doing what you suggested and it does work, but I um can't use it because its not an official release :) -Original Message- From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] Sent: Friday, August 06, 2004 9:46 AM To: Jakarta Commons Developers List Subject: Re: Commons-net.FTPClient In message <[EMAIL PROTECTED]>, Steve Cohen writes: >Sorry I missed your earlier post. The answer is, unfortunately, that >the package does not support the easy conversion to UTF-8. If he needs to change the encoding for the control connection, he can recompile the source with FTP.__DEFAULT_ENCODING redefined. If it is a common requirement to use multi-byte character encodings on the control connection, we can add a setControlEncoding or some such method and/or make the control input and output reader/writers protected. There may be some way for telnet (the FTP control connection) to autonegotiate the character encoding, but there's no reason to believe FTP servers dealing in UTF-8 or other multi-byte encodings implement a negotiation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons-net.FTPClient
Thanks for he reply, -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Thursday, August 05, 2004 9:29 PM To: Jakarta Commons Developers List Subject: Re: Commons-net.FTPClient Sorry I missed your earlier post. The answer is, unfortunately, that the package does not support the easy conversion to UTF-8. Steve Cohen On Wednesday 04 August 2004 2:01 pm, Ash, Michael L wrote: > I sent this to the users group several days ago and haven't gotten a > response so I thought I would send it here with some additional info I > found. > > Is there any reason to not use UTF-8 instead of iso-8859-1? > > > The problem I am trying to solve is to send a file from an English > based client to a Chinese based ftp server. The user name and > password are Chinese characters stored as utf-8. It appears that the > FTPClient only communications in iso-8859-1. Is there a way for me to > change it to UTF-8? > > Thanks > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-net.FTPClient
I sent this to the users group several days ago and haven't gotten a response so I thought I would send it here with some additional info I found. Is there any reason to not use UTF-8 instead of iso-8859-1? The problem I am trying to solve is to send a file from an English based client to a Chinese based ftp server. The user name and password are Chinese characters stored as utf-8. It appears that the FTPClient only communications in iso-8859-1. Is there a way for me to change it to UTF-8? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] new StringBuffer.. what to call it
BTW: MutableString is a bad name as it can imply a class that holds a String and has a getString and setString method. Stephen Can you tell us why the name MutableString implies it has a getString and setString. And what do people think here of introducing a different term (say Strand) for this concept as I discussed earlier (I paste that here, last time it was buried under confusion due to a typo.) " Talking about name, I would add my opinion that while it might be nice to have a name for the replacer that is much like the replacee, (StringBuf) one might prefer a more descriptive name at the expense of this convenience: (*** MutableString). As a compromise between the two, the name Strand can be adopted (Str... thus near the original one + can be defined to represent a mutable string contrasted with "String" which, by virtue of the so-named class in the API, is immutable.) " Ash - Run, rabbit run. Dig that hole, forget the sun, And when at last the work is done Don't sit down it's time to dig another one. _ Our best dial-up offer is back. Get MSN Dial-up Internet Service for 6 months @ $9.95/month now! http://join.msn.com/?page=dept/dialup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] concept proposal: error resort
The concept of error resort. I have in mind a concept, which if you find useful, could perhaps find a place in the core packages we are setting up around the use of Java. This concerns the response of a class to known erroneous conditions. Taking the scenario of fetching a value, as an example, typically there are two possible responses, when something goes wrong: either return null or throw an exception. When one tries to fetch a property using ResourceBundle, a MissingResourceException is thrown if the property is not found, whereas the class java.lang.Properties behaves differently (returns null.) My idea is to introduce a concept whereby the client (user of a class/API) is given the choice to determine the response of the class used, to known erroneous conditions (provided, of course, it makes sense to give this choice to the user.) I call this Error Resort: the ability to change what behavior a class resorts to, on known erroneous conditions. My idea for implementing this is as follows: A core package, such as lang, will define an interface which has a method like: setErrorResort(int CONSTANT); with constants such as THROW_EXCEPTION, RETURN_NULL, etc defined in the interface and passable to this method. Any class offering the facility of Error Resort will implement this interface and support the method. We could perhaps have other convenience classes to facilitate implementation or the like. But the concept is that, certain classes can choose (rather, their creators) to give the choice of error resort to the users of that class, while hitherto such a thing has always been defined in the class in an iron-clad manner. The idea came to me when I was using ResourceBundle and I wished it returned null instead of throwing the exception when the key is not found. Whether in this case it makes sense or not, I am throwing this idea for debate, and it would be good if a useful addition can be made to the core library here. Waiting for comments, Ash - Run, rabbit run. Dig that hole, forget the sun, And when at last the work is done Don't sit down it's time to dig another one. _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] new StringBuffer
Sounds good, I will then work on a StringBuffer replacement, and then
later on get on to providing it with an XUtils.
That way, we will also be able to optimize the subsequent StringBufferUtils
implementation using package-private access.
I have always been a little disappointed with the facilities
java.lang.StringBuffer
offered, and now I have a chance to do something abt it :)
And now for the name game: I propose MutableString.
Other possible name suggestions, some quite fancy, would be:
Strand, CharStrand
Token,
Bead, CharBead,
CharGroup, CharBunch,
CharLot, StringLot
I find Strand especially useful because that lets us talk about a mutable
string in a conceptually distinct manner. Of course, its replacive role is
not immediate obvious by the name, and some might suggest that it is better
that the new name reflects its surrogate nature wrt StringBuffer. However, a
new coin may be useful in the long term. Just my 2 cents.
Ash
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 22:15
To: Jakarta Commons Developers List
Subject: Re: [lang] StringBufferUtils replacement for StringUtils --
Ah, I see what you mean. And no that wasn't what I meant :-)
There is the potential for a StringBufferUtils, with similar methods to
StringUtils, but where the first passed in parameter is a StringBuffer.
However, what I was thinking of (see the todo list in status.html) is a new
instantiable class
public AStringBuffer() {
private char[] buffer = new char[32];
private int size = 0;
public AStringBuffer() {
}
public void append(Object obj) {
// copy to end of buffer
}
}
ie. a direct StringBuffer replacement.
Both are good candidates for [lang].
Stephen
- Original Message -
From: "ASHWIN Suresh" <[EMAIL PROTECTED]>
> With the one difference that the methods here don't return aything, but
> instead modify the StringBuffer
> passed in, directly.
> I will start work on it tonight.
> Ash
>
>
> > -Original Message-
> > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 09, 2003 20:07
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] String Utils replacement for StringUtils -- was
> > ([lang] StringUtils.split() functionality wrt separator repeats)
> >
> >
> > The string buffer class needs to begin by having all the same
> > methods as
> > StringBuffer, and they should do exactly the same. Then,
> > methods to handle
> > null would be added:
> > appendSilentNull()
> >
> > At that point, we could evaluate it and see what else should be added.
> >
> > Stephen
> >
> >
> > - Original Message -
> > From: "ASHWIN Suresh" <[EMAIL PROTECTED]>
> > > Incidentally (or perhaps it was to come), I was about to
> > send out another
> > > email
> > > proposing a StringUtils-like class that handles
> > StringBuffer instead.
> > > I would be interested in writing it, but I need to evaluate
> > how much time
> > I
> > > can afford
> > > to it (will let u know).
> > >
> > > In the meanwhile, assuming I can go ahead, you can list out
> > right away
> > what
> > > differences
> > > you see between StringUtils and the StringBuffer
> > counterpart. I can, for
> > > now, perhaps cover the
> > > simpler methods which are similar to the StringUtils ones.
> > >
> > > Regarding tightening admissibility of new methods to a
> > class because it is
> > > large, I
> > > am of the opinion that for a class of only static methods
> > such as this
> > one,
> > > why should there be any hesitation. StringUtils is but a
> > repository of all
> > > such
> > > features, so as long as we have clear documentation, I see
> > no reason why
> > > largeness
> > > should lead to limits to having more methods.
> > > Let me know.
> > >
> > > Ash
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, December 08, 2003 22:05
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [lang] StringUtils.split() functionality wrt
> > separator
> > > > repeats
> > > >
> > > >
> > > > With StringUtils, we now face tough decisions. The class is
> > > > already very
> > > > large, and adding more and more methods is not necessarily
> > > > the answer. I am
> > > > now applyi
RE: [lang] StringUtils.split() functionality wrt separator repeats
Hi Matthew, I had come across the Tokenizer class in the lang package, and I agree that it offers much more control and flexibility. Here however, from a developer's perspective, I had meant to discuss the functionality of the StringUtils.split() method, regardless of such functionality available elsewhere. Ash -Original Message- From: Inger, Matthew [mailto:[EMAIL PROTECTED] try the new "Tokenizer" class. You can get it from CVS. -Original Message- From: Ash .. [mailto:[EMAIL PROTECTED] Subject: [lang] StringUtils.split() functionality wrt separator repeats The StringUtils.split(), suggest as an alternative to StringTokenizer, ignores adjacent separators. However, I feel that it would be better if they were not ignored, and empty strings be returned when such a case occurs. Or, there be an overloaded option which lets the user specify whether to ignore separator repeats or not. As I see it, it is more often that a separator repeat occurs due to the absence of data in a specified series of, say, cells. Taking the typical case of a CSV file line read, finding two commas would mean a cell is empty, not that the resultant array should have one element less. It must rather have the expected number of elements with the repeat case entailing an empty String. Comments. Ash - Run, rabbit run. Dig that hole, forget the sun, And when at last the work is done Don't sit down it's time to dig another one. _ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Anyone cares in patches?
-Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Dear Commonners, LOL!! Funny name. Hope this place doesn't become commonplace thow!! - Run, rabbit run. Dig that hole, forget the sun, And when at last the work is done Don't sit down it's time to dig another one. _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
class-mobility between packages
On observing some of the programming activity on this list, I find that classes are moved around -- respectably speaking, refactored -- into other packages quite generously. I would like to know what the general guidelines to this are, especially I mean, where do you draw the line. And with special view on backward-compatibility, what is the guiding principle here? I ask this is special relevance to lang, collections and primitives, but the question applies to any others within the commons framework as well. Ash _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[primitives] roadmap
I would like to know what the general roadmap for the primitives project is, when the next release is slated to be, what remains to be done in view of that release, and the kind. Ash _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [collections] MapUtils.getXxx() return types - repost
Proposed method sigs look OK to me. public static double getIntValue(Map map, Object key) public static double getIntValue(Map map, Object key, int defaultValue) Stephen Alright. I'll take that as the green signal for going ahead with implementing the methods, and get to work on it right away. Oops, I had meant "public static int getIntValue(Map map, Object key)" and so on. Ash PS: Waiting to know that the ArrayUtils.subarray() primitive implementation was ok. _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] ArrayUtils.subarray(primitives) patch
Please find enclosed the patches for the primitive-array implementations of the subarray method. I am open to comments, especially on the tests. Ashwin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: [collections] Primitive-value maps
Hi Arun, I had a look at Primitives, but I didnt find anything on primitive-value maps. Am I missing something here? Ashwin -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 17:54 Ash, Classes for this purpose which previously existed in COLLECTIONS were moved to the Sandbox project - PRIMITIVES. Please take a look there. There's apparently a lot of work going on with these classes, so check it out. -AMT -Original Message- From: Ash .. [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:51 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [collections] Primitive-value maps While waiting for a +1 on the MapUtils.getPrimxxxValue() methods, I have been wondering why the commons collections framework does not have Maps that store and help retrieve primitive values. Stuff like IntMap with put(Object key, int value), etc. I mean, when there are primitive-value collections (lists and sets), why not map? Maybe this was discussed before. In any case, perhaps we can have them. Comments. Ash _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Primitive-value maps
While waiting for a +1 on the MapUtils.getPrimxxxValue() methods, I have been wondering why the commons collections framework does not have Maps that store and help retrieve primitive values. Stuff like IntMap with put(Object key, int value), etc. I mean, when there are primitive-value collections (lists and sets), why not map? Maybe this was discussed before. In any case, perhaps we can have them. Comments. Ash Reposting this, so that if we are decided on the method signatures, I can work on the implementation this weekend. Ash [Stephen] I would only add the full signature version (with default). That way the method name can just be getDouble(). But that would provoke the question "if I want to retrieve a primitive without specifying a default, why should I have to mention a default (even 0) everytime??" I would propose we inlclude both variants (with and sans default), and have a uniform naming for them. Even if we add only the default-taking method today, what if we decide tomorrow that the defaultless one can be useful. And then, I think it is ok if we cannot preserve the same method names. so, I propose the following: public static double getIntValue(Map map, Object key) public static double getIntValue(Map map, Object key, int defaultValue) etc for each prim (and String) Waiting for feedback from others. I can implement these methods after I am done with the subarray(prim[]) ones. This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. But why?? Ash -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. However, now that we have them, I would support having the primitive methods as you propose. I would only add the full signature version (with default). That way the method name can just be getDouble(). Stephen - Original Message ----- From: "Ash .." <[EMAIL PROTECTED]> > I am curious to know why MapUtils does not have getters that return > primitive types. Perhaps there was a discussion on whether it was needed or > not, you could point me to such discussion that took place in the past when > this class was conceived. > In any case, I think that getters that return primitives could be very > useful, much more than those that return wrapper objects. Thus, I think we > could do with methods like: > > MapUtils.getDoubleValue(Map map, Object key [,defaultValue]); > > If the answer to my question is "you can do a MapUtils.getDouble(map, > key).doubleValue() and so on", > I would say, having a built-in method enhances the use of this class than > having a programmer resort to such multiple method call. Of course, the > internal implementation would do the same, but in the end, client code would > look far neater. > > Let me know, > Ash > _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: [collections] MapUtils.getXxx() return types - repost
Reposting this, so that if we are decided on the method signatures, I can work on the implementation this weekend. Ash [Stephen] I would only add the full signature version (with default). That way the method name can just be getDouble(). But that would provoke the question "if I want to retrieve a primitive without specifying a default, why should I have to mention a default (even 0) everytime??" I would propose we inlclude both variants (with and sans default), and have a uniform naming for them. Even if we add only the default-taking method today, what if we decide tomorrow that the defaultless one can be useful. And then, I think it is ok if we cannot preserve the same method names. so, I propose the following: public static double getIntValue(Map map, Object key) public static double getIntValue(Map map, Object key, int defaultValue) etc for each prim (and String) Waiting for feedback from others. I can implement these methods after I am done with the subarray(prim[]) ones. This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. But why?? Ash -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. However, now that we have them, I would support having the primitive methods as you propose. I would only add the full signature version (with default). That way the method name can just be getDouble(). Stephen - Original Message ----- From: "Ash .." <[EMAIL PROTECTED]> > I am curious to know why MapUtils does not have getters that return > primitive types. Perhaps there was a discussion on whether it was needed or > not, you could point me to such discussion that took place in the past when > this class was conceived. > In any case, I think that getters that return primitives could be very > useful, much more than those that return wrapper objects. Thus, I think we > could do with methods like: > > MapUtils.getDoubleValue(Map map, Object key [,defaultValue]); > > If the answer to my question is "you can do a MapUtils.getDouble(map, > key).doubleValue() and so on", > I would say, having a built-in method enhances the use of this class than > having a programmer resort to such multiple method call. Of course, the > internal implementation would do the same, but in the end, client code would > look far neater. > > Let me know, > Ash > _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-er or -or: offshoot from [digester] variable expansion
> > > > We haven't really talked about the terminology for this feature. > > I think it is open for discussion. Good names help in so many ways. > > > > > Yep, all your examples are right to have "-or". > > And also function-->functor. > > > > I'm convinced. Substitutor it is (unless the decision is made > > to rename > > it completely :-) > > > English is strange, isn't it? Substitutor but Expander and Resolver. > > How consistent (not)! > > I was thinking this topic of agent terms (-er -or) was not too relevant to this list, or to any list full of techies. But on second thought, I realize that it would be useful to have an idea of the naming patterns, since we are all coining so many terms every other day. Further, I have often winced at misnaming found in the technical terminology (implementors and adaptors and the like.) I am thus tempted to include here an old article in which I explained then whens and whys of -er and -or. It also has an answer for Simon's musing (on consistency.) Ash Here goes.. -er v/s -or. - Which comes when? What is the pattern? I attempt to answer the questions. -er is the native (Old) English and common Germanic (Dutch, German, etc) suffix for agent (the doer, the nomen agentis). -or is the originally the Latin suffix for the same function. -or is mostly found in latinate words, i.e., words derived from Latin, either as emprunt or constructed in English using Latin elements (roots, prefixes and suffixes.) actor, doctor, investigator, professor, etc. -er is the general suffix for unlatinate words (anything not part of the above definition.) Sometimes, you also find -ar, -eur, and -eer. killer, seller, buyer, Englander, trainer, entertainer, experiencer, etc. There are however some historical "aberrations" to this pattern. wrongly -or: advisor, ... I can't recall the examples now. wrongly -er: motor, but promoter (motion, promotion) The rule for making an -or agent-noun is this: Get the -ion form. Remove -ion and add -or. seduce: seduction -> seductor destroy: destruction -> destructor (used in programming terminology) translate: translation -> translator When there is no acceptable -ion form, use the -er formation. Sometimes, the -er form is preferred, usually when the -ion form is longer, or less attractive (English likes to shorten the words it will use, you see.) adapt: adaptation -> adapter (there is also the exceptional 'adaptor', which is incongruous with the pattern) implement: implementation -> implementer (-or here is incorrect) revolve: revolution -> revolver (rather than revolutor) produce: production -> producer (rather than productor) consume: consumption -> consumer (rather than consumptor, cf. Latin emptor) Ashwin S - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] variable expansion
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
On Wed, 2003-12-03 at 22:59, ASHWIN Suresh wrote:
> Sorry to jump in to this thread this way, and perhaps it is too late
now.
> But, have the people here considered using the term "resolve"
> for this concept?
I don't think it is too late for suggestions like this. Any time before
the release is not too late :-)
Glad abt that!
> Perhaps the interface could be named Resolver, with the method
resolve().
> > I can think of ${foo} > xyz as resolving the definition rather than
simple
> substitution,
> thow at a lower level of abstraction, it is substitution.
The concept of "substitution" is general; expanding/resolving variables
is just one application of the "substitution" feature. Possibly
"substitution" could be called "interception", "filtering",
"pre-processing", "manipulation".
I would go with you. Substitution is more generic, while resolving and
expanding are more specific activities. Then can it be said that the package
ought to be substitution, which contains classes (or perhaps methods within
a class) that do more specific things like resolving and expanding??
Trying to make things more concrete:
Substitution: f(x) > y
Resolution: f(x) > y where,
x is explicitly a resolvabe, indicated by special symbols (escapes): such as
${} and &;.
Expansion: f(x) > y where,
y is "longer" than x, conversely, x can be viewed as a
shorter/contracted/abreviated form of y.
Replacement: f(x) > y
A simple replacement of x by y. (Thow the term substitution itself can carry
this meaning, we "decide" to use that one with a higher/more generic value.)
Pre-processing:
When any kind of manipulation takes place BEFORE any kind of processing!
Sounds simple eh.
Filtering: f(x) > y
Where sometimes x = y, and at other times, x gives a y that is distinct.
The "VarExpander" is implemented using the generic "substitution"
mechanism.
I could go for "VarResolver" if other people like the term. The word
"Resolver"
on its own, however, implies the SAX EntityResolver to me; at least that's
what I would think of first..
There you are. Entities are another set of "resolvables", that get
resolved. So, let's say, we are on track, but here, we are doing variable
resolving.
Note that the string to which "var expansion" (in the current terminology)
is being applied can have multiple variables mixed with literal data. For
example:
"this is a ${var} and so is ${this}"
Is the process of converting this string to its final form "resolving"?
I'm going to sit firmly on the fence on this one :-)
Just getting the equivalent of ${var} is variable resolving. Do you propose
another term for the whole process?
> > If this has been considered and vetoed, please ignore my email.
We haven't really talked about the terminology for this feature.
I think it is open for discussion. Good names help in so many ways.
Name game, am game!
Besides, what did draw my attention too was that I had only recently
implemented some code to "resolve" an ant-like variable to its final value.
> > One more point:
> > > The spelling "substituter" feels more natural to me than > >
"substitutor".
> > > > cf.:
> > to write --> writer
> > to drive --> driver
> > to expand --> expander
> > > For Latinate words, the pattern is usually -or.
> Constructor, translator, delegator, etc.
> Whenever, the agent form is formed out of removal of -ion, the preferred
> suffix is -or.
> Thus, the more appropriate form is substitutor.
> Again, perhaps this was already discussed.
Yep, all your examples are right to have "-or".
And also function-->functor.
I'm convinced. Substitutor it is (unless the decision is made to rename
it completely :-)
Funnily, digester then must be renamed to digestor!
("Now, who's that feisty suggestor?", would you say? ;-))
English is strange, isn't it? Substitutor but Expander and Resolver.
How consistent (not)!
Strange it is. But there are reasons underlying it. Etymology being one of
my passions, I have unearthed some of the reasons, but more on that, another
day, and perhaps on another list.
Ash
_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[collections] general roadmap
Hello, I would like to have a general idea of the go-whither of the collections project. I mean, what are the general objectives of package for the immediate future, when is the next release slated, and such stuff. I did take a peek at the CVS for the docs that explain this, but most seem to be rather old (2-3 months and the like). I would appreciate pointers/more info on this. Thanks, Ash _ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: [collections] MapUtils.getXxx() return types
I would only add the full signature version (with default). That way the method name can just be getDouble(). But that would provoke the question "if I want to retrieve a primitive without specifying a default, why should I have to mention a default (even 0) everytime??" I would propose we inlclude both variants (with and sans default), and have a uniform naming for them. Even if we add only the default-taking method today, what if we decide tomorrow that the defaultless one can be useful. And then, I think it is ok if we cannot preserve the same method names. so, I propose the following: public static double getIntValue(Map map, Object key) public static double getIntValue(Map map, Object key, int defaultValue) etc for each prim (and String) Waiting for feedback from others. I can implement these methods after I am done with the subarray(prim[]) ones. This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. But why?? Ash -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] This is a very old class in [collections] and pre-dates me. I would probably oppose adding these methods now. However, now that we have them, I would support having the primitive methods as you propose. I would only add the full signature version (with default). That way the method name can just be getDouble(). Stephen - Original Message ----- From: "Ash .." <[EMAIL PROTECTED]> > I am curious to know why MapUtils does not have getters that return > primitive types. Perhaps there was a discussion on whether it was needed or > not, you could point me to such discussion that took place in the past when > this class was conceived. > In any case, I think that getters that return primitives could be very > useful, much more than those that return wrapper objects. Thus, I think we > could do with methods like: > > MapUtils.getDoubleValue(Map map, Object key [,defaultValue]); > > If the answer to my question is "you can do a MapUtils.getDouble(map, > key).doubleValue() and so on", > I would say, having a built-in method enhances the use of this class than > having a programmer resort to such multiple method call. Of course, the > internal implementation would do the same, but in the end, client code would > look far neater. > > Let me know, > Ash > _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringUtils.subarray v/s subArray
I think I see the point you are making. If I get you right, it's one of the following: get the sub of the array, or, get the subarray My original idea was to introduce the concept that every array innately has subarrays, and thus the emphasis that an array is being "subbed" I didnt find necessary. Thus subarray(). If people here find that the "subbing" function needs that emphasis, I agree, subArray() is what it should be. Instead, if a subarray is defined as an integral feature of every array, it is subarray(). Comments from others on this would be welcome. And of course, we must strive to achieve a consistent naming standard and stick to it. Hence all this debate. Ash -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 22:37 I was referring to whether we consider the word "array" to be a common part of language, or a specific concept to programming or something like that. I don't really want to get into a whole grammatical debate because I'm not particularly good at grammar. I see a classname as a proper noun. I think it needs that emphasis because it's a model of something, not the real "thing" in the real world. Like, in your example, I would refer to the class as *Person* not *person*, to emphasize that I'm talking about the class, not a real flesh-and-blood person. I like subArray because of that emphasis. An example from the numeric side would be: if such a concept as a "sub-number" existed, which names are preferred: subdouble, sublong, subint OR subDouble, subLong, subInt. I'd choose the latter due to the reasons I've mentioned. I also want to mention that I don't really care that much whether we choose subarray or subArray. What's more important to me is that if we choose a standard with regard to this, that we make our best efforts to stick to it, to avoid the type of ambiguity that Sun has and continues to provide with regard to these types of things. _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringUtils.subarray v/s subArray
It seems to depend on whether we see the word "array" as a proper noun. Could you please elaborate what you meant by that. In my understanding, class names rather represent common nouns, and you can say, specific instances of the class represent proper nouns: Person john = new Person(); Or, am I missing something here? Talking about String.subSequence, if I am right, it was so named because there exists a word called "subsequence" in English, which has no direct bearing with "sub + sequence", thus the emphasis: "sub-sequence". Another example would be re-store (= store again.) Ash -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Sunday, November 30, 2003 20:34 To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.subarray v/s subArray It seems to depend on whether we see the word "array" as a proper noun. java.lang.String has both substring and subSequence. There seem to be inconsistencies everywhere. I vote for subArray, since I would define a classname as being a proper noun. Stephen Colebourne wrote: > I changed this based on subList() in the collections API. substring() is an > alternative precedent, so I am open to opinions. > > Stephen > > - Original Message - > From: "Ash .." <[EMAIL PROTECTED]> > >>Thanks for integrating the subarray implementation patch. >> >>However, I am curious to know why Stephen chose to name the method >>"subArray", in place of >>"subarray". >>In the English language, the prefix "sub" in this sense is joined to the >>word with the resultant word being a single "token": subunit, subclass, >>suburbs, subway... substring, subarray, >>whereby, as per standard Java conventions, the name ought to be "subarray" >>rather than "subArray". >>Even names in Standard API reflect this: substring, etc. >> >>thanks, >>Ashwin _ Set yourself up for fun at home! Get tips on home entertainment equipment, video game reviews, and more here. http://special.msn.com/home/homeent.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] ArrayUtils.subarray() array types
One point I spotted is that the returned array is always an Object[], no matter what the input array type is. This is different to toArray(Object[]) on a List. I'm not sure that its right either. Stephen Do you suggest we implement checking the type of the input array and creating the subarray with the same type, using reflection, like I see, for example in java.util.ArrayList.toArray(Object[]) ? Also, I think we can provide implementations for all the primitive types and String. I would be willing to implement equivalent methods for all these types right away. public static int[] ArrayUtils.subarray(int[] array, int startIndexInclusive, int endIndexExclusive); etc... Ash _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] MapUtils.getXxx() return types
I am curious to know why MapUtils does not have getters that return primitive types. Perhaps there was a discussion on whether it was needed or not, you could point me to such discussion that took place in the past when this class was conceived. In any case, I think that getters that return primitives could be very useful, much more than those that return wrapper objects. Thus, I think we could do with methods like: MapUtils.getDoubleValue(Map map, Object key [,defaultValue]); If the answer to my question is "you can do a MapUtils.getDouble(map, key).doubleValue() and so on", I would say, having a built-in method enhances the use of this class than having a programmer resort to such multiple method call. Of course, the internal implementation would do the same, but in the end, client code would look far neater. Let me know, Ash _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StringUtils.subarray v/s subArray
I see two factors here, one, instances in the the standard Java API, two, mapping of natural language to Java convention. In the first case, we can say there is some incoherence, since you find both "substring" and "subList". Thus, the second one, is perhaps a better guide to making a decision here. Thus, I would say, one might go with how the names translate into Java convention (= subarray.) It would be good to have others' comments on this too. Ashwin - Original Message - I changed this based on subList() in the collections API. substring() is an alternative precedent, so I am open to opinions. Stephen - Original Message - From: "Ash .." <[EMAIL PROTECTED]> Thanks for integrating the subarray implementation patch. However, I am curious to know why Stephen chose to name the method "subArray", in place of "subarray". In the English language, the prefix "sub" in this sense is joined to the word with the resultant word being a single "token": subunit, subclass, suburbs, subway... substring, subarray, whereby, as per standard Java conventions, the name ought to be "subarray" rather than "subArray". Even names in Standard API reflect this: substring, etc. thanks, Ashwin _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang][patch]ArrayUtils.subarray(Object, startIndex, endIndex) implementation v1.1
Here is my submission of the ArrayUtils.subarray() with the changes
suggested
by Stephen.
Eagerly waiting for feedback and more.
Ash
- Original Message -
From: "Stephen Colebourne" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 24, 2003 5:47 AM
Subject: Re: [lang] new functionality in StringUtils and ArrayUtils -
proposal 01
> So many new concepts.;-)
>
> flank/singleQuote/doubleQuote/enclose
> This has some potential as a StringUtils addition. Perhaps just focussing
on
> the enclose method name, with
> enclose(str, encloseWith)
> enclose(str, before, after)
> Similar to string appending though so is it justified?
>
> lead/trail
> Very little gain over string appending - just null checking. But then
thats
> what StringUtils often is. These two could become one though:
> concat(str1, str2)
>
> ArrayUtils.toString with alternate delimiter
> I can't see the use case for this, and if it exists then ToStringBuilder
> already handles it.
>
> ArrayUtils.toString(Object arr, int startIndex, int endIndex)
> Possible, but how often is this needed?
>
> ArrayUtils.subarray(arr, startIndex, endIndex)
> Looks good +1. Just need to determine whether the end points are inclusive
> or exclusive (suggest copying List API)
>
>
> To proceded with ArrayUtils.subarray (gets you started), submit a CVS
patch
> against the latest CVS with the new addition and suitable tests.
>
> Stephen
>
>
> From: "Ash .." <[EMAIL PROTECTED]>
> > /**
> > * Flanks the given string with the flank String or char.
> > *
> > * StringUtils.flank(null, *) = null
> > * StringUtils.flank("", *)= *
> > * StringUtils.flank("abc", null) = abc
> > * StringUtils.flank("abc", "x") = xabcx
> > * StringUtils.flank("abc", "xy") = xyabcxy // xy...xy
> > *
> > */
> > StringUtils.flank(String flankee, String flank)
> > StringUtils.flank(String flankee, char flank)
> >
> >
> > Some special cases of flanking are quotes.
> >
> > /**
> >*
> >* StringUtils.singleQuote("Now is the time...") = 'Now is the
time...'
> >*
> >*/
> > StringUtils.singleQuote(String quotee)
> >
> > /**
> >*
> >* StringUtils.doubleQuote("Now is the time...") = "Now is the
time..."
> >*
> >*/
> > StringUtils.doubleQuote(String quotee)
> >
> >
> >
> > /**
> >* Enclose the string with a pair of symmetrical characters
> >* given one of the pair. Such pairs are
> >*
> >*
> >* (), {}, [], <>,
> >*
> >*
> >* When the encloser is not from a recognized pair,
> >* the method resorts to flank-like appending, with the order
> >* for the afterpart reversed.
> >*
> >*
> >* StringUtils.enclose("abc", "[")= "[abc]"
> >* StringUtils.enclose("abc", "[[") = "[[abc]]"
> >* StringUtils.enclose("abc", "x")= xabcx
> >* StringUtils.enclose("abc", "xy") = xyabcyx // xy..yx
> >*
> >*
> >* @param enclosee the String to be enclosed
> >* @param either of such pairs of strings as given above
> >*/
> > StringUtils.enclose(String enclosee, String encloser)
> >
> >
> >
> > /**
> >*
> >* StringUtils.lead("abc", "zz") = "zzabc"
> >*
> >*/
> > StringUtils.lead(String leadee, String leadStr)
> > StringUtils.lead(String leadee, String leadChar)
> >
> > /**
> >*
> >* StringUtils.lead("abc", '.', 3) = "abc..."
> >*/
> > StringUtils.lead(String leadee, char leadStr, int repeatCount)
> > StringUtils.lead(String leadee, String leadStr, int repeatCount)
> >
> > /**
> >*
> >* StringUtils.trail("abc", "zz") = "abczz"
> >*
> >*/
> > StringUtils.trail(String trailee, String trailStr)
> > StringUtils.trail(String trailee, char trailChar)
> > StringUtils.trail(String trailee, String trailStr, int repeatCount)
> > StringUtils.trail(String trailee, char trailChar, int repeatCount)
> >
> >
> >
> > /**
> >* The concept of
RE: [lang][PATCH] ArrayUtil.subarray(Object, startIndex, endIndex) implementatio
Some comments: 1) You should try to match the style of the surrounding code. For your submission this means spaces after if and for, brackets around the if statements, and brackets at the end of lines. In many cases I just use eclipse to reformat new code, but the missing if statement brackets would require manual intervention. [Ash] I did try to match the formatting, but some of the differences in the format seemed to have simply missed me. I'll ensure 100% conformance next submission onwards. 2) The array copy should be done using System.arraycopy, unless you can demonstrate the this is faster. [Ash] I can't. So, will use System.arraycopy() 3) The edge case of startIndex == endIndex is not handled to return EMPTY_OBJECT_ARRAY [Ash] I left this as a consequence of the final algorithm. I will treat it as a special case and insert the check. 4) The parameter names would be better as startIndexInclusive and endIndexExclusive. [Ash] In my understanding, when something spans two indexes, typically, the start index is inclusive and the end index exclusive. Examples in standard Java API are String.substring() and Arrays.sort(). I would thus propose that the param names be startIndex and endIndex with the javadoc clearly specifying the ?clusiveness. 5) The startIndex comment is innacurate re overvalue [Ash] In fact, it's downright wrong! Mea culpa. 6) I think that the startIndex to 0 and endIndex to end tests should probably go before the EMPTY tests. OK. 7) The submission was via a whole file, rather than a patch. See http://jakarta.apache.org/commons/patches.html [Ash] Sorry for my ignorance about patches. Will get it ready soon. 8) Tests look good, although I would like to see some assertSame(EMPTY_OBJECT_ARRAY, ...) to test that the constant is returned in the relevant cases. [Ash] OK. This seems like a long list, but hopefully you will learn some of our ways through it. Please submit a patch either to the list or bugzilla if you can ;-) [Ash] I am learn-willing :-) Will submit the patch as soon as I can. Thanks, Ashwin Stephen - Original Message - From: "Ash" <[EMAIL PROTECTED]> PFE a first implementation of the proposed ArrayUtil.subarray()implemented to take an Object array. Also encl some basic testcases. This is my first contribution, so I might take a while to get used to the some of the procedures of the group. Waiting for feedback and criticism. Thanks, Ashwin _ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang][PATCH] ArrayUtil.subarray(Object, startIndex, endIndex) implementation v 1.0
PFE a first implementation of the proposed ArrayUtil.subarray()implemented to take an Object array. Also encl some basic testcases. This is my first contribution, so I might take a while to get used to the some of the procedures of the group. Waiting for feedback and criticism. Thanks, Ashwin ArrayUtil.subarrayObject.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new functionality in StringUtils and ArrayUtils - proposal 01
All the concepts (flank, enclose, single quote, double quote) are rather trivial, or, let's say, they're simple append functions. However, they still do represent special cases of appending, and albeit simple, may merit inclusion to the StringUtils class considering that the class is largely a compendium of similar simple functions: If you can chomp a String, you can even flank it? > flank/singleQuote/doubleQuote/enclose > This has some potential as a StringUtils addition. Perhaps just focussing on > the enclose method name, with > enclose(str, encloseWith) > enclose(str, before, after) > Similar to string appending though so is it justified? > lead/trail > Very little gain over string appending - just null checking. But then thats > what StringUtils often is. These two could become one though: > concat(str1, str2) But lead and trail represent specific semantics, concat would do, but it's different semantically, isn't it? > ArrayUtils.toString with alternate delimiter > I can't see the use case for this, and if it exists then ToStringBuilder > already handles it. This is from an array user's perspective. A coder who simply wanted to print an array and go on with his code would say "why should I do a StringBuilder, I just want a direct toString(arr, ",\n\t"), that's it!" Of course, this could be a simple delegation to a StringBuilder implementation, but if an array-oriented view can be justified, it can perhaps be said that there is a use for this. > ArrayUtils.toString(Object arr, int startIndex, int endIndex) > Possible, but how often is this needed? One could use the subarray along with the existing toString. Feedback from others might throw more light on its need. > ArrayUtils.subarray(arr, startIndex, endIndex) > Looks good +1. Just need to determine whether the end points are inclusive > or exclusive (suggest copying List API) The String.substring(startIndex, endIndex) can be suggested to be a good model to emulate, for the inclusiveness aspect. > > To proceded with ArrayUtils.subarray (gets you started), submit a CVS patch > against the latest CVS with the new addition and suitable tests. > I'll send this across presently. Ash - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] new functionality in StringUtils and ArrayUtils - proposal 01 - error
In my previous email,
/**
*
* StringUtils.lead("abc", '.', 3) = "abc..."
*/
This should be:
/**
*
* StringUtils.trail("abc", '.', 3) = "abc..."
*/
From: "Ash .." <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi,
I would like to propose the following methods to the StringUtils and
ArrayUtils classes.
They are just minor additions to the existing functionality, but I thought
would be interesting,
hopefully quite useful too.
Waiting for feedback and looking forward to some development in this
regard.
I would be glad to submit an implementation to the concerned people, if you
feel this functionality
is include-worthy.
Thanks,
Ash
/**
* Flanks the given string with the flank String or char.
*
* StringUtils.flank(null, *) = null
* StringUtils.flank("", *)= *
* StringUtils.flank("abc", null) = abc
* StringUtils.flank("abc", "x") = xabcx
* StringUtils.flank("abc", "xy") = xyabcxy // xy...xy
*
*/
StringUtils.flank(String flankee, String flank)
StringUtils.flank(String flankee, char flank)
Some special cases of flanking are quotes.
/**
*
* StringUtils.singleQuote("Now is the time...") = 'Now is the time...'
*
*/
StringUtils.singleQuote(String quotee)
/**
*
* StringUtils.doubleQuote("Now is the time...") = "Now is the time..."
*
*/
StringUtils.doubleQuote(String quotee)
/**
* Enclose the string with a pair of symmetrical characters
* given one of the pair. Such pairs are
*
*
* (), {}, [], <>,
*
*
* When the encloser is not from a recognized pair,
* the method resorts to flank-like appending, with the order
* for the afterpart reversed.
*
*
* StringUtils.enclose("abc", "[")= "[abc]"
* StringUtils.enclose("abc", "[[") = "[[abc]]"
* StringUtils.enclose("abc", "x")= xabcx
* StringUtils.enclose("abc", "xy") = xyabcyx // xy..yx
*
*
* @param enclosee the String to be enclosed
* @param either of such pairs of strings as given above
*/
StringUtils.enclose(String enclosee, String encloser)
/**
*
* StringUtils.lead("abc", "zz") = "zzabc"
*
*/
StringUtils.lead(String leadee, String leadStr)
StringUtils.lead(String leadee, String leadChar)
/**
*
* StringUtils.lead("abc", '.', 3) = "abc..."
*/
StringUtils.lead(String leadee, char leadStr, int repeatCount)
StringUtils.lead(String leadee, String leadStr, int repeatCount)
/**
*
* StringUtils.trail("abc", "zz") = "abczz"
*
*/
StringUtils.trail(String trailee, String trailStr)
StringUtils.trail(String trailee, char trailChar)
StringUtils.trail(String trailee, String trailStr, int repeatCount)
StringUtils.trail(String trailee, char trailChar, int repeatCount)
/**
* The concept of naught.
* True if the String is null or "null".
*
* StringUtils.isNaught("abc") = false
* StringUtils.isNaught(null) = true
* StringUtils.isNaught("null") = true
*
*/
StringUtils.isNaught(String str)
// ArrayUtils methods
/**
* Similar to the existing toString but
* using delimiter given.
*/
ArrayUtils.toString(Object array, String delimiter)
ArrayUtils.toString(Object array, char delimiter)
/**
* A toString that emits only a given part
* of the array.
*/
ArrayUtils.toString(Object arr, int startIndex, int endIndex)
/**
* Obtain a new array of the given size, with the elements
* present between startIndex (inclusive) and endIndex (exclusive).
*/
ArrayUtils.subarray(arr, startIndex, endIndex)
---
The concept of a "naught" String.
A String is naught if it is either 'null' or is the literal "null".
I have often encountered this situation in my JSP project where a
particular
parameter is passed in
as x=null, and I need to insert code everytime saying if(x == null ||
x.equals("null"))
_
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] new functionality in StringUtils and ArrayUtils - proposal 01
Hi,
I would like to propose the following methods to the StringUtils and
ArrayUtils classes.
They are just minor additions to the existing functionality, but I thought
would be interesting,
hopefully quite useful too.
Waiting for feedback and looking forward to some development in this regard.
I would be glad to submit an implementation to the concerned people, if you
feel this functionality
is include-worthy.
Thanks,
Ash
/**
* Flanks the given string with the flank String or char.
*
* StringUtils.flank(null, *) = null
* StringUtils.flank("", *)= *
* StringUtils.flank("abc", null) = abc
* StringUtils.flank("abc", "x") = xabcx
* StringUtils.flank("abc", "xy") = xyabcxy // xy...xy
*
*/
StringUtils.flank(String flankee, String flank)
StringUtils.flank(String flankee, char flank)
Some special cases of flanking are quotes.
/**
*
* StringUtils.singleQuote("Now is the time...") = 'Now is the time...'
*
*/
StringUtils.singleQuote(String quotee)
/**
*
* StringUtils.doubleQuote("Now is the time...") = "Now is the time..."
*
*/
StringUtils.doubleQuote(String quotee)
/**
* Enclose the string with a pair of symmetrical characters
* given one of the pair. Such pairs are
*
*
* (), {}, [], <>,
*
*
* When the encloser is not from a recognized pair,
* the method resorts to flank-like appending, with the order
* for the afterpart reversed.
*
*
* StringUtils.enclose("abc", "[")= "[abc]"
* StringUtils.enclose("abc", "[[") = "[[abc]]"
* StringUtils.enclose("abc", "x")= xabcx
* StringUtils.enclose("abc", "xy") = xyabcyx // xy..yx
*
*
* @param enclosee the String to be enclosed
* @param either of such pairs of strings as given above
*/
StringUtils.enclose(String enclosee, String encloser)
/**
*
* StringUtils.lead("abc", "zz") = "zzabc"
*
*/
StringUtils.lead(String leadee, String leadStr)
StringUtils.lead(String leadee, String leadChar)
/**
*
* StringUtils.lead("abc", '.', 3) = "abc..."
*/
StringUtils.lead(String leadee, char leadStr, int repeatCount)
StringUtils.lead(String leadee, String leadStr, int repeatCount)
/**
*
* StringUtils.trail("abc", "zz") = "abczz"
*
*/
StringUtils.trail(String trailee, String trailStr)
StringUtils.trail(String trailee, char trailChar)
StringUtils.trail(String trailee, String trailStr, int repeatCount)
StringUtils.trail(String trailee, char trailChar, int repeatCount)
/**
* The concept of naught.
* True if the String is null or "null".
*
* StringUtils.isNaught("abc") = false
* StringUtils.isNaught(null) = true
* StringUtils.isNaught("null") = true
*
*/
StringUtils.isNaught(String str)
// ArrayUtils methods
/**
* Similar to the existing toString but
* using delimiter given.
*/
ArrayUtils.toString(Object array, String delimiter)
ArrayUtils.toString(Object array, char delimiter)
/**
* A toString that emits only a given part
* of the array.
*/
ArrayUtils.toString(Object arr, int startIndex, int endIndex)
/**
* Obtain a new array of the given size, with the elements
* present between startIndex (inclusive) and endIndex (exclusive).
*/
ArrayUtils.subarray(arr, startIndex, endIndex)
---
The concept of a "naught" String.
A String is naught if it is either 'null' or is the literal "null".
I have often encountered this situation in my JSP project where a
particular
parameter is passed in
as x=null, and I need to insert code everytime saying if(x == null ||
x.equals("null"))
_
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
re: new functionality in some of the commons classes - contd
Hi,
I got no reply for my second email. (Or did I miss any.)
Much of the ideas I have here are about minor functionality in some of the
basic classes (such as lang.StringUtils etc). I would be glad to know how to
go about it. I mentioned one as an example, perhaps it would be preferred if
I mention all of them at one go? Since I am new to this group, I am not very
familiar with your preferred way. Curious to know.
Cheers,
Ash
Hello again,
Adding to my earlier email I just sent out, I wish to give an example here,
of some of the ideas I have.
The concept of a "naught" String.
A String is naught if it is either 'null' or is the literal "null".
I have often encountered this situation in my JSP project where a particular
parameter is passed in
as x=null, and I need to insert code everytime saying if(x == null ||
x.equals("null"))
Perhaps others have encountered a similar situation. I thus propose the
following functionality in the
org.apache.commons.lang.StringUtils class:
StringUtils.isNaught(String str)
And more such to go. Waiting for some feedback.
Thanks,
Ash
-Original Message-
From: ASHWIN Suresh
Sent: Saturday, November 22, 2003 20:47
To: 'Jakarta Commons Developers List'
Subject: new functionality in some of the commons classes
Hello all,
I am new to the list, and am here after my recent (and really exciting)
discovery of the existence of this whole treasure of day-to-day usage
code in the name of the Commons project.
I would like to propose/contribute some new functionality to some
of the classes (mostly simple stuff). Do let me know the procedure
for this. If there is a standard document which explains this,
which I missed, please give me a pointer to it.
Thanks,
_
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
new functionality in some of the commons classes - contd
Hello again,
Adding to my earlier email I just sent out, I wish to give an example here,
of some of the ideas I have.
The concept of a "naught" String.
A String is naught if it is either 'null' or is the literal "null".
I have often encountered this situation in my JSP project where a particular
parameter is passed in
as x=null, and I need to insert code everytime saying if(x == null ||
x.equals("null"))
Perhaps others have encountered a similar situation. I thus propose the
following functionality in the
org.apache.commons.lang.StringUtils class:
StringUtils.isNaught(String str)
And more such to go. Waiting for some feedback.
Thanks,
Ash
-Original Message-
From: ASHWIN Suresh
Sent: Saturday, November 22, 2003 20:47
To: 'Jakarta Commons Developers List'
Subject: new functionality in some of the commons classes
Hello all,
I am new to the list, and am here after my recent (and really exciting)
discovery of the existence of this whole treasure of day-to-day usage
code in the name of the Commons project.
I would like to propose/contribute some new functionality to some
of the classes (mostly simple stuff). Do let me know the procedure
for this. If there is a standard document which explains this,
which I missed, please give me a pointer to it.
Thanks,
Keep up the good work,
Ash
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
