Wow, there's so much stuff in this thread already - I'm going to have
to spend some time responding to many of the issues raised here.
However, I'm going to start with Dave's post (because it's the closest
one to being on the mark).
On 5/13/05, Dave Carabetta <[EMAIL PROTECTED]> wrote:
At the end of the day, introducing interfaces and a concept of a null
is a massive undertaking from an engineering standpoint. Sean Corfield
has touched on this in previous threads (sorry, can't find direct
references at the moment), and, while I don't have anywhere near his
level of Java expertise, common sense dictates to me that it's
certainly not trivial.
Yeah, I've been designing programming languages and building compilers
and interpreters for much of my 25 years in IT so when I say that
adding null to a language is a big deal, I'd hope that people wouldn't
just dismiss it and say "Oh, they'd only have to change this and that
to make it work!". More on that in a minute.
Interfaces. Yes, that would be nice. For me, interfaces would be more
important than null: I bump into the lack of interfaces more than I
bump into the lack of null. And, before anyone comments on my
programming style, bear in mind I started OOP in early '92 with C++
and picked up Java in early '97 - I've built some large,
mission-critical systems including 24x7 embedded telco stuff. Yes,
I've found null very useful in a lot of that stuff but after three and
a half years of ColdFusion - all with CFCs - I haven't needed null to
the extent that it has prevented me from creating an elegant solution.
So what would it take to add null support?
First off, every single construct in CFML that does type validation
(cfargument, cffunction returntype=, cfparam, is*()...) needs to be
able to treat null as any component type. Probably need
isCustomFunction() to treat null as any function type too (see where
this gets into a discussion of semantics about what could be a
'pointer' and what does 'null' really mean?).
We've already got a null value we can return and pass around using
javaCast("null","") - yeah, some syntactic sugar here would be nice.
Then every single place where CFML looks up variables needs to change
so that the following doesn't error out:
<cfset var x = someObj.getNull() />
<cfset var y = x />
Today, that will complain that x is not defined. Similarly:
<cfset session.x = someObj.getNull() />
<cfset variables.y = session.x />
will complain that x is not defined in session.
Once that is changed, every built in function needs to be examined to
see what it should do if it is passed null - try passing
javaCast("null","") to a bunch of built in functions and see what
happens today... For most functions, passing null will probably just
throw a Java level NPE which may be acceptable behavior but some
functions will need to do something different.
Then there's cfqueryparam and how it maps null values to NULL in the
database. Any tags and functions that deal with a variable or
_expression_ by name (since they're not being passed null but when they
evaluate something they would get null - as opposed to thinking the
variable is just not defined).
That's just off the top of my head... so it would touch every piece of
type checking code and every piece of variable lookup and then there
would be all the QA and, especially, checking for backward
compatibility (in particular, behavior of isDefined() and
structKeyExists() may change because today CFMX treats a null variable
value or a null struct key value as being "not defined" / "not
present"). That latter point might make cause some subtle bugs to be
introduced in existing code (I know I have code that relies on null
values being treated as not defined for isDefined()).
Let's face the facts: CFCs, by several accounts, just are
not the "bread and butter" of what makes ColdFusion marketable.
Agreed. Of the three or four hundred thousand ColdFusion developers
out there, I'd hazard a guess that only a small percentage are
actually using CFCs. We have several thousand subscribers on cf-talk
but not even all of them are using CFCs yet. How many subscribers are
here on CFCDev? And then how many of those people using CFCs are
really trying to build complex OO stuff?
Want a comparison with, say, C++? Three million developers worldwide
and anecdotal evidence suggests that less than half of them are really
writing OO code. That's a language where classes have been available
for twenty years.
----------------------------------------------------------