I sort of understand the motivation for a String Builder class, but do all languages have one? Should they? I'm thinking specifically of PHP, Perl, Python, and Ruby. I know C# and Java do. If the others don't, why not? Do they not suffer from the same implementation problem? Or do they not care?
Not all languages have a String builder.
C, for example, doesn't even have strings.
In C++, std::strings are mutable -- they can be changed, so there is no real need for a separate string builder class.
In C# (and the rest of .NET), string are immutable - they cannot be changed, only replaced This leads to the problem causing the need for StringBuilder.
Technically, .NET strings are reference types pretending to be value types. This was done to make they act more like the native types (int, float, decimal).
There is no need in string builders when string streams exist - file-like objects to construct strings.
For example, Python has StringIO:
from cStringIO import StringIO
sio = StringIO()
sio.write("Hello")
sio.write(" world!!")
sio.write(111)
sio.write('!')
print sio.getvalue()
Hello world!!111!
Ruby has its own StringIO too. In C++, the equivalent is std::stringstream.
Related
Python can store multiple data types object inside a list while we can not do the same for Java and C++.
What are the additional functions used by python to do that? And from where we can study about the same.
To be fair, you are allowed to do the same in Java. Just you need to have a more generic type.
For example,
In python you can write
array = []
array.append(1)
array.append("hi")
The equivalent code in Java would be:
List<Object> list = new ArrayList<>();
list.add(1);
list.add("hii");
This two pieces of code are functionally equivalent, however in Java we require a cast to the desired type we want when we fetch from the list. In Python, the type is deduced in runtime so we don't have to do any explicit casting.
Python is a fully object oriented language, and also dynamically typed. So most things in Python behave the same way. Maps, Sets, and more complex data structures allow you to mix value types easily. Even key types for collections can be a mix of different data types as long the proper contract is implemented. To learn more about the python type system, look here; https://blog.daftcode.pl/first-steps-with-python-type-system-30e4296722af
I think everything in Python is dealt as an object and while we are storing data in Python, we are basically storing the references of the data. This may be the reason.
When to use which type of STRING in eiffel? I saw using READABLE_STRING_GENERAL and having to l_readable_string.out' to convert it to STRING`
READABLE_STRING_GENERAL is an ancestor of all variants of strings: mutable, immutable, 8-bit, 32-bit, so it can be used as a formal argument type when the feature can handle any string variant.
READABLE_STRING_32 is a good choice when the code handles Unicode, and can work with either mutable or immutable versions.
STRING_32 is a mutable Unicode variant. The code can change its value.
STRING is an alias for a string type that can either be STRING_8 or STRING_32. At the time of writing only a few libraries are adapted to handle the mapping of STRING to STRING_32. However, this mapping could become the default in the future to facilitate working with Unicode.
Regardless of the future, I would recommend using ..._STRING_32 to process strings. This way the code directly supports Unicode. The libraries are also updated in this direction. For example, io.put_string_32 can be used to print a Unicode string to the standard output (using the current locale).
Just as a follow-up (I know I am years late in posting anything).
What does it create instead of a String class? Unless java 'Isn't playing by its own rules' could I program my own Standard Library that utilizes string literals differently? Could I change what the string literal actually does even with the Java Standard Library being used?
It just seems strange to have something embedded in the language that has so much to do with a very specific class in the API that's not even primitive.
I was just wondering why the string functions in Google Go are defined in a strings package as opposed to on the string data type itself. They could have easily done
func (s string) ToUpper() string {
}
instead of the current
func ToUpper(s string) string {
}
in the strings package.
My guess is that if you want to implement a custom version of ToUpper on a custom type that extends string (i.e., type MyString string), you have no way to access the builtin ToUpper anymore on that type, but I can't find any support on this.
The short answer is: "To keep the language simple."
Go as a language only allows methods to be defined on types that are in the same package, but because string (like other builtin types) is implemented in the language itself, there is no way to add methods to it, without complicating the language / compiler.
It's also partly, because of how Go was designed.
See this mail from Rob Pike (one of the creators of Go) for more information:
Go does not have methods on basic types because the designers of the
language did not want methods defined for basic types, in part because
of the knock-on effect they might have on interfaces. I believe we are
all still comfortable with that decision. Others may feel differently.
-rob
And this one too:
We simply didn't understand what the implications would be; there's
nothing to explain. Go was designed with caution.
In that vein, look at the size of the strings library. Making all that
functionality methods on the basic type would, as Andrew said,
complicate the language. Why complicate the language with such trivial
things when it can be achieved by a library, which is more
maintainable, easier to extend, and more flexible? The language is
much simpler the way things are.
-rob
string is one of the predeclared type in the builtin package.
Those functions in strings couldn't have been defined as method using a predeclared type as a receiver: that would have required to define a type alias (to the underlying type string, in order to attach methods to it).
A method declaration uses a receiver which has a Type, which in turn does not include any of the predeclared types (bool byte complex64 complex128 error float32 float64 int int8 int16 int32 int64 rune string uint uint8 uint16 uint32 uint64 uintptr).
Or (which is done here), one uses functions in a dedicated package 'strings'.
That seems coherent with the fact that the type string itself has no fields: its content doesn't have to "receive" the method, it can simply be used by a function.
In scala, when you write out a string "Hello World" to a file it writes
Hello World
(note: no double quotes).
Lisp has a concept of print and write. One writes without the double quotes, the other includes them to make it easy to write out data structures and read them back later using the standard reader.
Is there anyway to do this in Scala?
With one string it is easy enough to format it - but with many deeply nested structures, it is nearly impossible.
For example, say I have
sealed trait PathSegment
case class P(x:String) extends PathSegment
case class V(x:Int) extends PathSegment
To create one does:
P("X")
or
V(0)
a list of these PathSegments prints as:
List(P(paths), P(/pets), P(get), P(responses), V(200))
I want this to print out as:
List(P("paths"), P("/pets"), P("get"), P("responses"), V(200))
In other words, I want strings (and characters), no matter where to occur in a structure to print out as "foo" or 'c'
That's what Serialization is about. Also, why JSON is popular.
Check out lift-json ( https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ ) for writing data out that will be parsed and read by another language. JSON is pretty standard in the web services world for request/response serialization and there are JSON libraries in just about every language.
To literally write out a string including double quotes, you can also do something like this:
"""
The word "apple" is in double quotes.
"""
I find a slightly more structured format like JSON more useful, and a library like lift-json does the right thing in terms of quoting Strings and not quoting Ints, etc.
I think you are looking for something like Javascript's eval() + JSON, and Python's eval(), str() and repr(). Essentially, you want Lispy symmetric meta-circular evaluation. Meaning you can transform data into source code, and evaluating that source code with give you back the same data, right?
AFAIK, there's no equivalent of eval() in Scala. Daniel Spiewak has talked about this here before. However, if you reeeeeealy want to. I suggest the following things:
Every collection object has 3 methods that will allow you to transform its data to a string representation anyway you want. There are mkString, addString and stringPrefix. Do something clever with them (think "decompiling" your in-memory ADTs back to source-code form) and you shall arrive to step 2). Essentially, you can transform a list of integers created by List(1,2,3) back to a string "List(1,2,3)". For more basic literals like a simple string or integer, you'll need to pimp the built-in types using implicits to provide them with these toString (I'm overloading the term here) helper methods.
Now you have your string representation, you can think about how to "interpret" or "evaluate" them. You will need an eval() function that create a new instance of a parser combinator that understands Scala's literals and reassemble the data structure for you.
Implementing this actually sounds fun. Don't forget to post back here if you've successfully implementing it. :)