Very interesting. I had no idea there were 3 states. I'm glad that I specify output="false" so it's treated as if the code is on a silent tag as opposed to the other way around. Thanks for the tip!
Dave Cordes Macromedia Certified Professional 636-265-0094 (Office) 636-578-4235 (Mobile) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matt Liotta Sent: Thursday, November 13, 2003 2:17 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Native CF tags and local scope > Are you saying that you don't go through design and implementation > iterations when building software? That would make you very unusual in > the software world... ;) > I didn't state that at all. I just don't feel that CFC went through design iterations; I feel they went through implementation iterations and that makes all the difference. It is one thing to implement a design and find issues that cause you to reconsider the design. It is completely different to keep making changes to the implementation without revisiting their impact on the design. Obviously, I don't have any insight into what the actual process was since I was not part of the CFMX team. However, based on my interaction with CFMX during the alpha and beta periods I feel pretty confident that CFCs were a work in progress up till the very end. > I agree that the pseudo-constructor idea was less than ideal but most > folks seem to be standardizing on init() as a constructor and only > using the pseudo-constructor for bare bones default value > initialization (like other languages allow initial values to be > specified for instance variables). Hopefully we'll get a fully-fledged > constructor notation in a forthcoming version of CFMX. > > I'm not quite sure what you objection to the output attribute is - > could you elaborate? > Two reasons, first the application of tri-state logic to a boolean attribute and second the implicit invocation of tags. Those reasons seems vague and confusing until one really looks at what the output attribute actually does. I'll admit I never really looked at it until recently because I thought I had a good idea of what it did. I was wrong and based on my conversations with other CFers most people don't fully understand what the output attribute does. With that said, let me explain what it does. If the output attribute is specified as yes/true then the function body is treated as if it is in a cfoutput tag. In other words, the cfoutput tag is implicitly invoked. On the other hand, if the output attribute is specified as no/false then the function body is tread as if it is in a cfsilent tag. Again, the cfsilent tag is implicitly invoked. I don't like implicit invocation of tags at all. I believe that if a developer wants the function body to be in a cfoutput or cfsilent tag then the developer should place those tags there. It makes the code more readable and maintainable. It also allows for the use of both the cfoutput and cfsilent tag in the function body. The above explains the second reason, but what about this tri-static issue I mentioned? Well if you read the above you can see how the function body is treated differently depending on the value of the output attribute. In fact, the above mentions to specific cases, which is inline with a boolean attribute since a boolean represents one of two states. However, that is not the case with CFMX as the output attribute is optional and doesn't default to a value. As it turns out, if the output attribute is not specified then a third state occurs. Specifically, the CFML in the function body is treated normally i.e. as if it is not in a cfoutput or cfsilent tag. Thus, my point that the output attribute is a tri-state boolean. How many people were aware of the above? It doesn't matter really, what matters is how many weren't aware of it. If a developer is not aware of how the output attribute works then the assumption as to how CFML works in a function body could be wrong thus decreasing readability and maintainability. > Well, just because you can't imagine it doesn't make it less true :) > Agreed > I would like to see: > a) interfaces / implements > b) an integrated constructor notation > c) null > Me too! > I can live without the second item since I have adopted a style that > works much the same as 'real' constructors: createObject().init() > I disagree. > So, yeah, even as an OO language diehard (eight years on the C++ > standards committee and doing hardcore C++ development, nearly seven > years of Java development), I find CFMX pretty good for OO > development. > Well I think that without interfaces or multiple inheritance CFCs don't offer the capabilities most OO people expect. Matt Liotta President & CEO Montara Software, Inc. http://www.MontaraSoftware.com (888) 408-0900 x901 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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 word '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]
