Good post Billy. You said 'Do we really _need_ private methods? Why?'
I suppose the answer is NO we don't need them but they are nice to have. When I create a cfc its nice to tell the other developers what I have as my api and what's not meant to be used outside the object. I also think 'package' is useful because I can have my DAO/Gateway methods as package and only available to my service object in the same directory. It then encourages anyone looking at using my objects into finding a suitable service method to use rather than the methods that shouldn't be public. And re: <cfscript>, I used to use it and will do again if Adobe gives it the TLC it deserves. Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of bill[y] [EMAIL PROTECTED] Sent: 03 September 2008 19:15 To: CFCDev Subject: [CFCDEV] What's wrong with cfscript? I've preferred writing in cfscript ever since it came out. There's a lot less keystrokes and cfscript is more readable; to mine eyes alone, maybe. I like the brevity of cfscript vs. the more verbose tag based expressions, and I'm looking forward to Centaur's improvements. I wonder if it's gonna feel like Groovy? Anyway, aside from documentation metadata and some hindered functionality, what are the _real_ downsides of cfscript today ? * Statically Typed Parameters ? * http://www.artima.com/weblogs/viewpost.jsp?thread=4639 ("Uncle" Bob Martin) After reading this older article a while back, I started to seriously re-think the importance of statically typed data in favor of loosely typed data. The point that struck me about this article and comments is that even though the compiler does type checking, you can still write bad code. So, what does a compiler do for the quality of your code? Also, what good is runtime checking of datatypes - could that be a code smell? I'm starting to think that if I'm relying on the runtime to make sure my app works, I'm being lazy. Like Bob mentioned above, the more I unit test, the less I rely on the runtime to check my stuff. Anyone else feel like this? * Access Control ? * By default, a function (udf) in cfscript is public. There's no _documented_ way to alter this access. It would be nice to make a cfscript udf remote or private ... which brings me to another quandary: Do we really _need_ private methods? Why? * Hindered Functionality ? * cftransaction, cfquery, cfdump, cfstoredproc, etc., have no _documented_ counterparts in cfscript. For me, this is the biggest drawback. I know I can build tag-based wrappers and have cfscript udfs call them. This is ok, but, what I'm also finding is that the overall format of my code is inconsistent - I'll evolve a mishmash of cfscript and cf tags ... not very pretty. Any cfscripters out there or anyone that codes almost entirely in cfscript? best, bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
