@Bill don't be despondent, I'm comfortably sure CFSCRIPT will get a resurgence at some stage in the not too distant future, if only to satisfy the growing number of people who are now preferring it (like myself, triggered by - of all things - using Application.cfc)
hang in there. On Thu, Sep 4, 2008 at 6:52 AM, Peter Bell <[EMAIL PROTECTED]> wrote: > > Just to say I'm another "all cfscripter". I use tags for components > and functions because I have to, I have a couple of base component > methods like dump() wrapping key tags, and I find most tags are well > encapsulated anyway - cflocations are handled by a redirect() method > in the BaseController, I have an executeSQL() method in my BaseDAO, I > hide all cfmails within calls to a NotificationService, etc. This also > allows me to wrap additional functionality around classes of activity > (directory operations, emails, etc.) as they all happen in one place. > > Best Wishes, > Peter > > On Sep 3, 2008, at 2:15 PM, bill[y] wrote: > >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
