Re: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-22 Thread Manish Jethani
On 3/23/08, Jeroen Beckers <[EMAIL PROTECTED]> wrote:

[snip]
> If I want to analyze a list of items, those items must implement the correct
> interface, according to which analyzers you have added to the class. Fe:
>
> var myClass:AnalyzerBundle = new AnalyzerBundle();
> myClass.addAnalyzer(new HeightAnalyzer());
>  myClass.addAnalyzer(new LevelAnalyzer());
> myClass.analyze(new Array(item1, item2, item3));
>
> What I am looking for now, is a way to make sure that item1, item2 and item3
> all implement the IHeightItem and ILevelItem interfaces.
[snip]

There's no compile time way to do this. I would implement a
targetInterface property as part of the IAnalyzer interface.

 interface IAnalyzer
 {
function get targetInterface():Class;
...
 }

Then, in the analyze method, I'd verify the items before passing them
to the analyzers. If the verification fails, throw an error.

  public function analyze(list:Array):void
  {
 for each (var item:Object in list)
   for each (var analyzer:IAnalyzer in analyzers)
 if (!(item is analyzer.targetInterface))
   throw new Error("&[EMAIL PROTECTED]");

  ...
  }

It also depends on whether your analyzers are supposed to be able to
deal with items that don't implement their iterfaces. Can't they
simply ignore those items?


Re: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Jeroen Beckers
Hi Jethani,

I guess this would be the only proper way... Too bad I can't check it
@compile time, but I guess that makes sense ...

I'm going to go with you and do a little loop in the analyze() method and
check all the items (or part of them) against the interfaces.

Thanks for thinking with me

On Sun, Mar 23, 2008 at 7:27 AM, Manish Jethani <[EMAIL PROTECTED]>
wrote:

>   On 3/23/08, Jeroen Beckers <[EMAIL PROTECTED]>
> wrote:
>
> [snip]
>
> > If I want to analyze a list of items, those items must implement the
> correct
> > interface, according to which analyzers you have added to the class. Fe:
> >
> > var myClass:AnalyzerBundle = new AnalyzerBundle();
> > myClass.addAnalyzer(new HeightAnalyzer());
> > myClass.addAnalyzer(new LevelAnalyzer());
> > myClass.analyze(new Array(item1, item2, item3));
> >
> > What I am looking for now, is a way to make sure that item1, item2 and
> item3
> > all implement the IHeightItem and ILevelItem interfaces.
> [snip]
>
> There's no compile time way to do this. I would implement a
> targetInterface property as part of the IAnalyzer interface.
>
> interface IAnalyzer
> {
> function get targetInterface():Class;
> ...
> }
>
> Then, in the analyze method, I'd verify the items before passing them
> to the analyzers. If the verification fails, throw an error.
>
> public function analyze(list:Array):void
> {
> for each (var item:Object in list)
> for each (var analyzer:IAnalyzer in analyzers)
> if (!(item is analyzer.targetInterface))
> throw new Error("&[EMAIL PROTECTED]");
>
> ...
> }
>
> It also depends on whether your analyzers are supposed to be able to
> deal with items that don't implement their iterfaces. Can't they
> simply ignore those items?
>  
>


