From pmh at edison.ioppublishing.com  Wed Jan 13 10:45:40 2010
From: pmh at edison.ioppublishing.com (Peter Haworth)
Date: Wed, 13 Jan 2010 10:45:40 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
Message-ID: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>

I've just got back from New Zealand, so am a bit late in organising
the next social meeting, which is scheduled for next Tuesday,
somewhere in Bristol.

Does anyone have any venue suggestions? Otherwise, I'm likely to pick
the Royal Oak.

-- 
	Peter Haworth	pmh at edison.ioppublishing.com
"For mad scientists who keep brains in jars, here's a tip:
 why not add a slice of lemon to each jar, for freshness?"
		-- Jack Handey

This email (and attachments) are confidential and intended for the addressee(s) only. If you are not the intended recipient please notify the sender, 
delete any copies and do not take action in reliance on it. Any views expressed are the author's and do not represent those of IOP, except where specifically 
stated. IOP takes reasonable precautions to protect against viruses but accepts no responsibility for loss or damage arising from virus infection. 
For the protection of IOP's systems and staff emails are scanned automatically.? 

Institute of Physics Registered in England under Registration No 293851 
Registered Office:  76/78 Portland Place, London W1B 1NT  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.bristolbath.org/pipermail/bristolbathpm/attachments/20100113/8e5f3312/attachment.html 

From jmoverley at ladnet.org  Wed Jan 13 11:35:56 2010
From: jmoverley at ladnet.org (James Moverley)
Date: Wed, 13 Jan 2010 11:35:56 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>
Message-ID: <6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>

+1 for royal oak :D

2010/1/13 Peter Haworth <pmh at edison.ioppublishing.com>:
>
>
> I've just got back from New Zealand, so am a bit late in organising
> the next social meeting, which is scheduled for next Tuesday,
> somewhere in Bristol.
>
> Does anyone have any venue suggestions? Otherwise, I'm likely to pick
> the Royal Oak.
>
> --
> Peter Haworth pmh at edison.ioppublishing.com
> "For mad scientists who keep brains in jars, here's a tip:
> why not add a slice of lemon to each jar, for freshness?"
> -- Jack Handey
>
>
> ________________________________
> This email (and attachments) are confidential and intended for the
> addressee(s) only. If you are not the intended recipient please notify the
> sender, delete any copies and do not take action in reliance on it. Any
> views expressed are the author's and do not represent those of IOP, except
> where specifically stated. IOP takes reasonable precautions to protect
> against viruses but accepts no responsibility for loss or damage arising
> from virus infection. For the protection of IOP's systems and staff emails
> are scanned automatically.?
>
> Institute of Physics?Registered in England under Registration No?293851
> Registered Office:??76/78 Portland Place, London W1B 1NT
> ________________________________
> _______________________________________________
> BristolBathPM mailing list
> BristolBathPM at bristolbath.org
> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>
>


From pmh at edison.ioppublishing.com  Thu Jan 14 12:12:53 2010
From: pmh at edison.ioppublishing.com (Peter Haworth)
Date: Thu, 14 Jan 2010 12:12:53 +0000
Subject: [BristolBathPM] ANNOUNCE: Bristol Social: The Royal Oak,
	7pm 19/1/2010
Message-ID: <PGM.20100114121253.15286.10415@edison.ioppublishing.com>

OK then; given the short time remaining, the Royal Oak it is

7pm 19/1/2010
The Royal Oak
385 Gloucester Road
Horfield
Bristol
BS7 8TN

Join us for a pleasant evening of Perl talk (or anything else you want to
talk about), beer (or whatever you like drinking) and food (if you're
hungry). If you don't know what we look like, just look for the table with
the camels.


On Wed, 13 Jan 2010 11:35:56 +0000, James Moverley wrote:
> +1 for royal oak :D
> 
> 2010/1/13 Peter Haworth <pmh at edison.ioppublishing.com>:
> > Does anyone have any venue suggestions? Otherwise, I'm likely to pick
> > the Royal Oak.


