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 M. [email protected] 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_
write_attr_
Are any of the following name pairs preferred?:
deconstruct_attr_
construct_attr_
decompose_attr_
compose_attr_
disassemble_attr_
assemble_attr_
addendum:
On 10/7/07, Mark Van De Vyver [email protected] wrote:
I chose them because read has the same stringlength with write and makes
deconstruct_attr_
construct_attr_
decompose_attr_
compose_attr_
disassemble_attr_
assemble_attr_
marshall_attr_
unmarshall_attr_
Thanks
Mark