Hi Sean, I'm agnostic on whether this change should be made (I would like it to work the proposed way, but I'll start telling people to add features the day I start being responsible for managing or coding the project!). I get that average users may not see the benefit of getFirstName() vs. get FirstNameRecord(), but one of the benefits of frameworks is that they help you to use best practices so you don't have to figure them out for yourself (if you are indeed just coming to terms with anything other than spaghetti code).
I do believe that getFirstName() makes more sense that getFirstNameReactor(). Back to some of the basics underlying OO - maintainability and reusability through encapsulation and cohesion. To take an example, imagine an object which supported n-persistence methods at runtime (web service from third party data source, flat file and some kind of DB). Now I would have to know whether to call getFirstNameXML(), getFirstNameWS() or getFirstNameReactor() when getting an attribute from my bean. I really shouldn't need to know anything about HOW my bean is being persisted to access its attributes. Are enough CF'ers creating dynamic n-persistence type applications such that they should have to go to extra effort to support this variability? No. YAGNI applies. But if it is no extra effort on the part of the developers (getFirstName() is no more complex or difficult to type than getFirstNameReactor()), then the fact that novice OO developers won't NEED the proposed feature seems to me (point tail right back at you), a bogus argument for not adding it. As to whether the purity of Reactor should be messed up with Jareds great solution (all such solutions are great until you have 200 of them) is another matter. Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Friday, March 24, 2006 12:01 PM To: [email protected] Subject: Re: [Reactor For CF] Reactor R&D On 3/24/06, Shannon Jackson <[EMAIL PROTECTED]> wrote: > My emphasis is not on changing out, rather migrating to. An additional > benefit would also be migrating from (potentially). Again, with my horns, pointy tail and pitchfork in hand: For the vast majority of CFers who might want to adopt Reactor, they don't have DAOs and they don't have beans and they don't have well-structured CFC-based applications at all. I've just completed a "tour" of CFUGs with my Objects & Persistence talk where I show how to migrate from spaghetti code to using CFCs to manage objects and then how to use any of the four ORM frameworks. For most all of those audiences, having a data access layer is a novel idea. For them, the cost of adopting Reactor would not be changed one iota by exchanging getXyxRecord() to getXyz() - in fact, I would contend that this might even confuse them (hey, remember the horns and pointy tail!). Remembering createRecord() / getXyzRecord() is probably easier for them - they can see immediately these are both "record" objects. > That is because the createRecord() is used below the service level -- > no problem there. Only if you have a service level - see above. For most CFers adopting Reactor, they will liberally pepper their code - which may well be page-based rather than controller-based - with calls to createRecord() and createGateway(). They *may* create a DAO to wrap Reactor. That's a long way from a controller / service / business model / data access layered model of development. You are in a very unusual minority in the CF community: you have created a large, multi-tiered application that is far beyond the comprehension and skill level of most folks in the CF community at the moment. > I do see your point completely... I think we actually might be both > right here about our points and I may not be communicating effectively > without white boarding the service pattern we are using. Oh I totally understand where you're coming from. I just don't think the change you are proposing is right for the framework - even tho' I actually think a small, configuration-based change with a backward-compatible default would be a "small tweak". Bear in mind that a CFer familiar with default Reactor behavior is going to find your code confusing with that "Record" naming convention to hang onto... -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
