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.
regards,
Muzak
----- Original Message -----
From: "Ian Thomas" <[EMAIL PROTECTED]>
To: <flashcoders@chattyfig.figleaf.com>
Sent: Wednesday, July 25, 2007 12:19 AM
Subject: Re: [Flashcoders] AS3 Events
> 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" <flashcoders@chattyfig.figleaf.com>
>> 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
_______________________________________________
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
