Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Tutorial: Introduction to Object-Oriented Programming

by Abigail-II (Bishop)
on Dec 13, 2002 at 12:10 UTC ( #219563=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Tutorial: Introduction to Object-Oriented Programming
in thread Tutorial: Introduction to Object-Oriented Programming

Are there any weaknesses?
  • As was pointed out, you need to take care of possibility someone subclass will implement stringification overload. A solution was proposed - alternatively, you can document that it's forbidden for a subclass to overload stringification if you don't want to pay the penalty. I think this isn't a major issue; overloading is used, but most objects don't.
  • You have to write a DESTROY method. You can't say that you can live with the memory leak - Perl does not garantee that if you create a reference, let it go out of scope, and then create a new reference, the new one will not have the same address as the first one.
  • Serialization might be a bit harder in some cases. But calling Serialize or Date::Dumper on an object won't work in general anyway. An object might have a reference to something, and a general serialization function cannot know whether the reference needs to be shared with something else.
  • You can't use the standard Class::MethodMaker. But that doesn't mean you can't have a module giving you the same functionality. I've written a proof of concept Class::MethodMaker::InsideOut (not released) giving the same functionality as Class::MethodMaker for Inside Out objects. It'll can even do the DESTROY function and the declaration of hashes. It's using a source filter. Alternatively, you could use our to declare the attribute hashes, and write a module with the same functionality as Class::MethodMaker.
  • If you have a large class, you may want to split it over more than one file. If your attribute hashes are lexical, this will not work. Again, you could use a source filter to merge the files, or declare the attribute hashes with our.
Just in case you are saying that making the attribute hashes package variables makes that someone else can access your attributes, that's ok. I'm not advocating my technique such that you cannot get to the attributes, I want to prevent accidents. After all: "It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

Abigail


Comment on Re: Tutorial: Introduction to Object-Oriented Programming
Select or Download Code
Re: Re: Tutorial: Introduction to Object-Oriented Programming
by BrowserUk (Pope) on Dec 13, 2002 at 17:59 UTC

    Thanks Abigail.

    And no. I had no insights as to any of the limitations.

    Until now I have had no real use for OO in my exploration of Perl, so i have basically avoided it. I have now started something that would benefit from OO which happens to coincide with this thread and your post.

    I read a couple of earlier peices on light-weight/inside-out objects, as well as several peices by you and others on the merits of OO in perl, so I just wanted to know what I was getting into. You can see my first attempt as using your method at (my?) problem with re-blessed references(?) though if your interested you'd better look at adrianh's correction of my idiocies at Re: Re: (my?) problem with re-blessed references(?).

    I'd be interested to hear your thoughts on using lvalue subs for the accessor/mutators? I've long prefered the syntax of one subname per attribute that returns the value optionally setting it if a value is passed. I hated the whole "should it be set_x/put_x or set_x/get_x debate" that rages still in the Java discussion groups. Another totally pointless, "religious-type", waste of time IMO. I also hate having to look up which convention is used for every attribute of every class I use.

    The lvalue sub seems to me to be the logical conclusion to this. One attribute, one name. Name it to use it. Assign to it to set it. In-line assign and use just like any other var. Makes perfect sense to me, but I'm sure that others have a different opinion.


    Examine what is said, not who speaks.

      I'd be interested to hear your thoughts on using lvalue subs for the accessor/mutators?

      Don't like them. No sir! Don't like them one bit.

      For me the problem with lvalue subs is that they expose your object implementation just a little bit too much. Consider:

      use strict; use warnings; my (%Foo, %Bar); sub foo : lvalue { $Foo{+shift} }; sub bar { my $key = shift; $Bar{$key} = shift if @_; $Bar{$key}; }; foo("apples") = 12; foo("pears") = 0; print foo("apples"), "\n"; print foo("pears"), "\n"; bar(bananas => 3); bar(oranges => 18); print bar("bananas"), "\n"; print bar("oranges"), "\n";

      Now, what happens if I want to prevent negative values being assigned to the hashes. With bar() it's trivial.

      sub bar { my $key = shift; if (@_) { die "no negative numbers" if $_[0] < 0; $Bar{$key} = shift; }; $Bar{$key}; };

      With foo... it isn't trivial.

      It's possible with a tied hash - but it's not simple. As soon as you need to do things with the values you are assigning (check them for validity, transform them, etc.) things suddenly get hard. You can end up with a separate tied class for each attribute.

      When you get to this stage "normal" subroutines look good again - but then you're changing your API. Nasty. Best to stick with normal subroutines (be it perls all-in-one or separate setter/getter) from the start.

      I really hope that perl6 takes a lesson from Eiffel and makes class attribute access and method calls look the same - that way all this nonsense can go away. Lexical subs used in this way are really just syntactic sugar for a $hash->{attr} and should be avoided most of the time (IMHO of course :-)


      Updates

        Agreed.

        Though I would argue that the problem is not the concept of lvalue subs that is at fault, but just the current implementation.

        As they stand currently, they are almost completly useless. The fact that there is no way to access the value being assigned prior to it's assignment, and that any attempt to check it after assignment prevents the assignment, is simply bewildering.

        Why the value is not made available to the sub as the last value in @_ I simply don't understand. The current implementation where the assigned value magically overwrites the last available lvalue in the sub if there is one and breaks if there isn't is just simply broken.

        Shame. No wonder nobody uses them.


        Examine what is said, not who speaks.

        Have a look at Attribute::Property on CPAN. It could easily be modified to use inside out objects, the current hype in Perl OO land.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://219563]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2014-07-29 12:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (217 votes), past polls