Re: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Aaron Miller
Polymorphisms is a run time technique. There is no way to determine a
dynamic class instance's interface at runtime. I would use a switch
statement in your AnalyzerBundle class to determine which interface an
analyzer implements and process accordingly, throwing an error on default if
necessary (realistically, you shouldn't have an unexpected interface). To
add new analyzer/interfaces, you would just have to add an item to the
switch statement and an appropriate method or class to handle it. Warning:
make sure to check extended interfaces in bottom up order.

I'm not sure if this is a generally excepted "design pattern", but it's what
I would do in this case.

Hope this helps,

~Aaron

On Sat, Mar 22, 2008 at 1:55 PM, Jeroen Beckers <[EMAIL PROTECTED]>
wrote:

>   Hi list!
>
> Situation: I have a class that analyzes stuff. There are different
> analyzing classes, suck as "HeightAnalyzer", "WeightAnalyzer",
> "LevelAnalyzer", etc. You can add an analyzer to the class by using '
> myClass.addAnalyzer(newAnalyzer:IAnalyzer)'. As you can see, there is an
> IAnalyzer interface which all Analyzer's implement. Every time you add an
> analyzer, it is added to the list using the Decorator pattern. (Every
> analyzer must analyze a list and pass it to the next analyzing test)
>
> Now, the analyzer's analyze certain items. Every analyzer requires a
> different set of methodes. The HeightAnalyzer requires a getHeight(), the
> LevelAnaylzer requires a getLevel(), etc. I want to have a different
> interface for each analyzer, so that I can easily add analyzers
> (+interfaces).
>
> If I want to analyze a list of items, those items must implement the
> correct interface, according to which analyzers you have added to the class.
> Fe:
>
> var myClass:AnalyzerBundle = new AnalyzerBundle();
> myClass.addAnalyzer(new HeightAnalyzer());
> myClass.addAnalyzer(new LevelAnalyzer());
> myClass.analyze(new Array(item1, item2, item3));
>
> What I am looking for now, is a way to make sure that item1, item2 and
> item3 all implement the IHeightItem and ILevelItem interfaces.
>
> I've found a couple of ways to do this, but none of them seemed really
> good to me. One of them was to have every Analyzer keep track of the
> interface associated with it, and check if they implement the correct
> interface, once the analyzer is called. But this would give ugly runtime
> errors...
> I'm pretty sure that it can't be done at compile time, but if anyone
> happens to know some way (hack), or a better way for the runtime errors,
> please tell me :-). All ideas are welcome
>
> Ps: I've just made up all these names, my question is about the technique
> to be used, not about the project :)
>
>  
>



-- 
Aaron Miller
Chief Technology Officer
Open Base Interactive, LLC.
[EMAIL PROTECTED]
http://www.openbaseinteractive.com


Re: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Aaron Miller
Hi Again, I'm not sure if this needs to be stated or not. But your switch
statement would look something like this.

# switch( true ) {
#   case item is IHeightItem:
# //do stuff
#   break;
#   case item is ILevelItem:
# //do stuff
#   break;
#   default:
# //do stuff
# }

I was going to mention this but forgot to add it before I hit send.

Best Regards,
~Aaron

On Sat, Mar 22, 2008 at 11:43 PM, Aaron Miller <
[EMAIL PROTECTED]> wrote:

> Polymorphisms is a run time technique. There is no way to determine a
> dynamic class instance's interface at runtime. I would use a switch
> statement in your AnalyzerBundle class to determine which interface an
> analyzer implements and process accordingly, throwing an error on default if
> necessary (realistically, you shouldn't have an unexpected interface). To
> add new analyzer/interfaces, you would just have to add an item to the
> switch statement and an appropriate method or class to handle it. Warning:
> make sure to check extended interfaces in bottom up order.
>
> I'm not sure if this is a generally excepted "design pattern", but it's
> what I would do in this case.
>
> Hope this helps,
>
> ~Aaron
>
>
> On Sat, Mar 22, 2008 at 1:55 PM, Jeroen Beckers <[EMAIL PROTECTED]>
> wrote:
>
> >   Hi list!
> >
> > Situation: I have a class that analyzes stuff. There are different
> > analyzing classes, suck as "HeightAnalyzer", "WeightAnalyzer",
> > "LevelAnalyzer", etc. You can add an analyzer to the class by using '
> > myClass.addAnalyzer(newAnalyzer:IAnalyzer)'. As you can see, there is an
> > IAnalyzer interface which all Analyzer's implement. Every time you add an
> > analyzer, it is added to the list using the Decorator pattern. (Every
> > analyzer must analyze a list and pass it to the next analyzing test)
> >
> > Now, the analyzer's analyze certain items. Every analyzer requires a
> > different set of methodes. The HeightAnalyzer requires a getHeight(), the
> > LevelAnaylzer requires a getLevel(), etc. I want to have a different
> > interface for each analyzer, so that I can easily add analyzers
> > (+interfaces).
> >
> > If I want to analyze a list of items, those items must implement the
> > correct interface, according to which analyzers you have added to the class.
> > Fe:
> >
> > var myClass:AnalyzerBundle = new AnalyzerBundle();
> > myClass.addAnalyzer(new HeightAnalyzer());
> > myClass.addAnalyzer(new LevelAnalyzer());
> > myClass.analyze(new Array(item1, item2, item3));
> >
> > What I am looking for now, is a way to make sure that item1, item2 and
> > item3 all implement the IHeightItem and ILevelItem interfaces.
> >
> > I've found a couple of ways to do this, but none of them seemed really
> > good to me. One of them was to have every Analyzer keep track of the
> > interface associated with it, and check if they implement the correct
> > interface, once the analyzer is called. But this would give ugly runtime
> > errors...
> > I'm pretty sure that it can't be done at compile time, but if anyone
> > happens to know some way (hack), or a better way for the runtime errors,
> > please tell me :-). All ideas are welcome
> >
> > Ps: I've just made up all these names, my question is about the
> > technique to be used, not about the project :)
> >
> >  
> >
>
>
>
> --
> Aaron Miller
> Chief Technology Officer
> Open Base Interactive, LLC.
> [EMAIL PROTECTED]
> http://www.openbaseinteractive.com




