1) Stop calling it "data hiding". Call it encapsulation. Then go find
articles that tell us why encapsulation is bad. Otherwise, you expect us
to just take your word for it?

2) If you can understand that "$" is not a good way to start a variable
name then I really think all hope is lost. You know what you should use
to distinguish between a variable name and a method name? The NAME.
Method names have verbs in them... getSomething, doSomething,
listenForSomthing. Variable names do not. Using a $ to denote something
says that you are unable to properly name your methods (or variables).

3) I think most of use are aware of the language we're working with.
CFCs are implemented different from other languages... but you enjoy
going against a consensus as to what "best practice" means in terms of
CFC development. That's a GREAT reason to not use your tool... not only
is the implementation terrible, but the author refuses to acknowledge
it.

4) I threw up into my mouth when I read this "argument". How the *&^@
is creating an instance of a CFC "dynamic linking". <cfinclude/>'ing a
function library might be considered dynamic linking, but not creating a
CFC instance that has it's own lifespan. You only prove that you have no
idea how CFCs work... how are we supposed to take your tool seriously
when you don't even understand the programming language you wrote it
in.

5) I consider CFSqlTool proof that not everyone should contribute their
work to others.

I won't even address the incredibly asinine comment about Mach-ii's
config file...

-Dave



>>> [EMAIL PROTECTED] 10/27/2005 8:40:28 PM >>>
Ok, let's talk about CFSQLTool any why you disagree.

First of all, CFSQLTool is a set of wizards that generate SQL code. 
Only one wizard generate a CFC for dynamic queries that use this 
scope variables. Other wizards deal with stored procedure generation 
and CFC for stored procedures. Mostly CFSQLTool is a design tool not 
only a code generation tool. For example it built a CFC for all the 
system stored procedures. The main design interface is a speadsheet 
of checkboxes. This design interface allows a CRUD designer to build 
multiple functions at the same time.

1. Yes, I disagree with the necessity to use data hiding for every 
purpose. The fact that I do not subscribe to data hiding as being OO 
critical is something others in OO think as well. I do not think data 
hiding is bad, it has a place. Some of you choose to use it, find. 
But, not using it not bad OO either. Data hiding for everything is 
the red herring of OO.

2. About the $ sign. The problem with CFCs is not being able to 
determine variable names from function names. The $ is simply a 
semaphore meaning variable names. If you know any computer history, 
the $ is one of a few characters often treated a alpha-numeric. Your 
objection may be because you dislike Basic.  Some programmers use the 
_ underscore to prefix label private variables. I suppose because it 
is a private variable the _ is more acceptable than the $. The 
objection is an emotional bias, not a compelling computer science
argument.

3. Take a look at a CFC. First of all it is ColdFusion, it is not 
Java, it is not C++, is not C#. It is ColdFusion. This forum is about 
CFC. and writing good CFCs. The code generated by CFSQLTool is 
excellent ColdFusion.  The code is all open source, so if you want 
add other features, like data hiding. Go ahead.  Some may disagree 
with the construction of the code, fine. But to say CFSQLTool does 
not follow OO best practices, and so don't use it, is childish 
prattle from people who should know better.

4. Invoking a CFC is conceptually the same as a linked library. The 
cfinvoker or createobject is another name for a dynamic linker. Don't 
get confused on this point. Linking is not OO design or programming. 
While the linker itself may use some OO techniques, it is still just 
a linker. One  feature of ColdFusion is how well the linking works. 
This scope variables are a benefit of CFCs not a curse.  With 
CFSQTool wizard for dynamic SQL CFUD function, I use the feature when 
building a data access layer. Within each CFC that contains the CRUD 
functions for a table, the table's column names are reversed 
engineered to this scope. That means the memory space to the column 
names variables happen at link init time. No extra get/set functions 
are necessary. It is there ready for use. It provides direct access 
which works great at the data access layer.

5. CFSQLTool itself is a technical demonstration of many of the 
features of SQL with ColdFusion. Consider it a proof of how well this 
scope variables work with CRUD for data access.

Ok I don't mind constructive arguments for points you disagree. But 
don't dismiss someone's work or contribution because you don't like 
the results. I have never said how bad a design Mach was because I 
disagree with the use of XML as poor excuse for something that should 
have been in a database.

Joseph

-----------------------------------------------------------------------
http://www.switch-box.org/CFSQLTool/Download/ 

Switch_box                      MediaFirm, Inc.
www.Switch-box.org              Loveland, CO  USA



----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm 

An archive of the CFCDev list is available at
www.mail-archive.com/[email protected] 



-----------------------------------------
CONFIDENTIALITY NOTICE: This email and any attachments may contain
confidential information that is protected by law and is for the sole
use of the individuals or entities to which it is addressed. If you are
not the intended recipient, please notify the sender by replying to
this email and destroying all copies of the communication and
attachments. Further use, disclosure, copying, distribution of, or
reliance upon the contents of this email and attachments is strictly
prohibited. To contact Albany Medical Center, or for a copy of our
privacy practices, please visit us on the Internet at www.amc.edu.



----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to