> Can anyone explain to me the benifits of declaring a variable before
> it gets used arpart from if you are wanting to specify a value type
> faor the variable? eg number, struct ect
Adherence to strict and formal coding standards that have proven, over time, and across many languages, to save money and reduce coding errors.
Some of us have been doing this (writing code) for a very long time and know that being forced to declare variables before using them helps root out logic errors. Noone is saying "force" everyone to do it - but those of us who have the experience of the benefits we gain (less errors in our code or easier to find bugs) would like the option to do it.
Don't want to do it? Then you don't have to. But it would be very nice if the language supported it natively. If it was supported in the language natively, I would turn it on tomorrow and insist my staff and contractors declare everything up front.
On a separate point, I dont see the ability to force variable declaration as being an OO feature. It is a very useful mechanism that has been lost in many scripting languages. Once again - let those that want it have it, and those that dont leave it disabled.
And I also disagree that you "cant" do OO in a tag-based environment. You can - you can do anything as long as you have a consistent mechanism to implement it. I previously built properly enforced OO tags in Cold Fusion long before they came up with <CFCOMPONENT>. Admittedly, I had to have a rule that said "You must use these tags" - but that is all a methodology is in any case.
The benefit of Cold Fusion being tag-based is in the fact that the "syntax" of your whole page is basically the "same". You have "commands" in angled brackets, and "attributes" as "variable=value" pairs. You arent forced to "switch" to a more traditional syntax (as is used in <CFSCRIPT>) but can do if you so choose. The tags are just a syntax. These days, CFMX compiles your code to Java. So there is no reason why it can't map it's syntax accordingly.
CMFX brings additional benefits over other platforms (such as ASP and PHP) in that you can easily build additional tags into the language (using <CFIMPORT>) and these can either be Cold Fusion OR Java!
Who would argue that <CFFUNCTION> is a bad addition to Cold Fusion?
Should we ask MM to remove the "type" attribute from <CFARGUMENT> so that our code doesn't force us to send over the correct type?
I dont think anyone would want either of the above.
So - why shouldn't we be asking for other functionality that has existed for a long time in other programming languages that DOES support good coding methodologies?
BTW: The <CF_STRICT> example mentioned would still perform as required, and highlight that there was something wrong in the code (ie. that the "colour3" variable had not been declared). The programmer can then try and work out where the "typo" is and fix it. And, in the end, that is what the whole exercise was about - helping to automatically detect incorrectly typed variable names (because Cold Fusion doesnt support that).
BUT....... stay tuned for another posting and how it IS possible to do the same thing without using any additionally defined tags.
Regards,
Gary Menzel
****************************************************************************
If this communication is not intended for you and you are not an authorised
recipient of this email you are prohibited by law from dealing with or
relying on the email or any file attachments. This prohibition includes
reading, printing, copying, re-transmitting, disseminating, storing or in
any other way dealing or acting in reliance on the information. If you
have received this email in error, we request you contact ABN AMRO Morgans
Limited immediately by returning the email to [EMAIL PROTECTED]
and destroy the original. We will refund any reasonable costs associated
with notifying ABN AMRO Morgans. This email is confidential and may contain
privileged client information. ABN AMRO Morgans has taken reasonable steps
to ensure the accuracy and integrity of all its communications, including
electronic communications, but accepts no liability for materials
transmitted. Materials may also be transmitted without the knowledge of ABN
AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not
accept liability for the results of any actions taken or not on the basis
of the information in this report. ABN AMRO Morgans Limited and its
associates hold or may hold securities in the companies/trusts mentioned
herein. Any recommendation is made on the basis of our research of the
investment and may not suit the specific requirements of clients.
Assessments of suitability to an individual's portfolio can only be made
after an examination of the particular client's investments, financial
circumstances and requirements.
****************************************************************************
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
- [cfaussie] RE: OT: Force variables to be declared Steve Onnis
- [cfaussie] Re: OT: Force variables to be declared Vaughan Allan
- [cfaussie] Re: OT: Force variables to be declared gary menzel
- [cfaussie] Re: OT: Force variables to be declared Steve Onnis
- [cfaussie] Re: OT: Force variables to be declared Darren Tracey
- [cfaussie] Re: OT: Force variables to be declared gary menzel
- [cfaussie] Re: OT: Force variables to be declared Mark M
- [cfaussie] Re: OT: Force variables to be declared Steve Onnis
- [cfaussie] Re: OT: Force variables to be declared gary menzel
