Well,

In transfer, I have a series of Observable events.

Now as it currently stands, if you want to Observe any of the events
in Transfer, the object that is an Observer must have a method with
given signature.

This is done by convention, and an error will be thrown at runtime if
the method does not exist, or isn't configured correctly.

Now, with interfaces, I could say, have a ITransferEventObserver (I is
a common prefix for an interface), which has the method that is
required for an event to be observed.

(In reality I would probably have one for each of the Transfer event
types, but I'll keep it simple for now).

If the Observer doesn't have the method, at runtime, when the object
is created, the developer will be told that the method is missing, and
it should be implemented.

So realistically, what are the differences? Maybe not much, maybe a lot.

On both sides, you get an error at runtime, one at when an event is
attempted to run, and one when the object is created.

*Assuming* some sort of testing approach is used (hopefully unit
testing), the two errors don't do much more than each other.  They are
both runtime, and both pretty clearly show that the method is missing.

Maybe to a new developer however, the error from a Interface is
actually clearer? Honestly, not so sure... but quite possibly.

Its not something I'm totally sold on either way, because the problem
at hand can be solved by duck typing... but maybe it will be useful in
the long run.

Mark

On 5/22/07, Barry Beattie <[EMAIL PROTECTED]> wrote:
> Maybe it is worth discussing ;)

well, it's been rumored that Sean Corfield, who "wished" it in the
first place is having very serious second thoughts... used for
good/evil, etc.


but ... what practical "pain" does it solve?

Mark, can use interfaces in Transfer? how? why?

Barney, how about you?


You are subscribed to cfcdev. To unsubscribe, please follow the instructions at 
http://www.cfczone.org/listserv.cfm

CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]




--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com


You are subscribed to cfcdev. To unsubscribe, please follow the instructions at 
http://www.cfczone.org/listserv.cfm

CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]

Reply via email to