@Marc, I found at first I'd have that kind of switching in my code which I agree sucks, but now that I've got a fairly stable framework I don't find that I need most tags - similar to Seans recent comment on the topic - the framework takes care of persistence, logging, notifications and the like so the tags aren't really that relevant.
Best Wishes, Peter On Sep 4, 2008, at 12:05 PM, Marc Esher wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
