On Apr 30, 2008, at 10:15 AM, Rubber Chicken Software Co. wrote:
> Isn't that a very fundamental mistake that is propagated by functions
> like GetSaveInfo? I mean, it specifically says in the docs "don't
> fiddle with the string". Although YOU MAY NOT, something else will,
> as we see. I figure RB uses that datatype because there is nothing
> else to use - unless you count a MemoryBlock, but that isn't written
> easily into a plist or whatever, which almost certainly is the
> intention.
A MemoryBlock would have been a sensible choice, but it really
wouldn't help, since MemoryBlocks are automatically converted to (nil-
encoded) strings anyway.
I don't think there's anything wrong with using strings for binary
data -- "string" just means a string of bytes. But I can see an
argument now for throwing an exception whenever a nil-encoded string
is treated as text. That would have alerted you to the correct
problem much faster in this case.
> Wouldn't it have been better for RB to Base64 it themselves,
> since the only purpose of the string is to be created by GetSaveInfo
> and read by GetRelative?
Hmm, maybe, but I'm not convinced.
> Wait.. I know the answer: sometimes it's not necessary, so don't bulk
> up the function unnecessarily. Leave it to the user to add the
> flexibility. But then again, practically the ONLY purpose of
> GetSaveInfo (as revealed by the name) is to store it as text and NOT
> binary data.
Says who? You happen to be writing a text file, but other people
write binary files. Binary data works just fine for them.
> I still figure that the "secret text format" RB uses in
> GetSaveInfo should be basee64'd in the first place, that would be
> logical. if not, at the very least, this should be printed in the
> manual that it's binary data.
Well, true. Lots of stuff could be added to the manual. :)
> Right, ok. Now that I'm complaining... =) Isn't GetRelative a real
> bad name for this function?
No, it's accurate.
> Most of the time I'm using GetSaveInfo to
> give me absolute information. Tying it in with a FolderItem is
> unnecessary with that.
Then you shouldn't be calling GetRelative; call GetFolderItem instead.
> Also, the docs are unclear - it says the host FolderItem of
> GetRelative is
> ignored if the GetSaveInfo-generated string is absolute, but the host
> FolderItem can't be Nil of course, so it's not COMPELTELY ignored.
Well, perhaps, due to some deep fundamentals about the language --
but this is basically saying, if you misuse the functions and call
GetRelative when you should have called GetFolderItem, it'll work in
a reasonable fashion anyway. Nothing wrong with that.
Cheers,
- Joe
--
Joe Strout
Inspiring Applications, Inc.
http://www.InspiringApps.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|