On 10/13/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
----------------------------------------------------------Hopefully this will go through...
The problem is with the way CFML is compiled. You can't make those
compile-time checks work consistently, because changing a one class
doesn't require recompiling other dependant classes. In other words,
CF doesn't recompile a CFC that extends another CFC when that second
CFC gets recompiled. Therefore your "claim to implement" status would
be invalid as soon as that happened in the same scenario with
interfaces rather than inheritance.
This is why I suggested that the improved error messaging be included. My thinking is/was while its not a perfect solution the object at least one time in its life it passed the test of implementing that interface. However I hadn't even considered dynamically added methods to meet the interface which would totaly screw things up (as you point out).
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