-- 
Aaron Miller
Chief Technology Officer
Open Base Interactive, LLC.
[EMAIL PROTECTED]
http://www.openbaseinteractive.com


Re: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Jeroen Beckers
Hi Aaron,

That's not really what I meant...

Every Analyzer implements the IAnalyzer interface with a few methods like
analyzeElements, getItemInterface, etc . The user can add as many analyzers
to the AnalyzerBundle as he wants and then give a list of elements. The way
i'm going to do it now, is have the AnalyzerBundle.analyze method check the
given items against every IAnalyzer by using the getItemInterface. Every
item must implement all the interfaces, since every item will be passed (via
the Decorator pattern) to the next Analyzer.

On Sun, Mar 23, 2008 at 7:50 AM, Aaron Miller <
[EMAIL PROTECTED]> wrote:

>   Hi Again, I'm not sure if this needs to be stated or not. But your
> switch statement would look something like this.
>
> # switch( true ) {
> #   case item is IHeightItem:
> # //do stuff
> #   break;
> #   case item is ILevelItem:
> # //do stuff
> #   break;
> #   default:
> # //do stuff
> # }
>
> I was going to mention this but forgot to add it before I hit send.
>
> Best Regards,
> ~Aaron
>
>
> On Sat, Mar 22, 2008 at 11:43 PM, Aaron Miller <
> [EMAIL PROTECTED]> wrote:
>
> > Polymorphisms is a run time technique. There is no way to determine a
> > dynamic class instance's interface at runtime. I would use a switch
> > statement in your AnalyzerBundle class to determine which interface an
> > analyzer implements and process accordingly, throwing an error on default if
> > necessary (realistically, you shouldn't have an unexpected interface). To
> > add new analyzer/interfaces, you would just have to add an item to the
> > switch statement and an appropriate method or class to handle it. Warning:
> > make sure to check extended interfaces in bottom up order.
> >
> > I'm not sure if this is a generally excepted "design pattern", but it's
> > what I would do in this case.
> >
> > Hope this helps,
> >
> > ~Aaron
> >
> >
> > On Sat, Mar 22, 2008 at 1:55 PM, Jeroen Beckers <[EMAIL PROTECTED]>
> > wrote:
> >
> > >   Hi list!
> > >
> > > Situation: I have a class that analyzes stuff. There are different
> > > analyzing classes, suck as "HeightAnalyzer", "WeightAnalyzer",
> > > "LevelAnalyzer", etc. You can add an analyzer to the class by using '
> > > myClass.addAnalyzer(newAnalyzer:IAnalyzer)'. As you can see, there is
> > > an IAnalyzer interface which all Analyzer's implement. Every time you add 
> > > an
> > > analyzer, it is added to the list using the Decorator pattern. (Every
> > > analyzer must analyze a list and pass it to the next analyzing test)
> > >
> > > Now, the analyzer's analyze certain items. Every analyzer requires a
> > > different set of methodes. The HeightAnalyzer requires a getHeight(), the
> > > LevelAnaylzer requires a getLevel(), etc. I want to have a different
> > > interface for each analyzer, so that I can easily add analyzers
> > > (+interfaces).
> > >
> > > If I want to analyze a list of items, those items must implement the
> > > correct interface, according to which analyzers you have added to the 
> > > class.
> > > Fe:
> > >
> > > var myClass:AnalyzerBundle = new AnalyzerBundle();
> > > myClass.addAnalyzer(new HeightAnalyzer());
> > > myClass.addAnalyzer(new LevelAnalyzer());
> > > myClass.analyze(new Array(item1, item2, item3));
> > >
> > > What I am looking for now, is a way to make sure that item1, item2 and
> > > item3 all implement the IHeightItem and ILevelItem interfaces.
> > >
> > > I've found a couple of ways to do this, but none of them seemed really
> > > good to me. One of them was to have every Analyzer keep track of the
> > > interface associated with it, and check if they implement the correct
> > > interface, once the analyzer is called. But this would give ugly runtime
> > > errors...
> > > I'm pretty sure that it can't be done at compile time, but if anyone
> > > happens to know some way (hack), or a better way for the runtime errors,
> > > please tell me :-). All ideas are welcome
> > >
> > > Ps: I've just made up all these names, my question is about the
> > > technique to be used, not about the project :)
> > >
> > >
> >
> >
> > --
> > Aaron Miller
> > Chief Technology Officer
> > Open Base Interactive, LLC.
> > [EMAIL PROTECTED]
> > http://www.openbaseinteractive.com
>
>
>
>
> --
> Aaron Miller
> Chief Technology Officer
> Open Base Interactive, LLC.
> [EMAIL PROTECTED]
> http://www.openbaseinteractive.com
>  
>


