>- see footer for list info -< That is of course presuming you currently code in a similar way without CFC's. You could equally say that putting data in request scope or using the caller scope from custom tags is bad practice for the same reason. I think if your going to actually care about whether or not using the THIS scope is bad, the rest of your code needs to follow the same process and be encapsulated, otherwise what is the point.
Russ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dominic watson Sent: 29 December 2005 14:40 To: Coldfusion Development Subject: Re: [CF-Dev] The THIS scope in CFCs >- see footer for list info -< As to the reasons for using the 'this' scope being bad practice I've just figured how to put it (though it's hard to put in words). As I said before, it is only bad practice in terms of writing Object Oriented components, but afterall, that is what they are for. Taking your example, lets say you are an outside developer using the object and you want that query that the method populates. If the query is stored as a property in the 'this' scope, you will need to open up the component and view its code to see the property name, where it is set, etc in order to know how to get at it. If the query is returned by a method, all you need to know is the method definition (in the case of CFCs, this can be automatically generated and viewed using a component browser, download my static CFC documenter here <http://www.greenhouse-design.co.uk/downloads/greenDoc.zip>). This is a rough description of encapsulation: the outside coder can only get and set data through the interface that the object creator allows. The outside coder just needs documentation of the interface (i.e. the methods) and he is set to go. The outside coder should never have to look into the code. With this in mind, you should always set the 'hint' attributes of CFFUNCTIONs, CFARGUMENTs and CFCOMPONENTs with useful documentation. By using the 'this' scope for component properties, you bypass the whole idea of the object interface and the object loses its encapsulation. This is why it is 'bad' practice. It may sound like a lot of hassle, but once in the swing of writing encapsulated objects you find programming them far more enjoyable and manageable. Dominic dominic watson wrote: >> - see footer for list info -< > > Using the this scope is 'bad' practice only in terms of O-O. Have a > look at some decent descriptions of O-O, and in particular > encapsulation Heres one that relates to java (which implements O-O > very well): > http://javaboutique.internet.com/articles/ITJ/part02/index.html > > In other languages, the problem of returning multiple values is dealt > with in ways which CFCs cant handle (pointers). I would think the most > straight forward way to do it in CF is to return a STRUCT of all the > different return values. I think this is a more elegant solution as > there is one less line of code: > > <cfset st_result = myObject.myMethod("argument")> <cffif > st_result.b_success> > <cfloop query="st_result.q_records"> > <!--- etc. ---> > </cfloop> > </cfif> > > In the above example, the struct return contains two values, a success > or failure flag and the query. > > In my opinion, objects and cfcs should be written so that the code > that uses them uses as little and as readable code as possible. The > code inside the objects can be as complex as you like as long as the > /interface/ that uses them is clean. The extra cfset line that > accesses the produced query seems a little ambiguous to me and would > be harder to document than a method that returns a structure that > contains the query and the other return variable. > > My tuppence worth > > Dom > > > Gary F wrote: > >>> - see footer for list info -< >>> >> >> I posted a similar message on Ray Camden's Ask a Jedi blog but it >> created more questions than answers. I need to return at least 2 >> complex objects >> (queries) from a CFC. The CFRETURN function only lets you return a >> single object/variable so I started using the THIS scope. >> >> Example: from within the CFC >> <CFSET this.myquery=myquery> >> >> Now myquery is exposed to the parent page so I can grab it like so: >> >> <!--- use createobject to initiate the cfc ---> <CFSET >> objCFC=CreateObject("component","myCFC")> >> <!--- collect a varible that CFReturn would usually return from a cfc >> ---> >> <CFSET getReturnedData=objCFC.myFunction("optional arguments go >> here")> >> <!--- get the var/object that was explosed using the This scope ---> >> <CFSET myquery=objCFC.myquery> >> >> I found this is the quickest and most effecient way to return >> multiple vars/objects from CFCs without storing them in arrays or >> structures which seems like a waste of code when This works with >> total simplicity. >> Someone >> told me using the This scope is bad practice but failed to give a >> reason. I honestly don't see what's wrong with this, but I'd like to >> hear the thoughts of experienced CFC users? (I've only been using >> CFCs for a few months). >> >> Thanks, >> Gary. >> _______________________________________________ >> >> For details on ALL mailing lists and for joining or leaving lists, go >> to http://list.cfdeveloper.co.uk/mailman/listinfo >> >> -- >> CFDeveloper Sponsors:- >> >> >>> - Hosting provided by www.cfmxhosting.co.uk -< >>> - Forum provided by www.fusetalk.com -< >>> - DHTML Menus provided by www.APYCOM.com -< >>> - Lists hosted by www.Gradwell.com -< >>> - CFdeveloper is run by Russ Michaels, feel free to volunteer your >>> help -< >>> >> >> >> >> > > _______________________________________________ > > For details on ALL mailing lists and for joining or leaving lists, go > to http://list.cfdeveloper.co.uk/mailman/listinfo > > -- > CFDeveloper Sponsors:- > >> - Hosting provided by www.cfmxhosting.co.uk -< >> - Forum provided by www.fusetalk.com -< >> - DHTML Menus provided by www.APYCOM.com -< >> - Lists hosted by www.Gradwell.com -< >> - CFdeveloper is run by Russ Michaels, feel free to volunteer your >> help -< > > _______________________________________________ For details on ALL mailing lists and for joining or leaving lists, go to http://list.cfdeveloper.co.uk/mailman/listinfo -- CFDeveloper Sponsors:- >- Hosting provided by www.cfmxhosting.co.uk -< >- Forum provided by www.fusetalk.com -< >- DHTML Menus provided by www.APYCOM.com -< >- Lists hosted by www.Gradwell.com -< >- CFdeveloper is run by Russ Michaels, feel free to volunteer your help >-< _______________________________________________ For details on ALL mailing lists and for joining or leaving lists, go to http://list.cfdeveloper.co.uk/mailman/listinfo -- CFDeveloper Sponsors:- >- Hosting provided by www.cfmxhosting.co.uk -< >- Forum provided by www.fusetalk.com -< >- DHTML Menus provided by www.APYCOM.com -< >- Lists hosted by www.Gradwell.com -< >- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
