Is this in response to the Null Object discussion? If so, I don't see how
it's related. In fact, in this thread, I've been taking the stance that
ColdFusion does not need all these things, though some of them would be
nice.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Hal Helms
> Sent: Thursday, May 12, 2005 9:04 PM
> To: [email protected]
> Subject: RE: [CFCDev] Null values (was CFC wish-list)
> 
> Hey, I've got an idea! Let's find a language that has...
> a. constructors
> b. method overloading
> c. interfaces
> d. compile time type checking
> e. checked exceptions
> f. null value
> g. static methods
> h. constants
> i. ability to finalize a method from being overridden and a class from
> being
> extended
> j. a huge library
> k. tons of free, really useful adjunct software
> 
> Then, if only it would interface with ColdFusion.
> Oh well, a man can dream...
> 
> Seriously, this is why I so strongly recommend using Java for model
> components (as in model-view-controller), where it excels and using
> ColdFusion for view and possibly controller stuff, where it excels. I
> think
> that's a much better solution than trying to convince Adobe to java-ize
> ColdFusion.
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Ben Rogers
> Sent: Thursday, May 12, 2005 8:24 PM
> To: [email protected]
> Subject: RE: [CFCDev] Null values (was CFC wish-list)
> 
> There is a pattern called "Null Object", if I remember correctly. I use it
> quite a bit, especially in regards to security. The component can either
> be
> the same component that you usually return or a completely separate
> component which implements the same interface.
> 
> For instance, if you're building a security system, you don't want to do
> this everywhere:
> 
>   <cfif isUserAuthenticated() and Session.User.IsUserInGroup(Group)>
>     ...
>   </cfif>
> 
> It's much cleaner to use the Null Object pattern and have a User component
> that always returns "false" when IsUserInGroup() is called. When the user
> logs in, the Null Object is either replaced with a fully initialized
> object
> that knows what to answer when IsUserInGroup() is called. Or, the User
> component could double as the Null Object itself and the default answer to
> IsUserInGroup() is always "false". Either way, your code looks like this:
> 
>   <cfif Session.User.IsUserInGroup(Group)>
>     ...
>   </cfif>
> 
> However, if you have to use two separate components, then they will have
> different names and, as a result, the returntype attribute will need to be
> set to "any". So, it doesn't solve much in the way of type checking.
> 
> Ben Rogers
> http://www.c4.net
> v.508.240.0051
> f.508.240.0057
> ________________________________________
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Jared Rypka-Hauer - CMG, LLC
> Sent: Thursday, May 12, 2005 7:46 PM
> To: [email protected]
> Subject: Re: [CFCDev] Null values (was CFC wish-list)
> 
> 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
> On 5/12/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> > In many instances, allowing functions to return null values just shifts
> the
> > problem or, at least, the responsibility. This is why we so many null
> > pointer exceptions from Java and C#. They are proper OO languages
> returning
> > null values that the consumer is unprepared to handle.
> 
> I HAVE to respond this statement.��Having or not having null doesn't
> affect this issue at all.��If i have null, I return it.��If I don't
> have null, I return "something" (like the empty string).��In either
> case, the calling code needs to be able to handle both scenarios.
> Having null makes this easier, because you have a specific value to
> test against, and more importantly, it's a value that cannot be
> confused with any other value.
> 
> 
> 
> --
> ---------------
> -------------------------------------
> 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]
> 
> 
> 
> ----------------------------------------------------------
> 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]
> 
> 
> 
> 
> 
> ----------------------------------------------------------
> 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]




----------------------------------------------------------
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]


Reply via email to