RE: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Rick Winscot
Aaron - you are almost there with the use of interfaces. Let's say that you
have the following interfaces for your return results.

 

IHeightResult

IWeightResult

ILevelResult

 

If you specified the a return variable as:

 

var _something:*;

 

.and functions that return the result as:

 

public function getSomething():*

{.

 

.or used event handlers as:

 

public function somethingEventHandler( event:AnalyZOR, obj:* ):void

{.

 

You can always.

 

If ( obj is ILevelResult )

  = > process as level result

Else if ( obj is IWeightResult )

  = > process as weight result

Else if ( obj is IHeightResult )

  = > process as height result

 

The trick is using the 'unspecified' type operator (asterisk) wherever you
are going to pass one of your three typed objects. One of the keys to
polymorphism is function overriding. which isn't available in AS 3.0 (you
probably found this out). So. one of the alternatives is to use the
'unspecified' identifier.

 

Rick Winscot

 

 

 

From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Aaron Miller
Sent: Sunday, March 23, 2008 2:51 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Design pattern for conditional Interfaces ?

 

Hi Again, I'm not sure if this needs to be stated or not. But your switch
statement would look something like this. 

# switch( true ) {
#   case item is IHeightItem:
# //do stuff
#   break;
#   case item is ILevelItem:
# //do stuff
#   break;
#   default:
# //do stuff
# }

I was going to mention this but forgot to add it before I hit send.

Best Regards,
~Aaron

On Sat, Mar 22, 2008 at 11:43 PM, Aaron Miller
<[EMAIL PROTECTED]> wrote:

Polymorphisms is a run time technique. There is no way to determine a
dynamic class instance's interface at runtime. I would use a switch
statement in your AnalyzerBundle class to determine which interface an
analyzer implements and process accordingly, throwing an error on default if
necessary (realistically, you shouldn't have an unexpected interface). To
add new analyzer/interfaces, you would just have to add an item to the
switch statement and an appropriate method or class to handle it. Warning:
make sure to check extended interfaces in bottom up order.

I'm not sure if this is a generally excepted "design pattern", but it's what
I would do in this case.

Hope this helps,

~Aaron

 

On Sat, Mar 22, 2008 at 1:55 PM, Jeroen Beckers <[EMAIL PROTECTED]>
wrote:

Hi list!


Situation: I have a class that analyzes stuff. There are different analyzing
classes, suck as "HeightAnalyzer", "WeightAnalyzer", "LevelAnalyzer", etc.
You can add an analyzer to the class by using
'myClass.addAnalyzer(newAnalyzer:IAnalyzer)'. As you can see, there is an
IAnalyzer interface which all Analyzer's implement. Every time you add an
analyzer, it is added to the list using the Decorator pattern. (Every
analyzer must analyze a list and pass it to the next analyzing test)

Now, the analyzer's analyze certain items. Every analyzer requires a
different set of methodes. The HeightAnalyzer requires a getHeight(), the
LevelAnaylzer requires a getLevel(), etc. I want to have a different
interface for each analyzer, so that I can easily add analyzers
(+interfaces).

If I want to analyze a list of items, those items must implement the correct
interface, according to which analyzers you have added to the class. Fe:

var myClass:AnalyzerBundle = new AnalyzerBundle();
myClass.addAnalyzer(new HeightAnalyzer());
myClass.addAnalyzer(new LevelAnalyzer());
myClass.analyze(new Array(item1, item2, item3));

What I am looking for now, is a way to make sure that item1, item2 and item3
all implement the IHeightItem and ILevelItem interfaces. 

I've found a couple of ways to do this, but none of them seemed really good
to me. One of them was to have every Analyzer keep track of the interface
associated with it, and check if they implement the correct interface, once
the analyzer is called. But this would give ugly runtime errors...
I'm pretty sure that it can't be done at compile time, but if anyone happens
to know some way (hack), or a better way for the runtime errors, please tell
me :-). All ideas are welcome

Ps: I've just made up all these names, my question is about the technique to
be used, not about the project :)

 





