Ben Johansen wrote:
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.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
1. You pass it parameter 2. You Process the function using method scope vars (do not affect callingIf 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)
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
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
