• Garett Bass (11/11) Jan 15 2006 I can understand the usage of the word "pickle" in the sense of preserva...
• clayasaurus (3/44) Jan 16 2006 You might want to post here (
• Kris (5/7) Jan 16 2006 Yes; please do.

Garett Bass <garettbass studiotekne.com> writes:

I can understand the usage of the word "pickle" in the sense of preservation,
but the method names for pickling library are totally counterintuitive.

PickleWriter.freeze()?!?  why would a "writer" be doing any freezing?

PickleReader.thaw()?!?  why would a "reader" need to thaw something?

Shouldn't writers write() and readers read()?  The individual method names do
capture their own purpose, but they don't fit into the larger scheme of things.
 Instead they sound like poorly named food-service machinery.  Excuse me, but
I'm trying to serialize/deserialize some data.  If I wanted to freeze my pickle
I'd go to Antarctica and pull down my pants.

I'm writing a serialization library that uses, I think, much more intuitive
naming.  The base interface for serializable things is "Serializable".  Classes
that serialize built-in data types are called Serializers.  E.g.:

class GenericArraySerializer(T) : Serializable {...}

This template generalizes the serialization implementation for arrays of
intrinsic types.  Similarly, there are specializations for arrays of object
references.

When I want to serialize/deserialize, I create a subtype of class Format, which
determines the format of the serialization data, and provide a stream to
serialize/deserialize to/from.  One particular benefit of my solution is that I
only require a SerializableObject's serializable members to be registered, the
class need not provide any code to handle the actual reading and writing that
occurs during serialization.

Sorry for the rant.  Seeing Pickle has only reinforced my desire to bring my
serialization project to completion.  I suppose is a good thing.  I only hope
the rest of Mango is a doesn't have such a multiple-personality disorder.

Regards,
Garett

clayasaurus <clayasaurus gmail.com> writes:

You might want to post here ( 
http://dsource.org/forums/viewforum.php?f=5 ) as well.

Garett Bass wrote:
 I can understand the usage of the word "pickle" in the sense of 
 preservation, but the method names for pickling library are totally 
 counterintuitive.
 
 PickleWriter.freeze()?!?  why would a "writer" be doing any freezing?
 
 PickleReader.thaw()?!?  why would a "reader" need to thaw something?
 
 Shouldn't writers write() and readers read()?  The individual method 
 names do capture their own purpose, but they don't fit into the larger 
 scheme of things.  Instead they sound like poorly named food-service 
 machinery.  Excuse me, but I'm trying to serialize/deserialize some 
 data.  If I wanted to freeze my pickle I'd go to Antarctica and pull 
 down my pants.
 
 I'm writing a serialization library that uses, I think, much more 
 intuitive naming.  The base interface for serializable things is 
 "Serializable".  Classes that serialize built-in data types are called 
 Serializers.  E.g.:
 
 class GenericArraySerializer(T) : Serializable {...}
 
 This template generalizes the serialization implementation for arrays of 
 intrinsic types.  Similarly, there are specializations for arrays of 
 object references.
 
 When I want to serialize/deserialize, I create a subtype of class 
 Format, which determines the format of the serialization data, and 
 provide a stream to serialize/deserialize to/from.  One particular 
 benefit of my solution is that I only require a SerializableObject's 
 serializable members to be registered, the class need not provide any 
 code to handle the actual reading and writing that occurs during 
 serialization.
 
 Sorry for the rant.  Seeing Pickle has only reinforced my desire to 
 bring my serialization project to completion.  I suppose is a good 
 thing.  I only hope the rest of Mango is a doesn't have such a 
 multiple-personality disorder.
 
 Regards,
 Garett

"Kris" <fu bar.com> writes:

"clayasaurus" <clayasaurus gmail.com> wrote
 You might want to post here ( 
 http://dsource.org/forums/viewforum.php?f=5 ) as well.

Yes; please do.

Any issues regarding Mango should (also) be posted over at dsource.org, just 
so that they are guaranteed to be noticed. Mango is an open-source, 
group-supported library ~ improvements are more than welcome!