@sean > I hope so... but if it feels too much like Groovy, why not simply use Groovy? Then what would I talk about at cf conferences? ;-)
>Who are you trying to protect code and data > from? That's what I'm getting at. Are _all_ public methods actually broadcasting, "please, evil programmer, feel free to use me as you wish"? Can it be design laziness to make a method public just so some other "object" in the same app can access it's services? What _would_ the consequences really be if every method were indeed public? As Adam said, it indicates intent, maybe nothing more, because you can still get around private/package methods if you want. I can see that if your product is a true API and you expected developers to build upon it, then you would somehow want to make it clear what things they _should_ be using, knowing full-well they can do whatever they want; especially in the open source world and with access to non-compiled CF. So, are we just touting "good design" with package or private access? Do those modifiers really have any effect? Or are they just documentation instructions or guidelines? Please don't get me wrong here; I'm not advocating anything, except testing, of course ;-). I'm just challenging a way of thinking ... one to which I have subscribed for some time ... best, bill On Sep 4, 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 -~----------~----~----~----~------~----~------~--~---
