On 7/25/07, Muzak <[EMAIL PROTECTED]> wrote:
Well, alot depends on the context of the whole thing (the bigger picture).
If contextInfo isn't used/part of class A or B, it shouldn't even be there.
But since you said:
> object B wraps it and wants to do something context specific once
> A has finished loading
Then contextInfo should probably be a property of A or B.
IMO that doesn't break encapsulation but rather enforces it.
contextInfo is relevant to B, not A; and I agree, that doesn't break
encapsulation (it does if contextInfo is placed in A).
However, because there might be multiple outstanding requests through
B, B can't simply have a property called contextInfo (because each
request has a different contextInfo). It could conceivably have a
_map_ of contextInfos, keyed in some way to each request.
But this just seems like overkill, particularly when a simply
Delegate(handler,contextInfo) solves the problem and is a lot easier
to read.
I honestly can't understand why other people aren't tripping over this
situation; it seems an obvious problem in an environment like Flash,
where you have lots of asynchronous requests kicking around. I was
hoping there'd be a standard approach to the issue; it looks like
there isn't.
Ian
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
