 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2008what is the use of capacity method in StringBuffer
Friends, What's use of capacity() method in StringBuffer Object or Why do we need it? ... > What's .. What's with the *huge* indentation? On usenet, it is generally better to not indent the first line, but instead leave a blank line between paragraphs. >..use of capacity() method in StringBuffer Object > or > Why do we need it? (Peers into 'crystal ball'*) "Every string buffer has a capacity. As long as the length of the character sequence contained in the string buffer does not exceed the capacity, it is not necessary to allocate a new internal buffer array. If the internal buffer overflows, it is automatically made larger." * AKA 'The JavaDocs'. -- Andrew T. PhySci.org >>..use of capacity() method in StringBuffer Object >> or Why do we need it? > "Every string buffer has a capacity. As > long as the length of the character sequence [quoted text clipped - 3 lines] > If the internal buffer overflows, it is > automatically made larger." While entirely true, it doesn't explain, why any programmer would ever use it. My view on that is, that if you, as a programmer, know, that some following chunk of code will gradually add up to 10 Megs of chars to the stringbuffer, you have the option of allocating those 10 megs in one go, rather than have the internal heuristics do that piecewise. In other words, it's never strictly necessary to explicitly specify the capacity of a stringbuffer, but in some cases, it will improve performance, if you do so, appropriately. On Wed, 16 Jan 2008 07:03:46 -0800 (PST), Sreenivas <thatiparthysreenivas@gmail.com> wrote, quoted or indirectly quoted someone who said : >Friends, > What's use of capacity() method in StringBuffer Object >or >Why do we need it? You can use it to see if your StringBuffer will be able to absorb X more characters without having to reallocate internally. Ideally you should allocate your StringBuffer/StringBuilder the exact correct size so as not to waste space or trigger time-consuming expansions.  SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com > On Wed, 16 Jan 2008 07:03:46 -0800 (PST), Sreenivas >> What's use of capacity() method in StringBuffer Object > ... <off-topic peeve> I have always wondered why Sun never fixed the broken names of these methods. I understand about backward compatibility, but is that any reason not to add "getCapacity and setCapacity and then mark "capacity" and 'ensureCapcity" as deprecated (or not?) Many of the methods in Java that violate naming standards could be fixed without creating any problems, making the language easier to learn. (Remember when Color constants were in lower case? Now they're also in uppercase, as the naming standard requires and nothing was broken by the addition.) Another method that needs fixing is System.arraycopy, which should be System.arrayCopy. (Maybe we should start a list and then create a JSR to fix 'em all. :-) </off-topic peeve> -Wayne >is that any reason not to add "getCapacity and setCapacity and >[...]Many of the methods in Java that violate naming standards If you intent to say that »capacity« violates a naming standard, could you give a reference to the naming standard for Java that is violated by this? >> is that any reason not to add "getCapacity and setCapacity and >> [...]Many of the methods in Java that violate naming standards > > If you intent to say that »capacity« violates a naming standard, > could you give a reference to the naming standard for Java that > is violated by this? The javabean (JavaBean?) standard of course. The capacity of a StringBuffer/StringBuilder (and similar objects) should be accessible by the standard getX/isX and setX naming standard. While nearly all of Java adheres to this standard there is the occasional oddball method name that students must memorize as exceptions to the naming rules. See also http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 For additional naming standards. -Wayne >>If you intent to say that »capacity« violates a naming >>standard, could you give a reference to the naming standard >>for Java that is violated by this? >The javabean (JavaBean?) standard of course. This does not apply to Java, but only to Java Beans and properties. >While nearly all of Java adheres to this >standard there is the occasional oddball method name that >students must memorize as exceptions to the naming rules. I am not aware that nearly all of Java adheres to the Java Beans property naming convention. It is natural to name a method that returns a value by that value. For example, java.lang.Math.sin(double) returns a »sine«, so it is named »sin«, not »getSine«. (OK, this is not a property, but it returns a value.) Not using »get« also is more »fluent« (natural-language like). Recently, more people start to prefer fluent notations in order to enhance readability. if( buffer.size() > 0 ) ~ »If the buffer size is greater the zero.« if( buffer.getSize() > 0 ) ~ ? >if( buffer.getSize() > 0 ) ~ ? In natural language, there is a fundamental distinction between verb phrases and noun phrases corresponding to the distinction between methods that have an effect and methods that return a value in programming.¹ A natural naming scheme is to name a value method by its value (noun) and an effect method by its effect (verb).² With this in mind, on might criticize »getSize« because it misleadingly makes a value method look like an effect method. Also it is misleading, because its wording indicates the wrong direction: »object.getSize()« would command an object to get a size - but instead by the Beans convention it is intended to command the object to /give/ (»return«) the value of the size property. Remarks: 1) There also are mixed methods that return a value and also have an effect, which I ignore for simplicity. 2) This suggestion might not agree with Java Code Conventions, which suggests to always use a verb. But this is not respected by Sun itself. >> is that any reason not to add "getCapacity and setCapacity and >> [...]Many of the methods in Java that violate naming standards > > If you intent to say that »capacity« violates a naming standard, > could you give a reference to the naming standard for Java that > is violated by this? The Sun Java coding standards specify that a method should be named as a verb. "capacity" is not a verb, where as {get,set}Capacity is (verb phrase, actually, but that's beside the point). SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth >The Sun Java coding standards specify that a method should be >named as a verb. "capacity" is not a verb, where as >{get,set}Capacity is (verb phrase, actually, but that's beside >the point). Yes. This is correct. But I don't know a single person (including Sun) adhering to this recommendation. In this case, the recommendation is wrong and the code of practice is right. The right rule was given by Rob Pike in 1989: »Procedure names should reflect what they do; function names should reflect what they return.« http://www.lysator.liu.se/c/pikestyle.html »Procedure« and »function« in Java, of course, are methods that have an effect and methods that return a value, respectively. (I ignore other methods here, for simplicity.) And »what they do«, of course, means a verb phrase, while »what they return« means a noun phrase. Pike simple states deep structure rules of any language one can not ignore without being penalized. Supersedes: <naming-20080117010038@ram.dialup.fu-berlin.de> >The Sun Java coding standards specify that a method should be >named as a verb. "capacity" is not a verb, where as >{get,set}Capacity is (verb phrase, actually, but that's beside >the point). Yes. This is correct. But I don't know a single person (including Sun) adhering to this recommendation. In this case, the recommendation is wrong and the code of practice is right. The right rule was given by Rob Pike in 1989: »Procedure names should reflect what they do; function names should reflect what they return.« http://www.lysator.liu.se/c/pikestyle.html »Procedure« and »function« in Java, of course, are methods that have an effect and methods that return a value, respectively. (I ignore other methods here, for simplicity.) And »what they do«, of course, means a verb phrase, while »what they return« means a noun phrase. Pike simple states deep structure rules of any language beyond which we cannot trespass with impunity. >> On Wed, 16 Jan 2008 07:03:46 -0800 (PST), Sreenivas >>> What's use of capacity() method in StringBuffer Object [quoted text clipped - 16 lines] > create a JSR to fix 'em all. :-) > </off-topic peeve> Not speaking for Sun and in any case not privy to the debates among the people who dreamed up the names, I can't see that adding a get... prefix to half the methods in Creation does a whole lot of good. (Well, it provides some informal capacity testing for browsers when they load the G or S Javadoc index frames ;-) Really, now: Is System.getCurrentTimeMillis() an improvement on an already bletcherous name? Would renaming Number's methods to getIntValue() and getDoubleValue() and so on make life easier for anyone? Would Iterator be better if its methods were getNext() and isAbleToGetNext()? Beauty is in the eye of the beholder, but my eye at least finds no beauty in such names. "A foolish consistency is the hobgoblin of little minds, Adored by little statesmen and philosophers and divines." -- Ralph Waldo Emerson SignatureEric.Sosman@sun.com >>> On Wed, 16 Jan 2008 07:03:46 -0800 (PST), Sreenivas >>>> What's use of capacity() method in StringBuffer Object [quoted text clipped - 33 lines] > Adored by little statesmen and philosophers and divines." > -- Ralph Waldo Emerson Well I did state it was a pet peeve and I'll let the next poster have the last word, but I want to point out that only methods which return/change the value of a property of an object are supposed to follow this naming scheme, not all non-void methods (as I think some people think I think, which I don't. :-) -Wayne >have the last word, but I want to point out that only >methods which return/change the value of a property of an >object are supposed to follow this naming scheme, not all >non-void methods (as I think some people think I think, According to the JLS, the properties of a named entity are are the /accessibility/ or whether a named method is »synchronized« or so. Beyond that, objects do not have »properties« by the JLS. Beans might have properties - but that is another specification, which does not apply to Java in general. >> have the last word, but I want to point out that only >> methods which return/change the value of a property of an [quoted text clipped - 9 lines] > Beans might have properties - but that is another > specification, which does not apply to Java in general. The thing about style guides is that they are about style, and they merely guide. If style were universal there would be no one on Mr. Blackwell's 10-worst-dressed list. <http://en.wikipedia.org/wiki/Mr._Blackwell> SignatureLew >> On Wed, 16 Jan 2008 07:03:46 -0800 (PST), Sreenivas >>> What's use of capacity() method in StringBuffer Object [quoted text clipped - 6 lines] > is that any reason not to add "getCapacity and setCapacity and > then mark "capacity" and 'ensureCapcity" as deprecated (or not?) What I would like to Sun really fix is the removal of some deprecated versions and stuff them in a compatibility-JAR somewhere. At some point, I think that the library needs to wipe away a large amount of cruft that came about because of poor decisions and say "to hell with backwards compatibility." Autoconf did this, PHP did this, Microsoft did this, even C++ did this (okay, the latter's changes were minutiae, but still...). SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth >getCapacity and setCapacity a Getters and setters are ugly. They should have been fixed long ago borrowing from Delphi or Eiffel. I have a proposal to fix the problem in the Bali language - reformed Java. See http://mindprod.com/bali.html#PROPERTIES Instead of writing: x.setHeight( x.getHeight() + 1 ); you would write: x.height++; Getters and setters look syntatically to the outside world just like public variables. Whether they are implemented as getter/setter or public variables is an internal matter for the class. Of course they generate slightly different byte code. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com >> getCapacity and setCapacity a > [quoted text clipped - 14 lines] > public variables is an internal matter for the class. Of course they > generate slightly different byte code. That is what C# does. But I am not that fond of the change. Because it is still a method call. Which can be very confusing if the method does something besides the standard. And if you say that it should follow conventions, then I can not see the point in replacing something by convention (get & set) with syntax (property) that has to follow convention. Arne >Which can be very confusing if the method does something besides >the standard. It in none of the client's business if there are additional checks. The class should be able to add checks or remove them without changing the contract interface to the outside world. Further it saves writing dummy setters and getters on the off change you might later add checks. You don't need to write code unless you are actually doing a special check. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com On Thu, 17 Jan 2008 00:52:15 GMT, Roedy Green <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted someone who said : >Getters and setters look syntatically to the outside world just like >public variables. Whether they are implemented as getter/setter or >public variables is an internal matter for the class. Of course they >generate slightly different byte code. Getters and setters, as they are now, reek of kludge. I imagine the guy who invented them has an office full of mouldy pizza boxes and old Styrofoam coffee cups. This is one reason I want more female programmers. I would hope they would balk at such bailing wire. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com > On Thu, 17 Jan 2008 00:52:15 GMT, Roedy Green > <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted [quoted text clipped - 9 lines] > Styrofoam coffee cups. This is one reason I want more female > programmers. I would hope they would balk at such bailing wire. What do you recommend that we use in their place? >> Getters and setters, as they are now, reek of kludge. >> [snip] > > What do you recommend that we use in their place? Like Roedy proposed. Public attributes. Augmented to be "Properties" or "managed attributes". Python (I feel a little guilty for bringing it up constantly) has them and they're great. /W On Thu, 17 Jan 2008 15:41:48 -0500, "Charles Hottel" <chottel@earthlink.net> wrote, quoted or indirectly quoted someone who said : >What do you recommend that we use in their place? I want the language changed, to behave something like C#, Eiffel or Delphi. My proposal is in my Bali document. See http://mindprod.com/jgloss/bali.html For now, there is no alternative. SignatureRoedy Green, Canadian Mind Products The Java Glossary, http://mindprod.com > On Thu, 17 Jan 2008 15:41:48 -0500, "Charles Hottel" > <chottel@earthlink.net> wrote, quoted or indirectly quoted someone who [quoted text clipped - 6 lines] > > See http://mindprod.com/jgloss/bali.html I like quite a few of those ideas. Was this written before Java 5.0 acquired "enum"? > On Thu, 17 Jan 2008 15:41:48 -0500, "Charles Hottel" > <chottel@earthlink.net> wrote, quoted or indirectly quoted someone who [quoted text clipped - 8 lines] > > For now, there is no alternative. The Powers That Be must be reading your site; many of your suggestions (enums, assertions, for-each loops, ...) have now been included in Java. Maybe you should update this document with new "wish list" items, you never know! -Wayne >> On Thu, 17 Jan 2008 15:41:48 -0500, "Charles Hottel" >> <chottel@earthlink.net> wrote, quoted or indirectly quoted someone who [quoted text clipped - 13 lines] > have now been included in Java. Maybe you should update > this document with new "wish list" items, you never know! "Now"? Assertions were added in 2002 (and in beta in 2001), enums and for-each in 2004, back when autoboxing, varargs, generics and the corrected memory model were brought in. The other features of Bali make it an interesting language to target for the JVM. One nit - the bali site mentions <http://mindprod.com/jgloss/bali.html#MODULUS> > Java’s modulus [sic] operator. Java does not have a modulo operator, as Roedy points out elsewhere on mindprod. He also points out that "modulus" is an informal name, which it truly is. <http://en.wikipedia.org/wiki/Modulo_operation> discusses the matters involved in implementing modulo vs. remainder operations, and has a chart showing how various languages treat the issue of signed operands. SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.