how much can unset do?

[lawrence]

Given a bunch of mixes variables, I'm in a situation where I can't
know what type they are.

Can I use unset to kill an object? unset($object);

Can I use unset to kill a pointer to an open file? unset($fp);

Can I use unset to kill a pointer to a database return?
unset($mySqlResult);

Because of heavy masking in my objects, I often don't know what type
of variable I've got. In particular, I don't if the resource I've got
is a file pointer or a database pointer, all I know is that is fetched
data from some datastore. So, given the uncertainty, is unset a
reasonable way to kill these variables?

[IndyTim]

lawrence wrote:

Given a bunch of mixes variables, I'm in a situation where I can't
know what type they are.

Can I use unset to kill an object? unset($object);

Can I use unset to kill a pointer to an open file? unset($fp);

Can I use unset to kill a pointer to a database return?
unset($mySqlResult);

Because of heavy masking in my objects, I often don't know what type
of variable I've got. In particular, I don't if the resource I've got
is a file pointer or a database pointer, all I know is that is fetched
data from some datastore. So, given the uncertainty, is unset a
reasonable way to kill these variables?

Taken from the PHP manual:!

"unset() destroys the specified variables. Note that in PHP 3, unset()
will always return TRUE (actually, the integer value 1). In PHP 4,
however, unset() is no longer a true function: it is now a statement. As
such no value is returned, and attempting to take the value of unset()
results in a parse error."

[Chung Leong]

Uzytkownik "lawrence" <lk******@geocities.com> napisal w wiadomosci
news:da**************************@posting.google.c om...

Given a bunch of mixes variables, I'm in a situation where I can't
know what type they are.

Can I use unset to kill an object? unset($object);
Not always. And since PHP4 doesn't have destructor, it doesn't make much
sense to talk about "killing" an object.
Can I use unset to kill a pointer to an open file? unset($fp);
No.
Can I use unset to kill a pointer to a database return?
unset($mySqlResult);
No.
Because of heavy masking in my objects, I often don't know what type
of variable I've got. In particular, I don't if the resource I've got
is a file pointer or a database pointer, all I know is that is fetched
data from some datastore. So, given the uncertainty, is unset a
reasonable way to kill these variables?

No. Just let the script run to completion and all resource will be freed.

[lawrence]

"Chung Leong" <ch***********@hotmail.com> wrote in message

Because of heavy masking in my objects, I often don't know what type
of variable I've got. In particular, I don't if the resource I've got
is a file pointer or a database pointer, all I know is that is fetched
data from some datastore. So, given the uncertainty, is unset a
reasonable way to kill these variables?

No. Just let the script run to completion and all resource will be freed.

That will work 99% of the time. The time is won't is when an object
has been assigned a var, and does some operation, and then, during the
next operation, the attempt to assign a value to that variable fails,
so the variable now has the value from the first operation, instead of
the second one. I can't protect myself against that through any easy
kind of test, like isset() or is_array(), because if it was set with
the right type the first time it will still set true. So at the
beginning of the method that sets that variable I've been doing
unset(), to first clear the var, before setting it again. Does unset
protect in such situations?

[Chung Leong]

Yes. Unset() removes the variable from the current namespace, so that when
it's used again, a new variable is created. Unset() does not free the
underlying resource, however. So you files woud be left opened and the
memory allocated for result set won't be freed (until the script is done
running).

It seems your object code has some major flaws. If you're going to
encapsulate functionalities you need to do it completely. You should never
have a situation where you don't know what something is but need to know.
Methods that return different resource types are particularly bad, since
they're completely unrelated.

Uzytkownik "lawrence" <lk******@geocities.com> napisal w wiadomosci
news:da**************************@posting.google.c om...

"Chung Leong" <ch***********@hotmail.com> wrote in message

Because of heavy masking in my objects, I often don't know what type
of variable I've got. In particular, I don't if the resource I've got
is a file pointer or a database pointer, all I know is that is fetched
data from some datastore. So, given the uncertainty, is unset a
reasonable way to kill these variables?
No. Just let the script run to completion and all resource will be

freed.
That will work 99% of the time. The time is won't is when an object
has been assigned a var, and does some operation, and then, during the
next operation, the attempt to assign a value to that variable fails,
so the variable now has the value from the first operation, instead of
the second one. I can't protect myself against that through any easy
kind of test, like isset() or is_array(), because if it was set with
the right type the first time it will still set true. So at the
beginning of the method that sets that variable I've been doing
unset(), to first clear the var, before setting it again. Does unset
protect in such situations?

[lawrence]

"Chung Leong" <ch***********@hotmail.com> wrote in message news:<K6********************@comcast.com>...

It seems your object code has some major flaws. If you're going to
encapsulate functionalities you need to do it completely. You should never
have a situation where you don't know what something is but need to know.
Methods that return different resource types are particularly bad, since
they're completely unrelated.
Yes, you're right. After thinking about it, I've no idea why I'm
trying to kill the resource up in the object that isn't supposed to
know anything about the details of the implementation or the
underlying datastore. I'm going to change the code so that the request
merely gets passed down to the object that is specific to the
datastore:

$this->datastoreObject->destroyResource();

The datastoreObject will always know which type of datastore it is
dealing with, and whether it is a MySql resource or a file pointer,
and it will know how to behave appropriately.

Thanks for pointing that out.



Uzytkownik "lawrence" <lk******@geocities.com> napisal w wiadomosci
news:da**************************@posting.google.c om...

"Chung Leong" <ch***********@hotmail.com> wrote in message

> Because of heavy masking in my objects, I often don't know what type
> of variable I've got. In particular, I don't if the resource I've got
> is a file pointer or a database pointer, all I know is that is fetched
> data from some datastore. So, given the uncertainty, is unset a
> reasonable way to kill these variables?

No. Just let the script run to completion and all resource will be

freed.

That will work 99% of the time. The time is won't is when an object
has been assigned a var, and does some operation, and then, during the
next operation, the attempt to assign a value to that variable fails,
so the variable now has the value from the first operation, instead of
the second one. I can't protect myself against that through any easy
kind of test, like isset() or is_array(), because if it was set with
the right type the first time it will still set true. So at the
beginning of the method that sets that variable I've been doing
unset(), to first clear the var, before setting it again. Does unset
protect in such situations?

[Nikolai Chuvakhin]

lk******@geocities.com (lawrence) wrote in message
news:<da**************************@posting.google. com>...

Given a bunch of mixes variables, I'm in a situation where I can't
know what type they are.

Of course you can. Use gettype()...

Cheers,
NC

[lawrence]

[e-mail] (Nikolai Chuvakhin) wrote in message news:<32**************************@posting.google. com>...

lk******@geocities.com (lawrence) wrote in message
news:<da**************************@posting.google. com>...

Given a bunch of mixes variables, I'm in a situation where I can't
know what type they are.

Of course you can. Use gettype()...

And get_resource_type() for the types of resource? I've thought about
that, but it gets messy - I end up with a long switch statement
dealing with each type, and I may miss a few, and the PHP crew might
add new types in the future, so I'd have to change one of my core
classes.

I think I like the suggestion someone else made, that this kind of
thing simply doesn't belong that high in the class hierarchy. I should
pass the request along to the low level object that knows what type it
is dealing with. That way if changes arise in the future I only have
to change some subclass. I don't have to make any changes in my core
class, which would be dangerous.