No, I don't suppose Macromedia "owes" anyone anything. I think they're doing themselves and their customers a disservice by not tightly specifying the CFML language (and I've had conversations with people in Macromedia who agree with this view). That it causes pain for New Atlanta is incidental and no concern of theirs. Of course there's no compulsion for Macromedia to anything that's not in their best interests, and I've never suggested otherwise.
I have great respect for Macromedia's engineers based on their work (CFMX) and the few I know personally. But when they do something that looks like a mistake we're not going to propagate that mistake into BlueDragon. This thread started when I sought the opinions of the best group of experts I could find as to whether this looked like a mistake to them or not. I was glad to get those opinions (I learned something), and not a chorus of "just do whatever CFMX does." Regards, Vince > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Cameron > Sent: Tuesday, June 29, 2004 10:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFEXIT or CFABORT within CFFUNCTION > > 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]