-- 
	Peter Haworth	pmh at edison.ioppublishing.com
"Amazing! You type random strings of letters, and it does what you want!"
		-- Rhiannon Mogridge, on vi

This email (and attachments) are confidential and intended for the addressee(s) only. If you are not the intended recipient please notify the sender, 
delete any copies and do not take action in reliance on it. Any views expressed are the author's and do not represent those of IOP, except where specifically 
stated. IOP takes reasonable precautions to protect against viruses but accepts no responsibility for loss or damage arising from virus infection. 
For the protection of IOP's systems and staff emails are scanned automatically.? 

Institute of Physics Registered in England under Registration No 293851 
Registered Office:  76/78 Portland Place, London W1B 1NT  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.bristolbath.org/pipermail/bristolbathpm/attachments/20100114/5def8ff5/attachment.html 

From webmaster at cosmicperl.com  Wed Jan 20 00:57:50 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Wed, 20 Jan 2010 00:57:50 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>
	<6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>
Message-ID: <4B56550E.3060501@cosmicperl.com>

... For some reason I was thinking this meant you might actually turn up...

James Moverley wrote:
> +1 for royal oak :D
>
> 2010/1/13 Peter Haworth <pmh at edison.ioppublishing.com>:
>   
>> I've just got back from New Zealand, so am a bit late in organising
>> the next social meeting, which is scheduled for next Tuesday,
>> somewhere in Bristol.
>>
>> Does anyone have any venue suggestions? Otherwise, I'm likely to pick
>> the Royal Oak.
>>
>> --
>> Peter Haworth pmh at edison.ioppublishing.com
>> "For mad scientists who keep brains in jars, here's a tip:
>> why not add a slice of lemon to each jar, for freshness?"
>> -- Jack Handey
>>
>>
>> ________________________________
>> This email (and attachments) are confidential and intended for the
>> addressee(s) only. If you are not the intended recipient please notify the
>> sender, delete any copies and do not take action in reliance on it. Any
>> views expressed are the author's and do not represent those of IOP, except
>> where specifically stated. IOP takes reasonable precautions to protect
>> against viruses but accepts no responsibility for loss or damage arising
>> from virus infection. For the protection of IOP's systems and staff emails
>> are scanned automatically.?
>>
>> Institute of Physics Registered in England under Registration No 293851
>> Registered Office:  76/78 Portland Place, London W1B 1NT
>> ________________________________
>> _______________________________________________
>> BristolBathPM mailing list
>> BristolBathPM at bristolbath.org
>> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>>
>>
>>     
>
> _______________________________________________
> BristolBathPM mailing list
> BristolBathPM at bristolbath.org
> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>
>   

From jmoverley at ladnet.org  Wed Jan 20 15:09:38 2010
From: jmoverley at ladnet.org (James Moverley)
Date: Wed, 20 Jan 2010 15:09:38 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <4B56550E.3060501@cosmicperl.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>
	<6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>
	<4B56550E.3060501@cosmicperl.com>
Message-ID: <6b7926b21001200709y2aae2419ucefa27b4926a058c@mail.gmail.com>

Yea,... Babies introduce this "random event" quality to your life.. so
was kinda tied back home.. intention was actually to be there:
 a) there is beer involved
 b) its just round the corner
 c) its talking techie with techies :D
its full of win..

Will have to double the efforts for the next one! Im curious to what
the hell you all got for christmas!! :D

J.

