Make mappers friendlier to Structs, etc about perpetuity HOT 3 OPEN

I can see the advantage of going in, expecting values to be stored in instance variables, but there's plenty of cases where that wouldn't be enough, Struct just being one example.

Perhaps something like this for both methods and generic operations:

Perpetuity.generate_mapper_for Article do
  attribute :title, accessor: :title
  attribute :body,  via: lambda{|article| article.content(:unescaped) }
end

I'd see the individual methods implemented before the lambda.

from perpetuity.

Yep. It'd be pretty nice to have other options to store/retrieve attributes. I like the ivars as the default (since I'd bet that's the most common). I originally thought about passing blocks instead of lambdas:

Perpetuity.generate_mapper_for Article do
  attribute :title do |article|
    article.title
  end
  # ... or ...
  attribute(:title) { |article| article.title }
end

Aesthetically, I'm not sure I like either one of these, though. Using do/end on separate lines breaks up the declarations. Using parentheses to override precedence for the curly-brace block would make it look different from other lines.

Also, it wouldn't account for storing the attributes. Something like the :accessor attribute would take care of that, but if we pass in procs, blocks, or lambdas (oh my) we'll need to allow two different ones to allow for deserialization as well as serialization.

Perpetuity.generate_mapper_for Article do
  attribute :body, reader: proc { |article| article.title }, writer: proc { |article, value| article.title = value }
end

The upside of something like this is that we can get rid of the hardcoded instance variable access and supply default procs instead (which technically would still hardcode the instance variable access, but at least it'd be overridable :-)).

from perpetuity.

Hmm … It seems some of the things I mentioned here might conflict with what we've discussed in #15. Maybe using procs might not be a good idea and we should stick to letting users specify whether to use ivars or accessor methods.

from perpetuity.