On Jul 3, 2007, at 10:37 PM, Perrin Harkins wrote:
Using closures just makes it more confusing. Class variables are
usually implemented as globals, i.e. our $object, not my $object.
agreed.
i just prefer using methods locked into version numbers for a
consistent api. this way the variable
On 7/4/07, pubert na <[EMAIL PROTECTED]> wrote:
Won't multiple simultaneous requests change the "our" variables
unpredictably since they all have access to the symbol table?
No. Every child process is completely separate and they don't share
anything. Each process only handles one request at
Won't multiple simultaneous requests change the "our" variables
unpredictably since they all have access to the symbol table?
On 7/3/07, Perrin Harkins <[EMAIL PROTECTED]> wrote:
On 7/3/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> i prefer storing them as class variables and using a public
On 7/3/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
i prefer storing them as class variables and using a public method to
provide access
ie:
package myfactory;
my $object= object->new();
sub get_object { return $object ;}
Using closures just makes it more confusing.
On Jul 3, 2007, at 5:51 PM, Perrin Harkins wrote:
I don't really understand this description. If you're trying to code
a singleton pattern, use global variables to hold the object. That
makes it clearer what your intent is.
Scoping works the same as usual under mod_perl. If you need acces
[ Please keep it on the list ]
On 7/3/07, pubert na <[EMAIL PROTECTED]> wrote:
The app I'm working with uses this as a method for object b to retrieve the
instance of object a, which created it.
i.e. An object x, creates 4 objects, a,b,c, and d, then calls a method in
object a. Object a need
On 7/2/07, pubert na <[EMAIL PROTECTED]> wrote:
my $self;
[...]
sub doit{
print $self->{CGI}->header;
print "hello";
}
This is bad. You're using a variable that you didn't pass to doit().
That means you're creating a closure. The sub will remember the $self
it saw when you first
Hi,
I jumped into the middle of this thread and it seems I am encountering a
segfault in the header just like you have described.
Could you give me an overview of your solution since I do not have your
first emails to this list.
Thanks
Tyler
pubert na wrote:
I fixed it... apparently it no
I fixed it... apparently it not like the "return $self if defined $self;"
... return $class id ref $class is better form anyway... thanks and sorry
about all the emails ;)
On 7/2/07, pubert na <[EMAIL PROTECTED]> wrote:
I was able to narrow down the problem I was having, and produce a test
cas
I was able to narrow down the problem I was having, and produce a test case
for you folks. Below are two relatively self-explanatory files. If I
navigate to test.cgi, it will appear to load the page properly, but if I hit
the reload button a bunch of times in a row, the error_log will log
segfaul
10 matches
Mail list logo
