Alex Francis wrote:
> On Wed, Jan 27, 2010 at 3:58 PM, Lyle <[email protected]> wrote:
>> package OrigObj;
>> use ExtObj;
>> my $OrigObj = {};
>> bless $OrigObj, OrigObj;
>>
>> 1;
>>
>> With $OrigObj->ExtObj->new_methods; some of the new_methods will want to
>> access $OrigObj.
>>
>> Hope that makes more sense?
>
> If you *just* want to add more methods to OrigObj but put them in a
> separate source file, because it's easier to manager that way, you can
> do that in a couple of ways - none of which are particularly good
> practice but would work.
For this I can just export methods to the OrigObj's namespace. I really
want to keep them grouped separate in a sub object. I'm happy with
$OrigObj->ExtObj->new_methods notation, just think there is probably a
simpler/more efficient way of implementing...
> 3. Simply call methods of another package with your object. Put your
> new methods in ExtObj, then call e.g. $OrigObj->ExtObj::new_methods().
> Apart from looking kind of odd, this implies a violation of
> encapsulation - you're passing the object to a method it doesn't have.
> It also won't play well with inheritance.
Interesting... But violating encapsulation is something I'm really
trying to avoid.
> Some better options:
>
> 4. Subclass OrigObj - can you make a subclass of OrigObj that
> implements the extra methods, then use that instead of OrigObj?
OrigObj is a CGI::Application request, I've subclassed it with a
superclass I've made for all my cgi-app stuff, that does add new
methods. But I don't want a huge object full of methods. It's the
grouping into sub objects that I'm really after.
> 5. Composition - rather than $OrigObj->ExtObj returning a single
> shared ExtObj instance could you give each $OrigObj its own instance
> of ExtObj? You mentioned the methods in ExtObj need to have access to
> the $OrigObj instance, which means either a circular reference (
> $OrigObj->{ ExtObj } is an instance of ExtObj, which itself holds a
> reference back to $OrigObj ) or passing $OrigObj explicitly to each
> method call of ExtObj. Circular refs can be OK, but it depends on your
> situation.
There will only be one $OrigObj, but many $ExtObj, not from the same
class, each different with different methods. But using the same
implementation. After creating a couple, using my example method, I
realised I would be creating a load more and hence wanting to get it
right first and posting this question. At the moment I've got ExtObj
grabbing a reference to $OrigObj when it's called:-
$OrigObj->ExtObj->new_methods;
^--- Grabs ref to $OrigObj here, saving to the blessed
hashref of ExtObj class.
> I didn't ask if you have more than one ExtObj class that you want to
> add in at the same time, or whether ExtObj::guts is fixed or
> represents one of a number of implementations of the ExtObj interface.
ExtObj::guts was just so that the new_methods didn't get exported to
OrigObj, and only the ExtObj method did.
Lyle
_______________________________________________
BristolBathPM mailing list
[email protected]
http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
