On Sunday, May 3, 2015 at 6:10:00 PM UTC-4, Kevin Squire wrote: > > One thing I was confused about when I first started using Julia was that > things that are done with strings in other languages are often done > directly with IO objects in Julia. > > For example, consider that, in Python, most classes define `__str__()` and > `__repr__()`, which create string representations of objects of this class > (the first more meant for human consumption, the second for parsing > (usually)). > > In Julia, the implicit assumption is that most strings are meant for > output in some way, so why not skip the extra memory allocation and write > the string representation directly to output. For this, types define > `show(io::IO, x::MyType)`. If you really want to manipulate such strings, > you can (as pointed out in this thread) go through an IOBuffer object > first. (There is also `repr(x::SomeType)`, but it's not emphasized as > much.) >
Problem is, with what I'm doing, the strings are almost never written to output... they are analyzed, modified, stored and retrieved from a database... and you want all the normal string operations... you might be doing regex search/replace, for example... and for performance reasons, you don't want to be converting to an immutable string all the time. This was a design decision made early on. I personally found (and still > find) it somewhat awkward at times, but for many things, it works fine, and > (seemingly) it lets most string output allocate less memory by default. > > Now, it certainly is the case that mutable strings may be very useful in > some contexts. The BioSeq.jl package implements mutable DNA and protein > sequences, which are very useful there, and would be represented by mutable > strings in many other languages. The best way to test that would probably > be to create a package (say, MutableStrings.jl), and define useful types > and functions there. > There are a few things I'd like to add to Julia wrt strings, validated strings (right now, it is a bit of a mishmash as to whether or not convert functions will accept invalid Unicode data), and mutable strings... Somebody already did create a MutableStrings.jl, however it is broken, it doesn't look like it has been updated in over a year, and is only for ASCII and UTF-8, it doesn't have UTF-16 or UTF-32 mutable strings... (and I also want mutable 8-bit (ANSI Latin 1) strings and UCS-2 strings (i.e. UTF-16 with no surrogates) [that is so that it would be a DirectIndexString, to get O(1) instead of O(n) for some operations].) Cheers, > Kevin >
