Re: [CFCDev] "this" scope vs. unnamed

[Matt Liotta]

I wasn't advocating anything. I was simply responding to the idea that 
public fields in objects are bad; they aren't. Further, my example of 
providing constants holds whether or not CFML can enforce constants 
because the advantage of constants in my example is not that they are 
in fact constant, but the fact that they are predefined pieces of data 
that can make using an object easier.

-Matt

On Wednesday, July 30, 2003, at 05:37 PM, Nathan Dintenfass wrote:

OK -- but let's not confuse the matter here.  Are you advocating 
storing
things like "firstName" as public data members?  If not, you might 
want to
clarify since the people asking the questions aren't thinking about
comparing CFCs to Java (which is an exercise done far too often, IMO) 
--
they want to know the "best practices" for their every day development 
of
CFCs.

Once someone knows the best practices and the reasons for them they 
can feel
free, of course, to break the rules.

Since CFCs (and CFML) don't have constants that's not a very good 
example,
IMO.



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Matt Liotta
Sent: Wednesday, July 30, 2003 1:58 PM
To: [EMAIL PROTECTED]
Subject: Re: [CFCDev] "this" scope vs. unnamed
There are many perfectly valid reasons for using public fields in an
object. For example, many classes in the Java hierarchy use public
fields for constants. In fact, I find it quite annoying when class
authors require bit-based states without representing those states 
with
constants.

-Matt
----------------------------------------------------------
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).
----------------------------------------------------------
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).