Hi Ian, Been thinking about this a bit more and you're correct, contextInfo doesn't belong in class A and I'd go for storing a list of contextInfos in class B.
regards, Muzak ----- Original Message ----- From: "Ian Thomas" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 25, 2007 10:14 AM Subject: Re: [Flashcoders] AS3 Events > 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 _______________________________________________ [email protected] 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
