S
Sreenivas
Friends,
What's use of capacity() method in StringBuffer Object
or
Why do we need it?
What's use of capacity() method in StringBuffer Object
or
Why do we need it?
A
Andrew Thompson
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.
(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'.
A
Andreas Leitgeb
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.
R
Roedy Green
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.
W
Wayne
<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
S
Stefan Ram
Wayne said:
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?
W
Wayne
Stefan said:
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
S
Stefan Ram
Wayne said:
This does not apply to Java, but only to Java Beans
and properties.
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 ) ~ ?
S
Stefan Ram
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.
E
Eric Sosman
Wayne said:<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>
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
W
Wayne
Eric said:
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
J
Joshua Cranmer
Stefan said:
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).
J
Joshua Cranmer
Wayne said:
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...).
S
Stefan Ram
Joshua Cranmer said:
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.
S
Stefan Ram
Supersedes: <[email protected]>
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.
Joshua Cranmer said:
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.
R
Roedy Green
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.
A
Arne Vajhøj
Roedy said:
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
R
Roedy Green
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.
R
Roedy Green
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.
S
Stefan Ram
Wayne said:
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.