Tiz a puzzler, though, where to stop... what's "enough" when it comes to making CFC's follow an OO paradigm. And, depending on how it's done, what impact does it have on those who just want to use CFCs for handlers in a Fusebox app and not go full-blown OO? I guess it wouldn't really matter...
Just so I'm clear, though, you're talking about being allowed to return a null when the returntype="someCFC" so that you can handle a situation where someCFC hasn't been defined, yes? That is, if I have a sessionFacade call to sesFacade.getValue("cart") and session.cart is undefined as of that moment, I can return a null... or if it is defined then I can return the cart instance... sort of an implicit or: [returntype="shoppingCart" (or null)].
Laterz,
J
On 5/12/05, Hal Helms <[EMAIL PROTECTED]> wrote:
Jared,
The problem is that I *want* to specify the type I expect to return. It's only in those cases where I can't return it that I need a null value that will fulfill the contract for any reference type (class or interface). So specifying "null" would be no better than specifying "any".
See how that works?
--
---------------
-------------------------------------
Buy SQLSurveyor!
http://www.web-relevant.com/sqlsurveyor
Never make your developers open Enterprise Manager again. ----------------------------------------------------------
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]
