Re: Live_Objects behavior depends on garbage collection timing

[prev] [thread] [next] [Date index for 2004/07/09]

On Fri, 2004-07-09 at 15:12, Siamak Pazirandeh wrote:
> ex 1: This is the original case where the $user object persists.  This
> is the behavior I got on 5.8.0 and 5.8.2
> 
> do { my $user = Class::DBI::users->retrieve(1); };
> print STDERR Class::DBI->dump_object_index();
> 
> $VAR1 = {
>           'Class::DBI::users|user_id=1' => bless( {
>                                                            'user_id' => '1'
>                                                          }, 'Class::DBI::users' )
>         };
[...]
> ex 4: This is the more serious case, which comes up with "has_a"
> relationships. probably the same issue as demonstrated in example 1,
> but actually implemented within the has_a behaviour:
> 
> 
> In the following example, Class::DBI::html defines a "has_a"
> relationship to Class::DBI::card, on the primary key. You'll note that
> the card object persists. This is the original case which caused me to
> look into the issue. Very, Very subtle, but allows the object to
> remain as a Live_Object somehow. 
> 
> do {
> my $card2=Class::DBI::card->retrieve(25189);
> 	if (my $hh=Class::DBI::html->retrieve(25189)) {
> 	$hh->html;
> 	}
> };
> print STDERR Class::DBI->dump_object_index();
> 
> $VAR1 = {
>           'Class::DBI::html|cid=25189' => undef,
>           'Class::DBI::card|cid=25189' => bless( {
>                                                           'cid' => '25189'
>                                                         }, 'Class::DBI::card' )
>         };

This is the same as #1, isn't it?  What happens if you drop that
assignment to $card2 in the beginning?  That should make it the same as
example #3.

My opinion at the moment is that this is looking potentially too
difficult for programmers to manage.  If normal perl constructs commonly
result in scoping problems, we should remove the single instance
feature.  Other opinions?

- Perrin