Thank you Sam and Nando, I think you both have good ideas and you are correct it doesn't sound like using "any" is as bad as it might have initially seemed.
"#1 is that inheritance for code reuse can get you in trouble. If you have little experience in OO architecture, i'd shy away from that." Can you give me an idea of what you mean by this. I am setting up multiple inheritance trees, and they are all really pretty simple. I'm only extending things that it really seems to make sense to do so. I have some room in my projects for experimentation like this. Again, Thanks for the feedback, I really appreciate it. James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Friday, September 01, 2006 6:36 PM To: [email protected] Subject: Re: [CFCDEV] Extending CFC and Argument Types James, Reading your email quickly, i have 2 comments. #1 is that inheritance for code reuse can get you in trouble. If you have little experience in OO architecture, i'd shy away from that. Object orientation in practice isn't perfect, and an experienced OO architect can see where to bend "the vision" of OO into something more practical in a certain circumstance, as a trade-off. But in general, and you may know this already, composition is much more flexible than inheritance. With inheritance, you lock yourself into your inheritance hierarchy. With composition, that doesn't happen. I'd use inheritance only when you have a very clear-cut case for it. I've backed myself into a corner several times using inheritance where i shouldn't have. And each time, i've come out of it saying to myself, "Gee, that was dumb" ... because you have your whole codebase structured around it. And then you've got a lot of restructuring and rewriting ahead of you to get yourself out of the corner. #2 is that ColdFusion is a dynamically typed language. And from what i see in between the lines of the function you showed, you're trying to use that function in a dynamically typed way. "We wanted to declare *all* of these functions in our base component because they *all* look the same." Yeah, so if i'm interpreting this correctly, that means necessarily that you need to use "any" as your type there. But before we get too far in developing out this architecture, let's read point #1 again. ;-) In regards to CFCs, type is either the explicit.dot.delimited.path.to.your.CFC, (or if it's in the same directory as the calling code, you can simply use the name of the CFC in the type declaration and leave off the path). In other words, "type" means a single specific CFC. You can also type a subclassed CFC by it's parent class. That will work. All CFC's are subclasses of the component.cfc in WEB-INF\cftags, so if you just want to specify "any CFC", you can use *WEB-INF.cftags.component* as your type declaration. Now, the crux of the matter is this. Since ColdFusion is a dynamically typed language that is compiled at runtime, you don't get as much benefit from strictly typing your CFCs as you would in a strictly typed language. In a strictly typed language, the compiler won't let you compile code where you try to pass an object into another if it's the wrong type. In ColdFusion, the benefit is that you can accept /any/ CFC as an argument in a function, if that's what you need - easily. You just set the argument type to "any". That's a benefit. And it seems like that's what you're trying to do here. In CF, the only difference between strictly typing a CFC and using "any" is that you'll get a slightly different runtime error when it doesn't work, and in fact, the error you get if you use "any" is probably more descriptive of the problem. Otherwise, you'll just see that "hey, that's the wrong type" error. The only benefit you get by strictly typing your CFC's is that it's a form of documentation. You can also put that documentation in a hint tag, if you want. If you're working in a team and members of that team might use these functions for further development, typing your arguments might help them a lot. It'll tell them that the function NEEDS to have a specific CFC instance passed into it in order to function correctly, and it's THIS one -> some.dot.delimited.path.to.the.CFC Thats very helpful, because it tells the developer using the function exactly where that CFC is, out of perhaps thousands of files. This is where strict typing can be very beneficial in CF. One needs to clearly understand the implications of strict typing in a loosely typed language. See the newsletters at halhelms.com about Duck typing for a better explanation of this than mine. ciao, Nando Glaser, James B Mr TACOM-RI wrote: > Here in my office I moved us to developing our CF apps in Mach-II and > ColdSpring because we wanted to move towards OO development. We have > been slowly taking steps to more and more leverage the OO development style. > > The question I have relates more to CFC development rather than > Mach-II so I'm posting it here. > > The next step we are making is to try to leverage the power of > extending CFCs. We want to declare lots of common functions that we > now end up putting in many components over and over. We have developed > some naming conventions to help facilitate this but we are now running into a minor problem. > > Here is what we've done. We have created a base component that pretty > much every other component will extend. This component contains some > functions that are used in every component. > > Next we started creating a base database service component. Every one > of these service components has a 2 setter functions to set the DAO > and gateway CFC, and they all have a get, set, and search function to > get set, and search database records. We wanted to declare all of > these functions in our base component because they all look the same. > In the functions that get a bean as a argument we have ran into a problem. > > Imagine this: > <cffunction name="set" access="public" returntype="bean" output="false"> > <cfargument name="bean" type="bean" required="true" /> > <cfreturn variables.DAO.save(arguments.bean) /> </cffunction> > > We intend that the type="bean" refers to the local bean for the > specific service. But ColdFusion does not understand this and throws > an exception that the argument passed to the function is not of type > bean. Because the bean does not reside in the directory as the base service component does. > > So, from here I can only figure out 2 ways out of this. Backtrack and > put all these methods back into the individual services, or utilize > the type="any" option. I would rather not use type any, and I think > the time saved in not having the functions repeated in every service > is a valuable one. > > I did have an idea of using the GetMetaData() function to dynamically > set the type, but CF throws an error when you do this stating that > type must be a constant. > > Does anyone have any suggestion on an alternative, or is there > something I might have missed that would help us out. > > Thanks! > James > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > -- <http://aria-media.com/> Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com <http://aria-media.com/> You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
