I think you're running on a supposition that Macromedia "owe it" to someone to start considering *their* language as some sort of public document like I guess Sun considers the Java language to be. This would obviously be convenient for New Atlanta, as they/you could them positon themselves as something other than "a copycat of CF", which would lend them more credibility beyond "a free(-ish) version of something that's kind of like CF".
However there's no compulsion for Macromedia to do that, if they don't think that's where the want to position themselves. MM do have a group of people who - for better or worse - decide on where they're going with CFML, and I guess if you want to get on that "expert group"... Get a job at MM and get on the relevant team. Or get on the beta programme and hope like hell they listen to you (they seem to). As it stands, MM define how their language works, and New Atlanta *are* producing what amounts to a CF emulator. So it would make the most sense to emulate it as closely as possible (for better or worse). Adam Cameron Senior Application Developer Straker Interactive Ph: +64 9 3605034 Fx: +64 9 3605870 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vince Bonfanti Sent: Wednesday, 30 June 2004 1:40 p.m. To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFEXIT or CFABORT within CFFUNCTION Not necessarily. Most (nearly all) of the CFML language is well-thought out and consistent. But nobody's perfect, and the designers sometimes overlook things, and there are always implementation side-effects, and then there are just plain bugs. An "implementation side effect" is when something works the way it does not because the designer intended it to, but as an "accident" or "side effect" of the implementation, and may be something that the designer never even thought about. One of the problems with CFML is that it's not a "spec'd" language, such as JSP. With JSP, there's an "Expert Group" that defines how the language should work before anyone does any implementation. When things crop up during implementation, the designers can go back to the Expert Group and ask for a clarification. When there's a side effect or bug in an implementation, it's easy to go back to the spec and say, "See, that's how it's really supposed to work, don't rely on the side effect or bug." (BTW, I'm a member of the Expert Groups for Java Servlets and JSP). With CFML, while there's obviously a lot of thought and design that goes up front, there's no formal spec and no "expert group". As a result, side effects, and even bugs get enshrined as defacto parts of the language. Macromedia (and Allaire before them) really do themselves a disservice, because now they have to maintain backwards compatibility with the side effects and bugs. Further, when the only "spec" is the documentation, what happens when there's a discrepancy? Is it a software bug or a documentation bug? Who knows? (Have you ever heard anyone from Macromedia say they have "hundreds and thousands" of CFML pages they use as testcases on each ColdFusion release? And they say this as if it's a good thing--well, it's not. If there was a well-defined CFML spec then you could right a clear, well-defined set of testcase to definitively test each release. But there's no spec, so they--and we--have not alternative to test a release except to run every piece of CFML code we can find to see if anything breaks. This is one of the reasons CFMX took so long to deliver). So, no, it's not at all clear that blindly doing the same thing as CFMX is the most sensible thing in all cases. Vince > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Cameron > Sent: Tuesday, June 29, 2004 6:32 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFEXIT or CFABORT within CFFUNCTION > > G'day > Wouldn't be most appropriate behaviour be to do whatever CF > does in the same situation? Shouldn't that be the answer to > all questions like this, most sensibly? > > > Adam Cameron > Senior Application Developer > Straker Interactive > > Ph: +64 9 3605034 > Fx: +64 9 3605870 > Email: [EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). 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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
