http://www.perlmonks.org?node_id=1039806


in reply to Re^3: OO Perl Baby Steps
in thread OO Perl Baby Steps

I see two primary concerns here regarding OO: encapsulation and security. Perl does not provide acceptable security here, because to do so would be very un-Perl like. As someone who was trained on classic OO before he studied and used Perl, i have absolutely no desire to use that private or protected nonesense in my code, because i dislike the restrictions they impose on future hackers of my code.

Othewise i would use Java or Ruby or perhaps Perl 6 in 100 years ...

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^5: OO Perl Baby Steps
by Anneq (Vicar) on Jun 22, 2013 at 16:58 UTC

    Jeffa,

    If you have the time, I would greatly appreciate it if you would give an explanation or example(s) of the security risks related to using OO in perl. Or perhaps suggest a link to where I could learn more?

    Thanks

    Anne

      I was merely referring to "locking down" access to certain methods via the concepts (and implementation) of private, protected and public method modifiers. In other words, secure your methods' accessibility from clients.

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
      -R--R-RR-R--R-RR-R--R-RR
      B--B--B--B--B--B--B--B--
      H---H---H---H---H---H---
      (the triplet paradiddle with high-hat)
      

        Thanks jeffa,

        A lot of my web app methods are activated through URLs, via catalyst, so I want to make sure I'm not missing something I need to know about protecting those methods.

        Anne

        In other words, secure your methods' accessibility from clients.

        In other words, deny access, forbid access, put a padlock on it, lock the door, nail the windows shut, eat those pancakes :)