<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://eiffelroom.com" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>eiffelroom - Unicode strings - an opportunity? - Comments</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity</link>
 <description>Comments for &quot;Unicode strings - an opportunity?&quot;</description>
 <language>en</language>
<item>
 <title>Read-only strings</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity#comment-412</link>
 <description>&lt;p&gt;Ignoring for the moment Colin&#039;s suggested optimisations, I think the most interesting suggestion he made was to make &lt;code class=&quot;geshifilter eiffel&quot;&gt;STRING_32&lt;/code&gt; read-only. I&#039;m convinced that read-write strings are a maintenance problem, in many ways, not the least of which is the complexity it adds to the interface of the &lt;code class=&quot;geshifilter eiffel&quot;&gt;&lt;a href=&quot;http://www.google.com/search?q=site%3Ahttp%3A%2F%2Fdocs.eiffel.com%2Feiffelstudio%2Flibraries+STRING&amp;btnI=I%27m+Feeling+Lucky&quot;&gt;&lt;span style=&quot;color: #800000&quot;&gt;STRING&lt;/span&gt;&lt;/a&gt;&lt;/code&gt; class. I agree with Colin: Eiffel should grab this opportunity to abolish read-write strings. I&#039;d like to see what the interface of &lt;code class=&quot;geshifilter eiffel&quot;&gt;STRING_32&lt;/code&gt; looks like without any commands!&lt;/p&gt;

</description>
 <pubDate>Fri, 21 Dec 2007 16:01:27 -0800</pubDate>
 <dc:creator>peter_gummer</dc:creator>
 <guid isPermaLink="false">comment 412 at http://eiffelroom.com</guid>
</item>
<item>
 <title>I think I&#039;ve mentioned it</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity#comment-410</link>
 <description>&lt;p&gt;I think I&#039;ve mentioned it quite a few times, STRING_GENERAL is indeed not worth it when there is no more legacy using STRING_8. It was only created to offer a smooth transition path for those who were using STRING_8 (thus the many restrictions on the string containing only characters that can fit into a STRING_8 instance). So it is just a matter of time until it becomes obsolete.&lt;/p&gt;

&lt;p&gt;For substring, there is nothing that you cannot do with today&#039;s implementation. If we add a boolean flag to say whether a STRING object has changed or not, then we can easily implement substring the way you describe it. It could be called `aliased_substring&#039;.&lt;/p&gt;

&lt;p&gt;For the starting index being 0 instead of 1, we can easily do it, but it would break some existing code using `area&#039; directly instead of `to_c&#039;. However I&#039;m not sure if it makes sense as most of the operations in class STRING are already using 0 based indexing for efficiency. So here you would only optimize client code but the drawback is that indexing from 0 is always messy, especially when the rest always starts at 1.&lt;/p&gt;

</description>
 <pubDate>Thu, 20 Dec 2007 07:58:30 -0800</pubDate>
 <dc:creator>manus_eiffel</dc:creator>
 <guid isPermaLink="false">comment 410 at http://eiffelroom.com</guid>
</item>
<item>
 <title>All other reference types</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity#comment-409</link>
 <description>&lt;p&gt;All other reference types are not writable. Only those that provide mutating features.&lt;/p&gt;

&lt;p&gt;Yes, you understand my point about substring correctly, but describing it as cunning is a bit much.&lt;/p&gt;

&lt;p&gt;Colin Adams&lt;/p&gt;

</description>
 <pubDate>Sun, 16 Dec 2007 21:07:33 -0800</pubDate>
 <dc:creator>colin-adams</dc:creator>
 <guid isPermaLink="false">comment 409 at http://eiffelroom.com</guid>
</item>
<item>
 <title>STRING_32 read-only</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity#comment-407</link>
 <description>&lt;p&gt;I think that&#039;s a great idea, Colin.&lt;/p&gt;

&lt;p&gt;But what about the fact that this would make &lt;code class=&quot;geshifilter eiffel&quot;&gt;STRING_32&lt;/code&gt; an oddity in Eiffel&#039;s type system? All other reference types are writeable. Would Eiffel need a &lt;code class=&quot;geshifilter&quot;&gt;readonly&lt;/code&gt; keyword?&lt;/p&gt;

&lt;p&gt;Also, just to be sure that I understand your point about &lt;code class=&quot;geshifilter eiffel&quot;&gt;substring&lt;/code&gt; being more efficient, do you mean that each new &lt;code class=&quot;geshifilter eiffel&quot;&gt;substring&lt;/code&gt; object would be implemented by indexing into the area of the old string? Cunning!&lt;/p&gt;

</description>
 <pubDate>Sun, 16 Dec 2007 16:44:00 -0800</pubDate>
 <dc:creator>peter_gummer</dc:creator>
 <guid isPermaLink="false">comment 407 at http://eiffelroom.com</guid>
</item>
<item>
 <title>Unicode strings - an opportunity?</title>
 <link>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity</link>
 <description>&lt;p&gt;It seems to me that STRING_GENERAL isn&#039;t worth having - just take a look at some of the implementations, and you will see they are marked for 8-bit only.&lt;/p&gt;

&lt;p&gt;I think it would be better to take the opportunity to abandon read-write strings altogether (confining STRING_8 to &amp;quot;legacy&amp;quot;) and make STRING_32 unconnected with STRING_8.&lt;/p&gt;

&lt;p&gt;Also substring would then not need to take a copy, and so could be much faster. Indeed, we could consider wasting the initial byte, and so eliminating the cost of translating from 1-base addressing to 0-based addressing (1 byte wasted would not be very significant when every character consumes 4 bytes - I am assuming UTF-32 for the implementation of STRING_32).&lt;/p&gt;

</description>
 <comments>http://eiffelroom.com/blog/colin_adams/unicode_strings_an_opportunity#comments</comments>
 <pubDate>Sat, 15 Dec 2007 22:06:12 -0800</pubDate>
 <dc:creator>colin-adams</dc:creator>
 <guid isPermaLink="false">245 at http://eiffelroom.com</guid>
</item>
</channel>
</rss>
