On 2005-07-05, Michael Peters <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
>> On 2005-07-05, Michael Peters <[EMAIL PROTECTED]> wrote:
>>
>>>>I think you are wrong. Looking at the source code of new(),
>>>>
>>>>We can see the object creation:
>>>>
>>>> # Create our object!
>>>> my $self = {};
>>>> bless($self, $class);
>>>
>>>Right, but how do you register a callback for init on this newly blessed
>>>object? You won't see it until after the init hook is already called.
>>
>>
>> Maybe /I'm wrong here/ but can't you do this 'using' a plugin that
>> registers a callback at init as part of the import process?
>
> The import just has access to the class name, not the
> (as-yet-not-created) object.
>
>> It doesn't matter that the object doesn't exist at import time because
>> you aren't doing anything with it. You are just providing a pointer to a
>> code reference, that happens to be an object method call.
>
> The fact that the object doesn't exist doesn't matter to the sub being
> registered as a callback since it will exist when the callback is run.
> But it does matter the add_callback() method itself.
>
> You can never do
> $self->add_callback( init => sub {...})
> where $self is an object and have that sub get executed. It will only
> get executed if $self is a class name.
I see what you are saying. The callback will have to be registered by
a class method to be run at init time.
But is that a problem if the code that is eventually run is an object
method?
[ thinks. birds chirp. ]
Is the problem that in a persistent environment you would possibly add
run modes to all modules using some class, inside of adding methods
private to an object?
I sense our conversation has a circular and about is about to reboot.
Mark
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
