Yes, but if you declare your returntype to be 'null', then you can't return anything else. The benefit of null isn't that it's a special type, but rather that it's an example of EVERY type.
And you're right, null isn't needed by CF at all, because it is loosely typed. However, since MM started to expose some strongly-typed characteristics, it would be very nice if they exposed null as well. You don't have to use returntypes on CFFUNCTION, or type on CFARGUMENT; you're free to keep CF entirely loosely typed. But there's a reason that most languages designed for large-scale system have typeing in them. Compile-time (or develop-time, if you've got a decent IDE) error checking is an enormous help to the developer, because it narrows down a lot of errors without having to go through an actual deploy-run cycle. CF will never have that, since it doesn't compile, but the ability to do typechecking (like you would with a compiler) at runtime in addition to normal in-code checking can help you narrow bugs in the same way. So there's a strong case for using strong-typeing where you can, especially in complex systems or integrated systems where different pieces come from different places, and the adherance to defined interfaces is important. Much easier to do that checking with the compiler rather than manually coding checks all over the place. So that's the case as I see it for leveraging the strongly-typed characteristics of what is primarily a loosely-typed language. Certainly not a deficit, but it definitely is a case of giving a tool only partially capable of the task it's designed for. cheers, barneyb On 5/12/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote: > Barney... > > I get your point, but I wonder... and prepare yourself for YACFOOWA (yet > another cf-oo work-around). > > Why note just have a CFC called... null.cfc. If you need a standard, > consistent value to test against perhaps expecting the language to provide > it by default isn't always the answer. > > If you had a null.cfc, you could actually USE type="null" or > returntype="null" in your CFC code. I'm not sure I understand the need for > making CF into something that it isn't, wasn't, and really probably never > will be. I can see adding interfaces being as easy as adding an > implements="" attribute to a CFC... but adding types to a loosely typed > language strikes me as an odd fix to a non-problem. > > Maybe I'm missing something... if so, please point it out. I just see many > of these things that people are calling "deficits" as part-and-parcel to the > strength and core values of the language: flexibility and a focus on runtime > over compiletime. > > Just my two cents since we're on the topic. > > Laterz! > > J -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- 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]
