Re: [Openinteract-help] Automatically created accessors - too much magic! + Tracking state

[Chris W. <ch...@cw...>]

* Terrence Brannon (bl...@sv...) [011104 15:11]:
> So now I have made my way over to SPOPS::Manual::Object and just as I 
> expected, the elusive business object new() method pops up.. heheh.
> 
> So, I am reading these docs and I come to the section on automatically 
> created accessors and I think:
> 
> 1 - are these accessors subject to field filtering as the tied hashref 
> fields are?

Yes.

> 2 - why are they set-only? get-set is better isn't it?

I found it too confusing with trying to set the field to a null, plus
see the next item.

> 3 - why is he making more than one way to do this? it seems to be
> un-necessarily. almost as if he wants to show a living-breathing
> implementation of every advanced technique from Conways
> "Object-Oriented Perl" for some reason. :-)

Umm... no. Actually, the accessor methods are secondary to getting and
setting the object properties as a hashref. To me, this is more
perlish and more easy to understand. Since AUTOLOAD made it so easy, I
threw them in there as sugar.

> I hope I don't seem overly critical. I am just giving feedback on what 
> was running through my mind when I read these docs.

No problem. Feedback is good. Particularly since the manual isn't
finished.

> Also, I think the wording of the object change methods could be
> better
> 
> $obj->has_changed  should be $obj->register_change
> $obj->changed isn't bad but I would prefer $obj->has_changed for this

That should be:

 $obj->is_changed (return true if changed, false otherwise)
 $obj->has_change (set the current state to 'changed')

If the docs reflect otherwise, then they need to be modified.

Unless I hear from other folks agreeing with you, I'll probably keep
them as they are. If only because users will generally never use
these. They're more for internal (and driver) use.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.