I used to be a pretty heavy cfscripter. Then when I started working with other people's code, I'd see a lot of this:
<cfset blah> <cfscript> something = somethingElse; </cfscript> <cfmail blah> <cfscript> blahblahblah; blahblahblah; </cfscript> <cfSomethingOrOther> this business of switching back and forth between script and nonscript was/is maddening. and especially when it's using cfscript just for a few assignment calls and no actual logic. So my problem with cfscript stems largely from what i perceive as its misuse in code i've seen (and also written, i'm sure). And I think that's why I avoid cfscript now, simply to avoid the issue entirely. Which is ironic in some ways because in terms of syntax, I generally prefer coding in java to coding with CF. Good stuff, Bill. On Thu, Sep 4, 2008 at 11:29 AM, Sean Corfield <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 3, 2008 at 11:15 AM, bill[y] <[EMAIL PROTECTED]> wrote: >> 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? > > I hope so... but if it feels too much like Groovy, why not simply use Groovy? > >> * 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. > > I agree. I've been an evangelist for dynamic typing for a few years > now (after being one of the most vocal advocates for CF getting > *stricter* typing and <cfinterface> back in the day). The more I've > worked with CFML (and other dynamic languages) alongside stricter > languages like Java, the more I prefer the power of dynamic typing. It > makes tester easier, it makes extensibility easier, it involves a > helluva lot less typing. It generally makes me a faster programmer. > >> * Access Control ? * >> Do we really _need_ private methods? Why? > > We don't. Groovy takes the approach that 'private' is just a hint to > exclude something from the API docs but otherwise completely ignores > 'private'. It makes sense. Who are you trying to protect code and data > from? In CFML, you can always get at the protected data / methods in a > CFC (note: protected - CFML does not have *private* anything!). You > can either extend the CFC, giving you full access to VARIABLES scope > or you can inject your own methods at runtime to expose whatever you > need. Since it's that easy to "get around" the 'private' access > control, you can't use it to protect your code against any developers > so you might as well simply drop it. I quite like Adam's 'intent' > annotations. > >> * Hindered Functionality ? * >> cftransaction, cfquery, cfdump, cfstoredproc, etc., have no >> _documented_ counterparts in cfscript. > > Now that I rely on ORMs for all persistence, I never write > cftransaction, cfquery or any of its ilk. I use a logging service for > debugging, I use a notification service to send emails. I'm finding > that the omission of these tags is only a nuisance in very small > p.o.c. code and never an issue in "real" programs. > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