2010/1/20 Lyle <webmaster at cosmicperl.com>:
> ... For some reason I was thinking this meant you might actually turn up...
>
> James Moverley wrote:
>> +1 for royal oak :D
>>
>> 2010/1/13 Peter Haworth <pmh at edison.ioppublishing.com>:
>>
>>> I've just got back from New Zealand, so am a bit late in organising
>>> the next social meeting, which is scheduled for next Tuesday,
>>> somewhere in Bristol.
>>>
>>> Does anyone have any venue suggestions? Otherwise, I'm likely to pick
>>> the Royal Oak.
>>>
>>> --
>>> Peter Haworth pmh at edison.ioppublishing.com
>>> "For mad scientists who keep brains in jars, here's a tip:
>>> why not add a slice of lemon to each jar, for freshness?"
>>> -- Jack Handey
>>>
>>>
>>> ________________________________
>>> This email (and attachments) are confidential and intended for the
>>> addressee(s) only. If you are not the intended recipient please notify the
>>> sender, delete any copies and do not take action in reliance on it. Any
>>> views expressed are the author's and do not represent those of IOP, except
>>> where specifically stated. IOP takes reasonable precautions to protect
>>> against viruses but accepts no responsibility for loss or damage arising
>>> from virus infection. For the protection of IOP's systems and staff emails
>>> are scanned automatically.?
>>>
>>> Institute of Physics Registered in England under Registration No 293851
>>> Registered Office: ?76/78 Portland Place, London W1B 1NT
>>> ________________________________
>>> _______________________________________________
>>> BristolBathPM mailing list
>>> BristolBathPM at bristolbath.org
>>> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>>>
>>>
>>>
>>
>> _______________________________________________
>> BristolBathPM mailing list
>> BristolBathPM at bristolbath.org
>> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>>
>>
> _______________________________________________
> BristolBathPM mailing list
> BristolBathPM at bristolbath.org
> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>


From webmaster at cosmicperl.com  Thu Jan 21 20:38:29 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Thu, 21 Jan 2010 20:38:29 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <6b7926b21001200709y2aae2419ucefa27b4926a058c@mail.gmail.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>	<6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>	<4B56550E.3060501@cosmicperl.com>
	<6b7926b21001200709y2aae2419ucefa27b4926a058c@mail.gmail.com>
Message-ID: <4B58BB45.5050607@cosmicperl.com>

James Moverley wrote:
> Yea,... Babies introduce this "random event" quality to your life..
>   

lol, there was a fair about of baby talk at the meet :)

> Will have to double the efforts for the next one! Im curious to what
> the hell you all got for christmas!! :D
>   

I got a large digital piano, not that I can play... yet...

Oh, and some lovely socks :)


Lyle


From rossey at gmail.com  Thu Jan 21 22:15:50 2010
From: rossey at gmail.com (Alex Ross)
Date: Thu, 21 Jan 2010 22:15:50 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <4B58BB45.5050607@cosmicperl.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com> 
	<6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com> 
	<4B56550E.3060501@cosmicperl.com>
	<6b7926b21001200709y2aae2419ucefa27b4926a058c@mail.gmail.com> 
	<4B58BB45.5050607@cosmicperl.com>
Message-ID: <26fac7821001211415y6ed77971s5f71530f78c10cda@mail.gmail.com>

Kind Regards,

Alex Ross


2010/1/21 Lyle <webmaster at cosmicperl.com>

> James Moverley wrote:
> > Yea,... Babies introduce this "random event" quality to your life..
> >
>
> lol, there was a fair about of baby talk at the meet :)
>
> > Will have to double the efforts for the next one! Im curious to what
> > the hell you all got for christmas!! :D
> >
>
> I got a large digital piano, not that I can play... yet...
>

[?] very nice. what make is it? (highly jealous)

our $bristol_bath_piano_players++; [?]



>
> Oh, and some lovely socks :)
>
>
> Lyle
>
> _______________________________________________
> BristolBathPM mailing list
> BristolBathPM at bristolbath.org
> http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.bristolbath.org/pipermail/bristolbathpm/attachments/20100121/2575496e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 111 bytes
Desc: not available
Url : http://mailman.bristolbath.org/pipermail/bristolbathpm/attachments/20100121/2575496e/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 453 bytes
Desc: not available
Url : http://mailman.bristolbath.org/pipermail/bristolbathpm/attachments/20100121/2575496e/attachment-0001.gif 

