Thanks for the correction ;-)
Ben Johansen - http://www.pcforge.com Authorized Witango & MDaemon Reseller Available for Witango Developement -----Original Message----- From: John McGowan [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 8:53 AM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Objects versus branch Ben Johansen wrote: >I know this is mostly directed at Robert, but I would like to take a stab at >it. > >TCFs are Thread Safe that means in simple terms that each instance of the >TCF has its own set of method vars. > >To me it is bad form to create a TCF that affects variables of any other >scope than method. In Essence it should be treated as a function > > This is the procedural programmers take on how to use objects. There's nothing wrong with writing "Library" type objects in TCFs to be used as a repository for useful functions. But this doesn't utilize OO principles. You can write your application that way, but don't call your application OO if that's the extent that you've used objects. >1. You pass it parameter >2. You Process the function using method scope vars (do not affect calling >tafs vars in this process) >3. You pass the value back to the calling taf > >Yes you can affect calling var tafs but you are going to handle the thread >safe issues yourself > > If this is how you're using TCFs you *can* mutate local/request scoped variables. (i assume that's what Ben means by calling taf vars) Because those variables are unique to the overall request from the browser and are not affected by other threads. Each thread has it's own "Request" scope. (That's why they changed the name to Request, to make that point more clear) The way OO programming was designed (including using TCF's) is something like the following. 1. model some data or something that exists in the real world with an object. This involves the following. a. modeling all the data and relationships to other objects with instance variables. b. modeling the behavior and actions that those objects are susceptible to by writing methods. this is what makes OO programming what it is. keeping your data structures close to the methods that affect them. 2. instantiate an object in the appropriate scope when you want to create that entity. 3. call the methods of the object to mutate or retrieve the data and probably most importantly 4. When it comes time to modify your code to fix a bug or whatever... lo and behold the data and the logic associated with that data is all in the same place, and you life should be just a bit easier because of it. Don't worry about instantiating objects in user or local scopes. If it makes sense to instantiate the object that way, do it. Just because you have a large TCF file doesn't mean you're going to take up that amount of memory for every instantiation. You will only be taking up the amount of memory required by your instance variables for each object instance. Picture every binary object as two parts. 1. data part (instance variables and temporary method variables) 2. functionality/logic part ( these are the algorithms that you wrote in your methods there only needs to be 1 copy of those methods for all instantiated objects of that type.in memory) as long as your language doesn't allow for "mutating the logic part" of your application, then there is no need to replicate that part of the code. Witango doesn't allow you do do such things so your safe there. /John >IMHO > >Ben Johansen > >-----Original Message----- >From: Bill Conlon [mailto:[EMAIL PROTECTED] >Sent: Friday, December 10, 2004 12:08 AM >To: [EMAIL PROTECTED] >Subject: Re: Witango-Talk: Objects versus branch > >Thanks everyone for your insights. Can I just ask for clarification on >one thing -- object instantiation in a shared scope. > >Robert, it sounds like you run TCFs in a shared scope (such as >application or domain) so the Object is created only once. For >example, an init.taf might set up the class files for a domain: > ><@ASSIGN NAME="myObject" SCOPE="domain" VALUE="<@CREATEOBJECT >TYPE='tcf' OBJECTID='MyObject.tcf'>"> > >Then within various appfiles you will invoke the methods: > ><@CALLMETHOD OBJECT=@@domain$myObject METHOD='foo(1,"test")'> > >So there is a single object instance, but the method can be called any >number of times by this and other appfiles. Is my understanding >correct? > >If it's correct, then how do you handle re-entrancy issues, method >scope? > >thx. > >On Thursday, December 9, 2004, at 04:38 PM, Customer Support wrote: > > > >>The only thing that should be added is that unscoped variables can be >>a performance hit. >> >>When an unscope variable is referenced the server starts looking for >>the variable in the different variable stores ([Method then Instance >>then] Request then User then Application then Domain then System). >>Custom scopes fall outside of the Witango scope hierarchy; therefore, >>only explicitly specifying the scope when returning the variable >>allows Witango Server to find the variable. Cookie scope is also not >>searched when no scope is present, though it does sit at the same >>level in the scope hierarchy as user scope. >> >>We recommend that you always scope variables for optimum performance. >>If you must use variables without scopes do not put them in large >>loops (@FOR, @ROW, @WHILE, FOR Action WHILE Action). You will see a >>performance difference when compared to scoped variables in loops >>proportional to the number of iterations of the loop and the size of >>the variable store in each scope. >> >>Witango Support >> >>On 10/12/2004, at 10:53 AM, Robert Shubert wrote: >> >> >> >>>1. Scope. Can Objects be instantiated just once (say in application >>>or domain scope) and used safely? It looks to me like you really >>>should instantiate everything in request scope to avoid getting >>>clobbered by another thread. >>> >>>I love objects and scope... I always name my object variables a little >>>unique, and call them without a scope. This allows me to create an >>>object in various scopes for various reasons: request or user when I'm >>>developing, domain or custom when I'm in production. You can also >>>beta-test on your production environment by leaving your production >>>tcf >>>in domain/application/custom and loading your beta tcf into >>>request/user. Witango 5.0+ is a pro at managing TCFs in all scopes, >>>and >>>higher level scopes can really make them fast/easy to use, providing >>>ever present functions akin to a custom tag. Just watch out how/when >>>you >>>purge/rebuild the higher scopes, you can pull a TCF out from under a >>>running request. >>> >>>2. Memory. Is each instantiated object a copy of the class file? It >>>seems like application memory use would then be proportional to >>>requests, whereas with branch/return application memory use is fixed >>>(assuming cached) and data memory is proportional to the number of >>>session. >>> >>>This is true, an application/domain level tcf would use about the same >>>memory as a branched taf, and user scope would compound in the user >>>var >>>space for each user. >>> >>>3. Performance. Does anyone have an idea of the extra burden placed >>>on the server to manage object instantiation (for example, if TCF must >>>be copied with each <@CREATEOBJECT>) >>> >>>It is very minor. There's effort with both of your methods, and both >>>are >>>very minor. I was once told that the way Witango handles TCFs (only, >>>not >>>other objects) is so close to a normal TAF that the decision on >>>whether >>>to use them or not should be made solely on the principles of >>>programming. A more object orientated program design is good in many >>>ways. HOWEVER, the use of TCFs is not truly objective, so beware of >>>the >>>pitfalls. >>> >>>Thanks. >>> >>>bill >>> >>>______________________________________________________________________ >>>__ >>>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>>______________________________________________________________________ >>>__ >>>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >>> >>> >>> >>_______________________________________________________________________ >>_ >>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> >> > >________________________________________________________________________ >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > >________________________________________________________________________ >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
