Forum: Nitro Og [RFC]: More jargon...

Hi Devs,
I'd appreciate thought and comments on the following.
A word in advance, I'm not proposing immediate changes, but rather
settling on some nomenclature that, when an oppotunity arises can be
put in place/implemented.
I'd think the process might be something like
 - the spec existing method/behavior
 - have spec accepted.
 - implement any changes to the code, the existing spec and 
documentation.

Following on from the last email you'll notice there are issues with
the names given to methods.  I've found that looking at these names
can lead you up the garden path/ down the creek (as you wish), but
quite frustrating regardless.

At the moment some related Og methods are prefixed with:
write, read, parse, and quote.
It seems they largely do the following - convert data in instances of
Ruby objects into/from text (ASCII?) strings, to be formatted ready
for (but not) storage/retrieval.
IMHO they certainly don't write or read, it's debatable that some
'parse', and 'quote' is also drawing a long bow for what that method
does.

serialize/deserialize terms are candidates for prefixes _but_ Og
doesn't store as binary - eg uses Yaml rather than Marshal - and this
could be considered misleading?
load/dump could be used as prefixes instead of read/write?
I'm not nuts about stringify/destringify but they could be prefixes
for the methods that convert to text strings.

Anyway, I think it needs some thought and I'd appreciate any comments.
Mark

Mark Van De Vyver wrote:
> serialize/deserialize terms are candidates for prefixes _but_ Og
> doesn't store as binary - eg uses Yaml rather than Marshal - and this
> could be considered misleading?
> load/dump could be used as prefixes instead of read/write?
> I'm not nuts about stringify/destringify but they could be prefixes
> for the methods that convert to text strings.
>
>   
I suggest marshal/unmarshal regardless of the underlying technique.
"Marshal" may own the name but the fact is that converting to/from an
external format, be it binary, YAML, or XML, is in fact marshalling and
unmarshalling.  I've seen output to XML referred to as "serialization"
as well.

>
> IMHO they certainly don't write or read, it's debatable that some
>

in lisp literature reading == parsing. In this point of view read is a 
valid
prefix.
I chose them because read has the same stringlength with write and makes
the source code nicer ;-)

but as I said, I fully agree with you that naming consistency is 
important.

-g.

Hi Devs,
Votes please...

On 10/7/07, George Moschovitis <george.moschovitis@gmail.com> wrote:
>
> > IMHO they certainly don't write or read, it's debatable that some
> >
>
> in lisp literature reading == parsing. In this point of view read is a valid
> prefix.
> I chose them because read has the same stringlength with write and makes
> the source code nicer ;-)
>
> but as I said, I fully agree with you that naming consistency is important.

Currently we have methods named:
parse_attr_<klass>
write_attr_<klass>


Are any of the following name pairs preferred?:

deconstruct_attr_<klass>
construct_attr_<klass>

decompose_attr_<klass>
compose_attr_<klass>

disassemble_attr_<klass>
assemble_attr_<klass>

addendum:

On 10/7/07, Mark Van De Vyver <mvyver@gmail.com> wrote:
> > I chose them because read has the same stringlength with write and makes
>
> deconstruct_attr_<klass>
> construct_attr_<klass>
>
> decompose_attr_<klass>
> compose_attr_<klass>
>
> disassemble_attr_<klass>
> assemble_attr_<klass>

marshall_attr_<klass>
unmarshall_attr_<klass>

Thanks
Mark