From webmaster at cosmicperl.com  Thu Jan 21 22:47:57 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Thu, 21 Jan 2010 22:47:57 +0000
Subject: [BristolBathPM] Next meeting, any suggestions?
In-Reply-To: <26fac7821001211415y6ed77971s5f71530f78c10cda@mail.gmail.com>
References: <PGM.20100113104540.15286.10413@edison.ioppublishing.com>
	<6b7926b21001130335i4d0c100bs2e16927556b0d762@mail.gmail.com>
	<4B56550E.3060501@cosmicperl.com>	<6b7926b21001200709y2aae2419ucefa27b4926a058c@mail.gmail.com>
	<4B58BB45.5050607@cosmicperl.com>
	<26fac7821001211415y6ed77971s5f71530f78c10cda@mail.gmail.com>
Message-ID: <4B58D99D.3040502@cosmicperl.com>

Alex Ross wrote:
>
>     I got a large digital piano, not that I can play... yet...
>
>
>  very nice. what make is it? (highly jealous)
>
> our $bristol_bath_piano_players++; 

It's a Casio, got it second hand on gumtree (felt guilty, they go for a 
lot more on ebay than I paid for it). I was looking at Yamahas but after 
talking to a couple of people, they said in my price range the Casios 
were probably better.

It's a digital piano/keyboard hybrid. Full 88 touch sensitive weighted 
keys, but does backing tunes and all that as well. If I had it setup 
when you gave me a lift I would have got you to come in and take a look 
at it. Need to finish the cupboards on my landing, so I can move stuff 
out of my bedroom and make space for it... It's massive!


Lyle


From webmaster at cosmicperl.com  Wed Jan 27 12:22:33 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Wed, 27 Jan 2010 12:22:33 +0000
Subject: [BristolBathPM] Extending an object with an object...
Message-ID: <4B603009.60401@cosmicperl.com>

Hi All,
  I have a main object that I don't want to just keep exporting new 
methods to. So instead I'm exporting new objects. The way I'm doing it 
is like so (cut down):-

package ExtObj;

use strict;
use warnings;

use vars qw ( $VERSION @ISA @EXPORT );

require Exporter;
@ISA = qw(Exporter);
@EXPORT = ( 'ExtObj' );

my $extobj;

sub import {
    $extobj = new ExtObj::guts;
    ExtObj->export_to_level(1, @_);
}#sub

sub ExtObj {
    unless ( $extobj->{params}->{__orig_obj} ) {
        $extobj->{params}->{__orig_obj} = shift;
    }#unless
    return $extobj;
}#sub

package Plugme::guts;

sub new {
    my $class = shift;
    my $obj = {
        params => {},
    };
    bless( $obj, $class );
    return $obj;
}#sub

sub new_methods {
    #code
}#sub

1;


Feedback and questions please.

I'm not happy with the ExtObj sub, particularly:-
    unless ( $extobj->{params}->{__orig_obj} ) {
        $extobj->{params}->{__orig_obj} = shift;
    }#unless
I'm sure there is some clever way of getting the reference to the 
original object, or at least swap this for some sort of subref so the 
unless isn't ran each time the obj is called...

This gives me $OrigObj->ExtObj->new_methods;

Hope that makes sense :-\


Lyle


From alex.francis at gmail.com  Wed Jan 27 15:24:56 2010
From: alex.francis at gmail.com (Alex Francis)
Date: Wed, 27 Jan 2010 15:24:56 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <4B603009.60401@cosmicperl.com>
References: <4B603009.60401@cosmicperl.com>
Message-ID: <16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>

On Wed, Jan 27, 2010 at 12:22 PM, Lyle <webmaster at cosmicperl.com> wrote:
> Hi All,
> ?I have a main object that I don't want to just keep exporting new
> methods to. So instead I'm exporting new objects. The way I'm doing it
> is like so (cut down):-
>
> package ExtObj;
>
...
> package Plugme::guts;
>
...
> This gives me $OrigObj->ExtObj->new_methods;
>

Confused. Does Plugme::guts inherit from ExtObj ? If so then it looks
like, given you'll only ever have one $extobj, things will only work
if Plugme::guts is the only class to inherit from ExtObj. Which would
be weird.

