How do I create a String class from scratch?
This is more of an academic exercise.
Suppose the String class in Java did not exist. How would you go about creating one?
My first thought would be to create arrays of characters to represent words, but then, how would I input those characters into my "StringClassWrittenFromScratch " class?
StringClassWrittenFromScratch sc =new StringClassWrittenFromScratch ("Hello World!");
Ok, but the words Hello World!, enclosed by a left and a right double quote, constitude a String, so my StringClassWrittenFromScratch class would just take a String as a parameter. How would I go about creating a String class without the use of these existing syntactical constructions?
> This is more of an academic exercise.
>
> Suppose the String class in Java did not exist. How
> would you go about creating one?
>
> My first thought would be to create arrays of
> characters to represent words, but then, how would I
> input those characters into my
> "StringClassWrittenFromScratch " class?
>
> StringClassWrittenFromScratch sc = new
> StringClassWrittenFromScratch ("Hello
> World!");
You can't, because the Java language defines that "blah" has a special meaning that is related specifically to the java.lang.String class.
> How would I go about creating
> a String class without the use of these existing
> syntactical constructions?
You can't because it's the language definition that binds that syntax to the existing String class. Your code doesn't get to alter the language, only to add new classes.
That's interesting. thanks.
> Suppose the String class in Java did not exist. How
> would you go about creating one?
Look at the sources.
> My first thought would be to create arrays of
> characters to represent words, but then, how would I
> input those characters into my
> "StringClassWrittenFromScratch " class?
As an array of chars...
> You can't, because the Java language defines that
> "blah" has a special meaning that is related
> specifically to the java.lang.String class.
Well, it defines that String literals are compiled to have matching String instances created. I wouldn't say it's really that "special". Same's troe for all kinds of numbers and booleans. And StringBuffer (+ operator).
Is there a way to measure specialness? ;o)
> You can't because it's the language definition that
> binds that syntax to the existing String class.
But he could write a pseudo-string class with a c'tor that accepts a String, or a char array.
I'd say it's pretty special when the compiler knows what class a string literal is compiled into, and what its constructors are, and what methods can be called on it ...
ejpa at 2007-7-9 6:25:00 >
> I'd say it's pretty special when the compiler knows
> what class a string literal is compiled into,
But that's also true for boolean, Boolean, int, Integer, double, Double, long, Long, float, Float, byte, Byte, char, Character, and StringBuffer, too. I agree it's sort of special, but not as special as the term implies (to me it sounds like unique).
> and
> what its constructors are, and what methods can be
> called on it ...
I think the compiler knows that about *every* class. Otherwise, it'll complain about missing code. You should know... ;)
It's special in that it knows how to interpret double-quote marks, and that quotes have a special meaning that maps directly to String objects.As opposed, say, to java.awt.FlowLayout.
> It's special in that it knows how to interpret
> double-quote marks, and that quotes have a special
> meaning that maps directly to String objects.
>
> As opposed, say, to java.awt.FlowLayout.
But not opposed to all the other stuff I just listed, which isn't really few.
I guess it's just that I'm tired of hearing "String is special this, String is special that". It's final? It's immutable? Both should rather be the norm for classes if possible, not the exception. It's not as special as people sometimes claim it to be...
> But that's also true for boolean, Boolean, int,
> Integer, double, Double, long, Long, float, Float,
> byte, Byte, char, Character, and StringBuffer, too. I
> agree it's sort of special, but not as special as the
> term implies (to me it sounds like unique).
I agree, they are special too. None of them is unique now, but until autoboxing came along String was unique AFAIK.
> I think the compiler knows that about *every* class.
> Otherwise, it'll complain about missing code. You
> should know... ;)
Yes, I do know, and yes the compiler knows about every class for typechecking purposes via introspection or simultaneous compilation.
What we are talking about here is the compiler generating code to call constructors and methods that it already knows exist.
This is obviously a separate, 'special' mechanism. Unless you can suggest how a compiler could use introspection or simultaneous compilation to decide that a quoted literal could be compiled as a String via a particular constructor of java.lang.String and concatenated via a particular method of java.lang.StringBuffer and converted back to a string via another method of StringBuffer?
ejpa at 2007-7-9 6:25:00 >
"special" != "unique"
Though actually... the compiler knows about Integers, inasmuch as it knows to map ints to them sometimes. But that's during the code generation stage. What other object types have a special meaning during just the parsing stage?
Offhand I can't think of any, but I'll bet someone else will...
[added]
Arguably null...
Message was edited by:
paulcw
> It's final? It's immutable? Both should rather be the norm for classes if possible, not the exception.
Why would you want to make final classes the standard? Isn't that a violation of a key principle of OOP? I'd say you only want a final class if you are really dependent on a concrete implementation, which is something you want to avoid as possible!
Inheritance is overrated, for implementations anyway.
> Why would you want to make final classes the
> standard? Isn't that a violation of a key principle
> of OOP? I'd say you only want a final class if you
> are really dependent on a concrete implementation,
> which is something you want to avoid as possible!
I'd say you only want a non-final class if you actually prepared your class for random extension, which seems to have more pitfalls as one would think. It already starts with the "no non-private/non-final method calls from the c'tor" rule - no problems with that with non-extensibility by default.
> Isn't that a violation of a key principle of OOP?
Which key principle says "a class must be extendable"? And it's not like having to declare a class as "non-final" prohobits you from inheriting anything. But, like Serializabe, it tells the user: "I have taken all precautions necessary for safe inheritance".
Isn't making your class final saying "My way or the high way!", the Microsoft way of business... IME there is always some people from business department who invent stuff that you and I can't think of! They are the ones with the money... Small modifications can sometimes be realised by inheritance in order not to break existing running code. I agree with Paul that inheritance is overrated and should not always be the first choice. But final classes that appear not to be perfect are a pain in the ***! (and I don't claim to be able to write perfect code)
Eh, yes and no. When you're writing code, you have to think about its formal correctness. It's easier to enforce that if you don't need to worry about someone subclassing it. If you want something to be extensible, write it as such, so that it can be extended without breaking anything.
On the other hand, it's hard to predict ahead of time what will need to be reused. Also you want to prevent pushing people into the other, even worse extreme, in which they just cut-and-paste the source code and make a mostly identical class that nevertheless doesn't inherit or otherwise relate to the first class in any formal way.
Arguably the real solution is to permit easy refactoring, and keep things final and tight to begin with. Refactor as the need arises.
> But final classes that appear> not to be perfect are a pain in the ***! And non-final classes that break when extended are better how?I think "Effective Java" deals with that topic.
> > You can't, because the Java language defines that
> > "blah" has a special meaning that is related
> > specifically to the java.lang.String class.
>
> Well, it defines that String literals are compiled to
> have matching String instances created. I wouldn't
> say it's really that "special". Same's troe for all
> kinds of numbers and booleans. And StringBuffer (+
> operator).
>
> Is there a way to measure specialness? ;o)
(CUC, I know, but I'll say it anyway...)
Yes, all the primitives are special in the same sense that String is, and now, with autoboxing, so are the wrappers. They're special in that the language knows about these classes and is defined to turn literals into instances of these classes.
> > You can't because it's the language definition that
> > binds that syntax to the existing String class.
> But he could write a pseudo-string class with a c'tor
> that accepts a String, or a char array.
Of course. Anybody can write a class that wraps an array of chars, or an int, etc. However, he seems to be asking to do this:MyStringlikeClass mystr = "abc";
But he can't, because the language is defined to turn "abc" into a String.
Now, true, he did start off, "Imagine String didn't exist..." and if String dind't exist, the language would obviously not be defined to turn "abc" into a String, but the point is that turning "abc" into an instance of any class has to be supported at the language level, and in Java, there's no support for doing that with a user-defined class.
jverda at 2007-7-21 17:30:43 >
> > You can't, because the Java language defines that
> > "blah" has a special meaning that is related
> > specifically to the java.lang.String class.
>
> Well, it defines that String literals are compiled to
> have matching String instances created. I wouldn't
> say it's really that "special". Same's troe for all
> kinds of numbers and booleans. And StringBuffer (+
> operator).
That's exactly the specialness that makes it impossible to do what the OP is asking. The language defines the mapping between those literals and their respective classes.
jverda at 2007-7-21 17:30:43 >
> I think the compiler knows that about *every* class.> Otherwise, it'll complain about missing code. You> should know... ;)Not in the way it knows about String (and the primitives and wrappers).
jverda at 2007-7-21 17:30:43 >
> Arguably the real solution is to permit easy
> refactoring, and keep things final and tight to begin
> with. Refactor as the need arises.
In cases where this is possible, I agree. But imagine you are using a third party library of which you haven't got the source. If they create everything final and it doesn't fit your needs exactly. I'm glad Vodafone didn't write all final classes, we would never have been able to get their portal running without changing anything!
> And non-final classes that break when extended are better how?
Interesting discussion, makes me think more about what I do, what impacts it has... All depends on how clean you keep your design. Normally if you add a subclass, the only location where it should affect your program is where it is intended to be used in the new way. Code that uses the base class should not be affected. When you rewrite an existing final class you can make mistakes that affect every place where your class is used.
