<div>Well, alternatively, you could strip out the hyphens where needed.</div>

<div> </div>

<div>ToString.Replace FTW!!!111!!1!1!!11!1!!One<br><br> </div>

<div><span class="gmail_quote">On 12/20/07, <b class="gmail_sendername">Justin Clark-Casey</b> <<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Johan Berntsson wrote:<br>> This problem is not caused by my work, but of changes in later versions<br>

> of LibSL. It has changed from using ToString (unhyphenated) and<br>> ToStringHyphenated(), to only using ToString() (hyphenated). This means<br>> that there is no way of getting an unhyphenated string from libSL

<br>> anymore. I changed all instances of  ToStringHyphenated() in OpenSim to<br>> ToString(), but I didn't realize that there would be a problem with<br>> plain ToString() calls.<br>><br>> The basic problem is that we are relying on a libSL behaviour that is

<br>> outside our control, and has changed. If we want to keep up to date with<br>> libSL I suggest that the problem is solved.<br>><br>> Possible solutions:<br>> 1. Identify the problematic ToString() calls and use a utility function

<br>> (Util.ConvertToUnhyphentated) to fix them like before.<br>> 2. Write scripts to update the current databases to use hyphenated<br>> GUID:s<br>> 3. Change the code not to use ToString at all.<br>><br>> I prefer option 3, and to be compatible it could output unhyphenated

<br>> GUIDs. At least this means that we won't have problems every time libSL<br>> is refactored (and ToString is meant as a debug tool, not as a provider<br>> of keys to a database)<br>><br>Is there any chance that, if asked, the LibSL folks would add extra

methods such as ToGuidString() ToGuidHyphenatedString() ?  We would still be relying on LibSL but with explicitly named and purposed methods such as these rather than ToString(), I would hope no-notice refactoring would be much less likely.

<br><br>If necessary, we could then migrate to our own methods at our leisure<br>(after patching all the string calls to use these two methods).<br><br>Even if they won't do this, we could patch their code in the meantime

<br>for these methods (I doubt that would be very complicated) if migrating<br>now would be considerable and destablizing work (in light of 0.5).<br><br>Regards,<br><br>--<br>justincc<br>_______________________________________________

<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev

</a><br></blockquote></div><br>