> You are giving reasons that it would be hard to do it right -- > admittedly true! However the question should be: is it worth doing? > Not today or tomorrow, but whenever it makes sense for competitive, > sales and technical reasons! > Good Point.. We all love CF and CF has come a long way to a standard Web Application Server and today... even taken further J2EE Compatible...and the goodies. Well.. CF will be in the same pool competing against all the other Web Application Servers Bea's WebLogic IBM's Websphere MS .NET and some of the others..
I personally think it would be great for a CFMX(RAD) to be able to achieve some of the performance like other competitiors in the market. The combination of RAD and Performance like any of its competitors will take CFMX to No 1 Web Application Server. Joe ----- Original Message ----- From: "Dick Applebaum" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Wednesday, September 18, 2002 2:03 AM Subject: Re: Jsp Vs Cfm (CFMX) -- Test Code > On Tuesday, September 17, 2002, at 10:10 PM, Sean A Corfield wrote: > > > On Tuesday, September 17, 2002, at 09:18 , Dick Applebaum wrote: > >> But, if the problem is caused by lack of typing, it seems to me that > >> this is something MM can fix rather easily by allowing type definition > >> by those who want to do it, and generating efficient code if it is > >> present or use the current generation if it is not. > > > > Not "easily", no. Adding type specifications to a type-less language - > > especially *optional* type specifications - complicates the compiler to > > quite a degree. Every reference to a variable has to be checked for > > known > > type information and, if present, either generate the appropriate code > > or > > warn of inappropriate usage. (If not present, it generates the same > > code > > as now). Read that carefully: *every* reference. That potentially > > impacts > > a lot of places in the code generator. > > > > Sean, even I can write a pre-compile scan that builds a table of any > variables that are defined and typed -- and the a post-compile scan > that replaces the currently generated code with optimal code for any > variables that are defined. It'd be a kludge, but it would work. > (where is that old Pascal book that with the compiler example?) > > >> I think that CF would lose little and gain quite a lot if it allowed > >> an > >> optional type definition. > > > > I agree that being able to declare types in CF would be a nice > > enhancement. > > But it would be a major change to the language. > > Yes it would -- but being optional it would be transparent to those who > did not use it. > > > > >> Think of it as extending the reach of CF to places it could not go > >> before. > > > > And then folks will want bitwise operations and full Java expression > > syntax inside cfscript! :) > > > > If these operations were justified, why not (although, really, how > much demand is there for it -- we aren't using CF to write compilers, > file systems or db engines -- just how often does one use bitmaps? ). > > >> BTW, nulls should also be allowed in CF! > > > > Hah! Adding 'null' to a language that doesn't currently support it is a > > *major* change and it's mostly a run-time change. It would cause a huge > > ripple through the CF language to add null because the semantics need > > to > > be defined (in documentation!) and it could impact every single > > expression > > in the language. Consider isStruct() - should isStruct( null ) return > > false or should it just fail with a null pointer exception (which is > > what > > happens now if you manage to feed it a null). What about isDefined()? > > Right now, if you manage to create a struct key entry with a null > > value, > > isDefined( "str.key" ) is false but structKeyExists( str, "key" ) is > > true. > > In fact isDefined( "v" ) is false whenever either 'v' is not > > declared *or* > > it has a null value. > > Hah, I knew that would get you! OK, I'll drop down to Java just to > get a null. But the ability to pass a null only in cfobject would be a > start -- yes it would apply to all variable types (oh, there *are* > variable types), but the changes would be localized to the cfobject > tag, and an IsNull function that are sensitive to all variable types. > > But, null is something that CF eventually must address -- surprised > that they didn't do it in CFMX. > > Just remember that these are not meant as criticisms, but as ways to > make one of the best systems even better -- > > If we didn't care, we wouldn't bother! > > Dick > > "All the woulda, coulda, shouldas lyin' in the sun... > ..talkin' 'bout what they woulda, coulda, shoulda done. > > All those woulda, coulda, shouldas went out and hid.... > .. from one little did!" > > - Shel Silverstein > > > > > > Sean A Corfield -- http://www.corfield.org/blog/ > > > > "If you're not annoying somebody, you're not really alive." > > -- Margaret Atwood > > > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