-- 
Aaron Miller
Chief Technology Officer
Open Base Interactive, LLC.
[EMAIL PROTECTED] 
http://www.openbaseinteractive.com 




-- 
Aaron Miller
Chief Technology Officer
Open Base Interactive, LLC.
[EMAIL PROTECTED] 
http://www.openbaseinteractive.com 

 

<><>

RE: [flexcoders] Design pattern for conditional Interfaces ?

2008-03-23 Thread Rick Winscot
I hate to be a fud... but your comment isn't true. Introspection is very
much alive in AS 3.0 and is available through... flash.utils.describeType(
yourClass ). There are also some options through ApplicationDomain. So - for
clarification. In AS 3.0, unknown/dynamic classes can be loaded at runtime,
'introspected' and compared against known interfaces for a type comparison.
Given this - it would be possible to genericize interfaces so that value
reporting is done through a common function and then to help group incoming
data have each new/dynamic object express each datagram with a 'type'
descriptor. 

Rick Winscot



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Aaron Miller
Sent: Sunday, March 23, 2008 2:43 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Design pattern for conditional Interfaces ?

Polymorphisms is a run time technique. There is no way to determine a
dynamic class instance's interface at runtime. I would use a switch
statement in your AnalyzerBundle class to determine which interface an
analyzer implements and process accordingly, throwing an error on default if
necessary (realistically, you shouldn't have an unexpected interface). To
add new analyzer/interfaces, you would just have to add an item to the
switch statement and an appropriate method or class to handle it. Warning:
make sure to check extended interfaces in bottom up order.

I'm not sure if this is a generally excepted "design pattern", but it's what
I would do in this case.

Hope this helps,

~Aaron
On Sat, Mar 22, 2008 at 1:55 PM, Jeroen Beckers <[EMAIL PROTECTED]>
wrote:
Hi list!

Situation: I have a class that analyzes stuff. There are different analyzing
classes, suck as "HeightAnalyzer", "WeightAnalyzer", "LevelAnalyzer", etc.
You can add an analyzer to the class by using
'myClass.addAnalyzer(newAnalyzer:IAnalyzer)'. As you can see, there is an
IAnalyzer interface which all Analyzer's implement. Every time you add an
analyzer, it is added to the list using the Decorator pattern. (Every
analyzer must analyze a list and pass it to the next analyzing test)

Now, the analyzer's analyze certain items. Every analyzer requires a
different set of methodes. The HeightAnalyzer requires a getHeight(), the
LevelAnaylzer requires a getLevel(), etc. I want to have a different
interface for each analyzer, so that I can easily add analyzers
(+interfaces).

If I want to analyze a list of items, those items must implement the correct
interface, according to which analyzers you have added to the class. Fe:

var myClass:AnalyzerBundle = new AnalyzerBundle();
myClass.addAnalyzer(new HeightAnalyzer());
myClass.addAnalyzer(new LevelAnalyzer());
myClass.analyze(new Array(item1, item2, item3));

What I am looking for now, is a way to make sure that item1, item2 and item3
all implement the IHeightItem and ILevelItem interfaces. 

I've found a couple of ways to do this, but none of them seemed really good
to me. One of them was to have every Analyzer keep track of the interface
associated with it, and check if they implement the correct interface, once
the analyzer is called. But this would give ugly runtime errors...
I'm pretty sure that it can't be done at compile time, but if anyone happens
to know some way (hack), or a better way for the runtime errors, please tell
me :-). All ideas are welcome

Ps: I've just made up all these names, my question is about the technique to
be used, not about the project :)




-- 
Aaron Miller
Chief Technology Officer
Open Base Interactive, LLC.
[EMAIL PROTECTED] 
http://www.openbaseinteractive.com