Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #16802

Re: Closing a statement causes a "malformed object" error ontheresult - by design ?

From "Christoph M. Becker" <cmbecker69@arcor.de>
Newsgroups comp.lang.php
Subject Re: Closing a statement causes a "malformed object" error ontheresult - by design ?
Date 2016-06-27 15:33 +0200
Organization solani.org
Message-ID <nkr9vk$boi$1@solani.org> (permalink)
References <576fede9$0$5918$e4fe514c@news.xs4all.nl> <nkponn$fii$1@solani.org> <5770f4f5$1$5918$e4fe514c@news.xs4all.nl> <nkr1i3$av4$1@solani.org> <57712350$0$5894$e4fe514c@news.xs4all.nl>

Show all headers | View raw


On 27.06.2016 at 15:02, R.Wieser wrote:

> Christoph M. Becker <cmbecker69@arcor.de> schreef in berichtnieuws
> nkr1i3$av4$1@solani.org...
>
> And that makes me wonder: who does actually take care of releasing the
> $results objects resources still there when $statement object is
> closed/destroyed ?   Shouldn't I be prepared to do that anyway ? (note to
> self: check if $restults->close() or something similar exists)

There is SQLite3Result::finalize(), but if you don't call it explicitly,
it will be called by SQLite3Result's destructor[1], which should be
called by SQLite3Stmt's destructor[2].  I'm not sure, however, if that
does really happen.  Maybe that's what <https://bugs.php.net/69971> is
about?  Might be worth closer examination.

> And no, in case of a COM/OCX object with its reference count the "parent"
> object can be told to terminate before all its "childs" are closed.   It
> will ofcourse not actually *do* so until the above-mentioned reference count
> reaches zero (though variable holding the object reference will (/should)
> get set to NULL).

The automatic memory management of PHP is actually mainly done by
reference counting[3], so basically works the same, unless one
explicitly calls ::close().

>> but removing the close() method now would cause major
>> BC issues, so that doesn't appear to be an option.
> 
> In that case just do what MS always does in cases like that: keep the
> method, but just don't let it actually *do* anything. :-)

But then a programmer would not be aware that he'd have to explicitly
set the statement to null to force closing the statement.  Of course,
the method could be deprecated, but that would require the RFC process[4].

> Just one request: please do not shift the blame to me when the documentation
> has been available all this time. :-D

No, I won't. :)

[1]
<https://github.com/php/php-src/blob/php-7.0.8/ext/sqlite3/sqlite3.c#L2267>
[2]
<https://github.com/php/php-src/blob/php-7.0.8/ext/sqlite3/sqlite3.c#L2114>
[3] <http://php.net/manual/en/features.gc.php>
[4] <https://wiki.php.net/rfc/howto>

-- 
Christoph M. Becker

Back to comp.lang.php | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-26 17:02 +0200
  Re: Closing a statement causes a "malformed object" error on the result - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-26 12:23 -0400
    Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-26 22:07 +0200
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-26 16:45 -0400
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 12:26 +0200
          Re: Closing a statement causes a "malformed object" error ontheresult - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-27 10:11 -0400
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Peter H. Coffin" <hellsop@ninehells.com> - 2016-06-26 15:55 -0500
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 11:11 +0200
  Re: Closing a statement causes a "malformed object" error on the result - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 01:33 +0200
    Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 11:44 +0200
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 13:10 +0200
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 15:02 +0200
          Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 15:33 +0200
            Re: Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-27 16:45 +0200
              Re: Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-28 12:45 +0200
                Re: Closing a statement causes a "malformed object" error on the result - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-28 15:25 +0200
                Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-28 18:41 +0200
                Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-28 19:29 +0200

csiph-web