On 12 Aug 2008, at 8:40 pm, Gerriet M. Denkmann wrote:
I'm sure if it weren't someone would have raised merry hell about
it before now. Something's fishy...
Reminds of a very rational being walking the streets with his son.
The son: "Hey dad, there's a hundred dollar note!"
Dad: "No son, this cannot be. If the note were real, somebody would
have picked it up long ago".
OK, fair comment. But let's look at the string you can't store:
$null
This reminds *me* of the old joke: "Doctor, doctor, it hurts when I do
this!" (...) "Well, don't do that then..."
If that's the one string you can't store, presumably because it's used
as a marker within the archive, then don't try to store what is a
reserved byte sequence. For its purpose, you can find an easy way
around it. What you seemed to be implying was that there is a whole
class of string sequences that broke keyed archiving, which of course
would be far worse than this one apparently reserved string.
If you need to store "$null", just substitute another string to stand
for it, archive that, and reverse the substitution when you decode. If
that is the argument between using keyed versus non-keyed archiving,
it's an awful lot to lose for a very minor inconvenience for this one
case. And, yes, I would probably agree that Apple should be performing
this substitution in their code rather than exposing this bug - but
then again it would only be shifting the problem onto whatever
substitution string they chose, though that could be made very much
less likely to collide.
As for file sizes, is that really all that relevant these days?
Archives don't store huge amount of overhead compared to the data
itself - saving a few bytes here and there is not worth the pain of
losing the convenience of keyed archiving.
A factor of two or three may be considered a "few bytes here and
there" or might amount to some pain. All according to taste and
situation.
True enough, but. A factor of two or three? Depends on what your data
is. If you're archiving a large image or video sequence, the archive
overhead is going to be an infinitesimal fraction of this. And if not,
then you're likely talking about small files anyway. 10K or 30K? It
hardly matters. Even if 20K of the file is not data, who cares? I know
I'm willing to spend 20K (or even 200K) to read the remaining 10K (or
100K) so very conveniently. Last time I cared about 10K versus 30K was
when Macs had an optional external 20MB(!) Hard Disk and 800K floppies.
So yes, according to your taste and situation. But surely the pain of
using non-keyed archiving *by far* outweighs these considerations?
cheers, Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
