<?xml version="1.0" encoding="windows-1252"?>
<node id="219563" title="Re: Tutorial: Introduction to Object-Oriented Programming" created="2002-12-13 07:10:25" updated="2005-07-27 14:07:47">
<type id="11">
note</type>
<author id="169744">
Abigail-II</author>
<data>
<field name="doctext">
&lt;blockquote&gt;&lt;em&gt;
Are there any weaknesses?
&lt;/em&gt;&lt;/blockquote&gt;
&lt;ul&gt;
&lt;li&gt;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.
&lt;li&gt;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.
&lt;li&gt;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.
&lt;li&gt;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 &lt;code&gt;our&lt;/code&gt; to declare the
    attribute hashes, and write a module with the same functionality
    as Class::MethodMaker.
&lt;li&gt;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 &lt;code&gt;our&lt;/code&gt;.
&lt;/ul&gt;
    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 &lt;em&gt;accidents&lt;/em&gt;.
    After all: "It would prefer that you stayed out of its living room
    because you weren't invited, not because it has a shotgun." 
&lt;/ol&gt;
&lt;p&gt;
Abigail
</field>
<field name="root_node">
218778</field>
<field name="parent_node">
219397</field>
</data>
</node>