What's the problem you're trying to solve? "Extending an object with
an object" sounds like aggregation, or perhaps delegation. Aggregation
would just involve object A holding a reference to object B and
implementing some of its own methods by calling methods of object B;
delegation would involve object A holding a reference to object B and
passing some method calls direct to object B. The latter could be done
with an AUTOLOAD fairly sensibly.

Need more clues!

Alex


From webmaster at cosmicperl.com  Wed Jan 27 15:58:57 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Wed, 27 Jan 2010 15:58:57 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>
References: <4B603009.60401@cosmicperl.com>
	<16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>
Message-ID: <4B6062C1.5090801@cosmicperl.com>

Alex Francis wrote:
> Confused. Does Plugme::guts inherit from ExtObj ? If so then it looks
> like, given you'll only ever have one $extobj, things will only work
> if Plugme::guts is the only class to inherit from ExtObj. Which would
> be weird.
>   

Yeah, thought I hadn't outlined it properly. The $OrigObj is part of 
another package that is importing the ExtObj package, effectively:-

package OrigObj;
use ExtObj;
my $OrigObj = {};
bless $OrigObj, OrigObj;

1;

The real thing is much more complicated (it's actually CGI::Application).

With $OrigObj->ExtObj->new_methods; some of the new_methods will want to 
access $OrigObj.

My solution exports a new method to OrigObj that simply returns the new 
ExtObj object after storing the reference to $OrigObj for retrieval later.

Hope that makes more sense?


Lyle


From alex.francis at gmail.com  Wed Jan 27 17:20:18 2010
From: alex.francis at gmail.com (Alex Francis)
Date: Wed, 27 Jan 2010 17:20:18 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <4B6062C1.5090801@cosmicperl.com>
References: <4B603009.60401@cosmicperl.com>
	<16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>
	<4B6062C1.5090801@cosmicperl.com>
Message-ID: <16afc9551001270920kb0ca00bw26bab8f4181972c8@mail.gmail.com>

On Wed, Jan 27, 2010 at 3:58 PM, Lyle <webmaster at cosmicperl.com> 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?

Yes, I think I can see what you're doing - it's kind of a combination
of mixins and composition. You want to add some more methods to a
class, but the class is a bit unwieldy so you want to keep the extra
methods in a different package (and source file). The extra methods
are related to each other and it makes sense to group them together in
code and in how you call them.

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.

1. In ExtObj.pm, just declare package to be OrigObj and add your extra
methods (but watch out for name clashes - make sure warnings are
enabled). This is contrary to good practice in terms of
maintainability - you expect the definition of OrigObj to be found in
OrigObj.pm only.

2. Make OrigObj inherit from ExtObj and put your extra methods in
ExtObj. This is strictly an abuse of inheritance, because (i) ExtObj
isn't a proper class and (ii) there's no model-based justification for
saying that an OrigObj is-a ExtObj.

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.

Some better options:

4. Subclass OrigObj - can you make a subclass of OrigObj that
implements the extra methods, then use that instead of OrigObj?

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 are plenty more ways to do it, but lets see if any of those make sense.

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.

Alex

From webmaster at cosmicperl.com  Wed Jan 27 20:41:39 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Wed, 27 Jan 2010 20:41:39 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <16afc9551001270920kb0ca00bw26bab8f4181972c8@mail.gmail.com>
References: <4B603009.60401@cosmicperl.com>	<16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>	<4B6062C1.5090801@cosmicperl.com>
	<16afc9551001270920kb0ca00bw26bab8f4181972c8@mail.gmail.com>
Message-ID: <4B60A503.2080107@cosmicperl.com>

Alex Francis wrote:
> On Wed, Jan 27, 2010 at 3:58 PM, Lyle <webmaster at cosmicperl.com> 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


From webmaster at cosmicperl.com  Wed Jan 27 20:57:41 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Wed, 27 Jan 2010 20:57:41 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <4B603009.60401@cosmicperl.com>
References: <4B603009.60401@cosmicperl.com>
Message-ID: <4B60A8C5.6010901@cosmicperl.com>

Attempt to improve my original example:-

In ExtObj.pm:-

package ExtObj;

use vars qw ( $VERSION @ISA @EXPORT );

require Exporter;
@ISA = qw(Exporter);
@EXPORT = ( 'ExtObj' );

my $extobj;

sub import {
    $extobj = new ExtObj::guts;
    ExtObj->export_to_level(1, @_);
}#sub

sub ExtObj {
    unless ( $extobj->{params}->{__orig_obj} ) {
        $extobj->{params}->{__orig_obj} = shift;
    }#unless
    return $extobj;
}#sub

package ExtObj::guts;

sub new {
    my $class = shift;
    my $obj = {
        params => {},
    };
    bless( $obj, $class );
    return $obj;
}#sub

sub new_methods {
    #code
}#sub

1;



In OrigObj.pm:-

package OrigObj;
use ExtObj;
my $OrigObj = {};
bless $OrigObj, OrigObj;

1;


ExtObj only exports one method of the same name to OrigObj. That method returns an object of the ExtObj::guts class, which contains all the new_methods. Only one instance of ExtObj::guts will ever be created and used. It's purely to group similar methods together in sub objects, rather than having a huge object with lots of methods.

I'm aiming for high cohesion and encapsulation, although methods of ExtObj::guts will often have to access $OrigObj. The $extobj object of ExtObj::guts, created in the ExtObj class can only be access through the $OrigObj->ExtObj method and not directly through other $OrigObj methods. (although saying that, I think I might need to wrap "my $extobj;" and the following 2 subs in a block??).


Lyle



From alex.francis at gmail.com  Wed Jan 27 22:48:33 2010
From: alex.francis at gmail.com (Alex Francis)
Date: Wed, 27 Jan 2010 22:48:33 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <4B60A503.2080107@cosmicperl.com>
References: <4B603009.60401@cosmicperl.com>
	<16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>
	<4B6062C1.5090801@cosmicperl.com>
	<16afc9551001270920kb0ca00bw26bab8f4181972c8@mail.gmail.com>
	<4B60A503.2080107@cosmicperl.com>
Message-ID: <16afc9551001271448v33a727e6pec240ad1e0888835@mail.gmail.com>

On Wed, Jan 27, 2010 at 8:41 PM, Lyle <webmaster at cosmicperl.com> wrote:
>
> For this I can just export methods to the OrigObj's namespace.

True!

> ExtObj::guts was just so that the new_methods didn't get exported to
> OrigObj, and only the ExtObj method did.

Methods won't get exported by ExtObj unless they're listed in @EXPORT
(or @EXPORT_OK etc.). So you can do without ExtObj::guts, although I
guess its existence might serve to help avoid confusion in that ExtObj
contains a function whereas ExtObj::guts is a class.

> But I don't want a huge object full of methods. It's the grouping into sub objects that I'm really after.

> There will only be one $OrigObj, but many $ExtObj, not from the same class, each different with different methods.

> ExtObj only exports one method of the same name to OrigObj. That method returns an object of the ExtObj::guts class, which contains all the new_methods. Only one instance of ExtObj::guts will ever be created and used. It's purely to group similar methods together in sub objects, rather than having a huge object with lots of methods.
>
> I'm aiming for high cohesion and encapsulation, although methods of ExtObj::guts will often have to access $OrigObj. The $extobj object of ExtObj::guts, created in the ExtObj class can only be access through the $OrigObj->ExtObj method and not directly through other $OrigObj methods. (although saying that, I think I might need to wrap "my $extobj;" and the following 2 subs in a block??).

OK, so we want $OrigObj->ExtObj->new_methods to invoke 'new_methods'
in the class 'ExtObj::guts' but provide access to $OrigObj within the
method body.

Might not be what you're after, but here's a way with a couple of
ideas that might be useful?

ExtObj.pm
--
package ExtObj;

use strict;
use warnings;

use Carp;
use Scalar::Util qw( blessed weaken );

sub new {
    my $class = shift;
    my %args  = @_;
    my $self  = bless \%args => $class;
    weaken $self->{ OrigObj };
    return $self;
}

sub OrigObj {
    my $self = shift;
    return $self->{ OrigObj };
}

sub new_methods {
    my $self = shift;
    print "new_methods: $self->{OrigObj}\n";
    $self->some_method; # Will automatically call $self->{OrigObj}->some_method
    return;
}

sub AUTOLOAD {
    my $self = shift;
    our $AUTOLOAD;
    ( my $method = $AUTOLOAD ) =~ s/.*:://ms;
    # Automatically delegate to OrigObj if we can
    if ( $self->OrigObj && $self->OrigObj->can( $method ) ) {
        return $self->OrigObj->$method( @_ );
    }
    # Ignore calls to DESTROY, Perl generates these because of this AUTOLOAD
    if ( $method eq 'DESTROY' ) {
        return;
    }
    my $package = blessed( $self );
    croak qq{Can't locate object method "$method" via package "$package"};
}

1;
--

OrigObj.pm
--
package OrigObj;

use strict;
use warnings;

use ExtObj;

my $OrigObj;

sub new {
    my $class = shift;
    my $self  = bless {} => $class;
    $self->{ ExtObj } = ExtObj->new( OrigObj => $self );
    return $self;
}

sub ExtObj {
    my $self = shift;
    return $self->{ ExtObj };
}

sub instance {
    return $OrigObj ||= __PACKAGE__->new;
}

sub some_method {
    my $self = shift;
    print "some_method: $self\n";
    return;
}

1;

--
Test code:
--
use OrigObj;
my $obj = OrigObj::instance();
$obj->ExtObj->new_methods;


From webmaster at cosmicperl.com  Sat Jan 30 14:45:21 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Sat, 30 Jan 2010 14:45:21 +0000
Subject: [BristolBathPM] Perl 6 Discovery Workshop
Message-ID: <4B644601.2070809@cosmicperl.com>

Hi All,
  We'd been talking about this at the meetings. Things finally look to 
be moving forward. I've got the site up:-
http://www.perl6.org.uk
Feedback please.
Originally the date was planned for 20th February, but that's too short 
notice now. I've spoke to UWE and they are ok with a reschedule.
So date suggestions please and I'll check they don't clash. 27th of 
March is an open day, so that's out...


Lyle



From webmaster at cosmicperl.com  Sat Jan 30 16:50:52 2010
From: webmaster at cosmicperl.com (Lyle)
Date: Sat, 30 Jan 2010 16:50:52 +0000
Subject: [BristolBathPM] Extending an object with an object...
In-Reply-To: <16afc9551001271448v33a727e6pec240ad1e0888835@mail.gmail.com>
References: <4B603009.60401@cosmicperl.com>	<16afc9551001270724n3d0e4eev233904cf4257afdd@mail.gmail.com>	<4B6062C1.5090801@cosmicperl.com>	<16afc9551001270920kb0ca00bw26bab8f4181972c8@mail.gmail.com>	<4B60A503.2080107@cosmicperl.com>
	<16afc9551001271448v33a727e6pec240ad1e0888835@mail.gmail.com>
Message-ID: <4B64636C.5060701@cosmicperl.com>

Alex Francis wrote:
> sub AUTOLOAD {
>     my $self = shift;
>     our $AUTOLOAD;
>     ( my $method = $AUTOLOAD ) =~ s/.*:://ms;
>     # Automatically delegate to OrigObj if we can
>     if ( $self->OrigObj && $self->OrigObj->can( $method ) ) {
>         return $self->OrigObj->$method( @_ );
>     }
>     # Ignore calls to DESTROY, Perl generates these because of this AUTOLOAD
>     if ( $method eq 'DESTROY' ) {
>         return;
>     }
>     my $package = blessed( $self );
>     croak qq{Can't locate object method "$method" via package "$package"};
> }
>   

I like this, so each extension object can treat $self like the original 
object as well... I'll adapt this a little and come back...


Lyle