Muzak,
Thanks for that.
But to me, that breaks encapsulation - it assumes that A _knows_ it
might be used in such a manner. What if you're writing to an API which
doesn't?
One of my stated requirements - as above - would be to achieve this
without A having to be modified/aware of it's potential usages.
Also - you could indeed create a contextInfo field on A, which would
be an anonymous object (i.e. typed as Object or *, because A shouldn't
know what that field is to be used for). But then that breaks
type-safety (which is the same argument as people have used for not
using a Delegate equivalent) and also, it means that you can only have
one request at a time running through A.
So - yes, your solution would solve the specific instance I gave, if
I had control of A. But it doesn't solve the general situation for all
cases, I'm afraid. I'm looking for a 'how are these things normally
handled' solution that'll apply generally.
Ian
On 7/24/07, Muzak <[EMAIL PROTECTED]> wrote:
an "A" instance should have a property that holds the contextInfo value.
class B {
function loadSomethingAndProcessIt(url:String, contextInfo:Object):void {
var a:A = new A();
a.contextInfo = contectInfo;
a.addEventListener(Event.COMPLETE,onALoaded);
a.loadSomething(url);
}
function onALoaded(event:Event):void {
var a:A = event.currentTarget as A;
trace(a.contextInfo);
}
}
regards,
Muzak
----- Original Message -----
From: "Ian Thomas" <[EMAIL PROTECTED]>
To: "Flashcoders mailing list" <[email protected]>
Sent: Tuesday, July 24, 2007 6:12 PM
Subject: [Flashcoders] AS3 Events
> Hi all,
> I'm in the process of converting a quite extensive code framework
> from AS2 to AS3, and I've got a 'how do you cope with this situation?'
> question.
>
> I understand events, event listeners, EventDispatcher etc., but I'm
> missing a trick somewhere (probably from my historical use of Delegate
> with additional params).
>
> Say we have object A, which supports the following:
>
> A.addEventListener(type:String,handler:Function);
> A.loadSomething(url:String); // Dispatches Event.COMPLETE when done
>
> and object B wraps it and wants to do something context specific once
> A has finished loading:
>
> (pseudo-AS3!)
>
> class B
> {
> :
> function addEventListener(/as per usual/);
>
> // Dispatches MyEvent.ITSOVERWITH when done
> function loadSomethingAndProcessIt(url:String,contextInfo:Object):void
> {
> var a:A=new A();
> a.addEventListener(Event.COMPLETE,onALoaded);
> a.loadSomething(url);
> }
>
> function onALoaded(event:Event):void
> {
> var a:A=A(event.target);
> // Process the results of A being loaded
> // : blah
> // then:
> dispatchEvent(new MyEvent(MyEvent.ITSOVERWITH,someDataIGotFromA));
> }
> }
>
> It doesn't really matter what events either are firing; what does matter is
that
> calling loadSomethingAndProcessIt() is both asynchronous and atomic
> i.e. multiple loadSomethingAndProcessIt() calls could be running at
> the same time on the same B.
>
> What I'm trying to do is to find a sane, 'generally accepted' way to
> get information from loadSomethingAndProcessIt() to onALoaded()
> without A being aware of it at all. So to access the contextInfo
> variable from within onALoaded().
>
> What I'd have done in AS2 is to use an extended Delegate (or Proxy) -
> the listener would have been:
>
>
a.addEventListener(Event.COMPLETE,Delegate.create(this,onALoaded,contextInfo));
>
> Which works fine.
>
> Now, I've written the equivalent of that sort of Delegate/Proxy for
> AS3, and it works perfectly well and does the trick. However, that
> method appears to be Frowned Upon by the community, for reasons which
> escape me. So I guess my question is:
>
> - Why, in AS3, is my equivalent of using Delegate Not The Done Thing?
> (Someone mentioned type-safety; and yes, at compile time, you'll lose
> type safety)
> - How else would you do it? What's the 'standard' approach?
>
> This situation comes up a lot - really, a huge number of times - in
> our code frameworks. This may be because they take the wrong approach
> - perhaps I can't see the wood for the trees.
>
> For clarity, we can't just store contextInfo inside B, as there may be
> multiple requests. We could conceivably store a look up table in B
> with various contextInfos tied to varies requests to A, but that's
> just overkill.
>
> Thoughts?
>
> 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
_______________________________________________
[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
