Forum: Nitro Og [patch]: Rename write_attr_<class> to serialize_attr_<class>

Posted by Mark Van De Vyver (mvyver)
on 2007-10-05 08:19
Attachment: mvdv-20071005-1.tar.gz (18,5 KB)
(Received via mailing list)
These changes should have no effect at the users level?

* Rename write_attr_<class> to serialize_attr_<class>
  These names properly reflect what is happening.  Renaming is also a
precursor to some changes that 1) DRY out the serialization that
occurs in Og, 2) Should permit Og's type mapping to be extensible
(without touching the code).
Posted by George Moschovitis (Guest)
on 2007-10-05 09:35
(Received via mailing list)
I kind of like

read_attr
write_attr

(notice the symmetry)

-g.
Posted by Mark Van De Vyver (mvyver)
on 2007-10-05 10:57
(Received via mailing list)
On 10/5/07, George Moschovitis <george.moschovitis@gmail.com> wrote:
> I kind of like
>
> read_attr
> write_attr

I haven't touch write_attr  -  yet :)

if you're still not convinced let me know I'll try and explain why.
Mark
Posted by Mark Van De Vyver (mvyver)
on 2007-10-05 13:32
(Received via mailing list)
Some detail...

On 10/5/07, Mark Van De Vyver <mvyver@gmail.com> wrote:
> On 10/5/07, George Moschovitis <george.moschovitis@gmail.com> wrote:
> > I kind of like
> >
> > read_attr
> > write_attr

The method

SqlStore#read_attr

currently calls:
self.class.parse_<klass>(res[col + offset])

while

SqlStore#write_attr

currently calls:
write_attr_<klass>(value)

None of these actualy read or write anything - in fact I ignored even
looking at them for a long time since I wasn't at the point of
reading/writing data... silly me :)

The RDoc is most accurate:
They serliaze/deserialize instances of Og objects.  Later on some
other method reads/writes this data - for sql stores the closest
methods to doing this are SqlStore#exec and SqlStore#query - even then
I'd argue it's still misleading naming to call them read/write.
anyway it is irrelevant right.

Now SqlStore#quote (and hence <vendor>Adapter) deals with arrays, but
re-implements all that is done in write_attr.
This opens the door for inconsistencies.
I'm heading towards closing that door, but I'll close it first in the
DbiAdapter, and then only when spec's are in place.

I'd guess a reason for this is that someone baulked at using
#write_attr in the quote loop, as in the following (untested):

module SqlUtils
  def quote(vals)
    vals = [vals] unless vals.is_a?(Array)
    quoted = vals.inject("") do |s, val|
      s += write_attr + ','
    end
    quoted.chop!
    vals.size > 1 ? "(#{quoted})" : quoted
  end
end

But essentially that is 99% of what is happening in SqlUtils#quote.

The non DbiAdapter spec's will flow as I make them....

> I haven't touch write_attr  -  yet :)

and won't until there is a spec in place.

HTH
Mark
This topic is locked and can not be replied to.