in reply to Re: Generally accepted style in Perl objects
in thread Generally accepted style in Perl objects

If the properties are completely unprocessed (i.e. you never rely on knowing what someone's favorite mustard is), you can probably get away with "add_property()", "set_property()", "get_property()", "get_all_properties()", and "delete_property()" routines. That'll keep you away from making assumptions about the internals that may later change, but is flexible enough so that you don't need to keep changing the class interface (which is only slightly better than having no interface at all.)
  • Comment on Re: Re: Generally accepted style in Perl objects

Replies are listed 'Best First'.
Re: (Stephen) Re: Generally accepted style in Perl objects
by coreolyn (Parson) on Dec 30, 2000 at 01:57 UTC

    I like the way you explained breaking out standard functions, from core functions. It's something I've always done, but have found myself hard pressed to enunciate as to why I do it. It has always stumbled out of my mouth as, "Cuz I don't want to mess the other files up".

    I do have a small point of contention with a portion of your conclusion though. You said,

    ...changing the class interface (which is only slightly better than having no interface at all.)

    Speaking from my position as a struggling Perl person that's learning both the base perl code and the many abstractions1 of perl as 00. I can suck the power of a 2 processor SPARC 450 because of the horrendous programing in my applications core modules. For this reason I contend that,
    Changing the class interface, is worse than no interface at all.

    coreolyn Duct tape devotee.
    -- That's OO perl, NOT uh-oh perl !-)

    1 From my slighlty crazed point of view, OO Perl takes Perl from being 'duct_tape' to 'silly putty on acid'.
[reply]
      Preachin' to the choir. :)

      stephen

[reply]

In Section Seekers of Perl Wisdom