> to a point. Passing attributes by name worries me and goes against the way I > work. This tightly couples the calling code to the tag. Sure that's how tags > usually work but > *tags != functions != fullyReusableCode*.
CFMX is not a real object-oriented language. Nor does a web app written using HTML really fall into an MVC pattern. My concern with what you have suggested is that the changing of parameter names is not something that should happen on a regular basis. Generally you should work out your API (which includes the names of the parameters for documentation purposes if nothing else) and stick to that API (extending it - rather than modifying it - over time). The real plus you get by naming the parameters and not just passing a list is the you can use CFARGUMENT to validate your data types. Even when I was programming in a full C++ environment, the parameter names to all the methods never changed once an API was agreed to. I always try to build my UDF's using CFFUNCTION and CFARGUMENT and then throw in a CFSCRIPT wrapper in there because I get better type checking. I think this outweighs any shortcuts that you can get by using a list of values that can't be type checked. Consider this scenario..... You have created a CFC (or an object in another language - like C++ or C#) and you have settled on a get/set methodology and full data hiding of your variables. You have also settled on all the name of the get/set methods that access the infternal member variables. Would you change the names of those methods mid-stream during development? Or would you create a new method? You might do either. In the first case you would simply wear the cost of having to go and transform all the old calls into the new calls. In the second, you would accept that you had both "old" and "new" calls and would ensure you used only the new calls from that point on. Now - I am not saying every time you change the name of a parameter you should create a new method - just using that as an example. The real issue with the type of loose coupling you are proposing is that it relies heavily on remembering the order of the parameters. It is "looser" coupling - in a tag based sense - to just name the attributes/parameters and not have to worry about the order. In one way or another you are "coupling" even if you think you aren't. Using the list of parameters, the coupling is actually tighter than using the attribute method (because you have to explicitly remember the order) Also - I beg to differ on your statement: > *tags != functions != fullyReusableCode*. Tags (in the sense of how they are used with CFIMPORT) are basically functions. You have a known set of inputs, and a mechanism of output (either through the TAG literally ouputting something, or by setting a variable back in your caller space. And a function can be fully reusable code if it is written correctly. It depends on the purpose of the function. Therefore, a TAG (done with CFIMPORT or as a CFMODULE) can easily be fully reusable code. Before UDF's and CFC's that is how I made reusable code with Cold Fusion. But, in the end, you have to go with a style that will be comfortable for you. Passing values in a list though would not be considered best practice. Gary Menzel Web Development Manager IT Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street BRISBANE QLD 4000 PH: 07 333 44 828 FX: 07 3834 0828 **************************************************************************** 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/
