Stevan Little <stevan.lit...@iinteractive.com> writes:
> On Jul 26, 2009, at 5:06 AM, Daniel Pittman wrote:
Thank you very much for your response. I really appreciate your taking the
time to talk to me about this.
[...]
>> Hmmm. In writing this all down I had to think about it, and it occurs to
>> me that I might be facing this problem because of a higher level design
>> decision.
>>
>> At the moment I create one attribute each time a "stage" is created on the
>> class; the methods in the role then look those up using the MOP by name in
>> order to obtain the internal implementation.
>
> This sounds wrong unless you are creating an anon-class for each
> instance. Otherwise your class will just keep getting attributes added to it
> that all instances share (even if they have different "stage"s).
Mmmm. On reflection, I made the wrong call in making up an example rather
than just talking about the code I am writing directly, I think.[1]
So, in this case what I am implementing is a "publish/subscribe" extension to
Moose, allowing classes to add "signals" and, correspondingly, subscription to
those signals on instances of the classes.[2]
So, to lay out that question again:
What I want to do is create an arbitrary number of signals associated with a
class; they behave more or less like the slots of a class — notably, adding
one to an immutable class would be an error, as they form part of the ABI of
the object.
Given that I am happy with the behaviour being modeled on MOP attributes,
since it will be (IMO) less surprising to folks using the code.
>> I could, I guess, replace that with a single attribute containing a hash,
>> mapping names to "stage" instances. The sing and dance methods would then
>> need to do a hash lookup in a know attribute, so the entire helper could be
>> eliminated...
>
> This sounds a lot saner to me.
I am starting to suspect that this is the right strategy. My logic for using
individual attributes for each signal was that it gave me, for free, things
like the error checking when mutating an immutable object to create a new
signal.
I suspect that, despite being class-level features, having to jump through
these hoops is a sign that the strategy is incorrect.
[...]
> It is a pretty good read even if it is not what you are looking for.
Thanks for the pointer; that is useful, and interesting.
Daniel
Footnotes:
[1] Being as I don't like talking about unreleased code I intend to write
but that may never get past vapour, I figured this was easier.
[2] Initially, only in-process, synchronous callbacks, but my plan is to make
the framework sensibly easy to extend to distributed, asynchronous or
out-of-process messaging or pub/sub systems; I anticipate needing one of
those at work in the next while for which this would be suited.
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
