Re: [PHP-DEV] Is reference counting necessary for a PHP implementation?

[Sidharth Kshatriya]

The incrementing of the counter is the easy part.

In ref counting, while decrementing the counter for a non-scalar (objects,
arrays, etc), if the counter reaches zero we need to follow all the
non-scalars referenced by the non-scalar you just made zero (and decrement
them too. Also, if any of them reach zero then you would need to follow up
on the non-scalars they point to, and so forth recursively). So reference
counting can become non-deterministic in terms of number of objects you
need to touch while doing any operation that results in a counter
decrement. Perhaps that is why HHVM is claiming that ref-counting can be a
performance hit?

The point here is that since we need the destructor to fire
deterministically there seems to be no way to avoid reference counting
semantics. We can however choose not to free memory while doing reference
updates but wait for later during a full garbage collection pass. However I
don't know what the specific performance implications of this might be.
That garbage collection pass will also automatically deal with circular
references. (However the Zend PHP implementation frees the objects during
reference decrement and only deals with cycles during it "gc" pass as far
as I know).

TL;DR: It seems to me that we need to follow full reference counting
semantics which involve following indeterminate non-scalar chains even
though we may not choose to actually free the memory occupied by
non-scalars when doing so.

Thanks,

Sidharth




On Thu, Sep 28, 2017 at 1:09 AM, Stanislav Malyshev 
wrote:

> Hi!
>
> > Is this statement correct? If I understand correctly many PHP projects
> > depend on the deterministic firing of `__destruct()` function to cleanup
> > SQL transactions or connections and so forth.
>
> Yes. But, strictly speaking, you do not have to use specifically
> refcounting - i.e. having some value to increment by 1 each time
> reference is added and decremented by 1 each time reference is removed -
> to achieve that. Pretty much none of the code requires there would be an
> actual counter - only that the system would behave as if there was a
> counter. Of course, in this case actually having the counter is the most
> natural way of doing it :) But if you find some other way of achieving
> the same semantics, I think it'd be still OK.
>
> > instead could unlock measurable performance improvements, and the
> behavior
> > of destructors could be closely imitated by a combination of try/finally
> > and other new language constructs.
>
> I am not sure I am convinced by this statement, and not sure how RAII
> patterns would work in GC-based environments (i.e. it seems to me they
> won't). That being said, many resource allocation scenarios can be
> implemented without RAII (in fact, C doesn't have RAII at all, people
> still manage to work with it :).
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

[Sara Golemon]

On Thu, Sep 21, 2017 at 5:13 PM, Stanislav Malyshev  wrote:
> It'd be also nice then if we could have some syntax that allowed us to
> refer to functions/methods as callables - mostly for the benefit of the
> code readers and IDEs. I.e. you can do "hello" |> "strtoupper" and it's
> fine but it is not at all intuitive what you're doing sending one string
> into another. Same with "hello" |> [$this, 'bar']. Now, if we could do
> something like this:
> "hello" |> &{strtoupper}
> "hello" |> &{$this->bar}
>
Super-hacky implementation (that I wouldn't want to merge, but it
shows the syntax at work).

https://github.com/php/php-src/compare/master...sgolemon:lambda
which provides a form of both short-closures and partial functions.

Combined with also-super-hacky pipe diff from earlier, you get:

$x = "Hello"
  |> &{strtoupper($0)}
  |> &{ $0 . "world" }
  |> &{strrev($0)};

var_dump($x);
// string(10) "dlrowOLLEH"

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Is reference counting necessary for a PHP implementation?

[Andrea Faulds]

Hi there,

Sidharth Kshatriya wrote:

In:

https://github.com/php/php-langspec/blob/master/spec/04-basic-concepts.md#reclamation-and-automatic-memory-management


Despite the use of the term refcount, conforming implementations are not

required to use a reference counting-based implementation for automatic
memory management.

Is this statement correct? If I understand correctly many PHP projects
depend on the deterministic firing of `__destruct()` function to cleanup
SQL transactions or connections and so forth.


It's __destruct() that is the problem, yes. If “running PHP code that 
relies on deterministic __destruct()” is what you mean by “a PHP 
implementation”, then yes, it's necessary. If not, then no. :)

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Is reference counting necessary for a PHP implementation?

[Stanislav Malyshev]

Hi!

> Is this statement correct? If I understand correctly many PHP projects
> depend on the deterministic firing of `__destruct()` function to cleanup
> SQL transactions or connections and so forth.

Yes. But, strictly speaking, you do not have to use specifically
refcounting - i.e. having some value to increment by 1 each time
reference is added and decremented by 1 each time reference is removed -
to achieve that. Pretty much none of the code requires there would be an
actual counter - only that the system would behave as if there was a
counter. Of course, in this case actually having the counter is the most
natural way of doing it :) But if you find some other way of achieving
the same semantics, I think it'd be still OK.

> instead could unlock measurable performance improvements, and the behavior
> of destructors could be closely imitated by a combination of try/finally
> and other new language constructs.

I am not sure I am convinced by this statement, and not sure how RAII
patterns would work in GC-based environments (i.e. it seems to me they
won't). That being said, many resource allocation scenarios can be
implemented without RAII (in fact, C doesn't have RAII at all, people
still manage to work with it :).

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Is reference counting necessary for a PHP implementation?

[Sidharth Kshatriya]

In:

https://github.com/php/php-langspec/blob/master/spec/04-basic-concepts.md#reclamation-and-automatic-memory-management

> Despite the use of the term refcount, conforming implementations are not
required to use a reference counting-based implementation for automatic
memory management.

Is this statement correct? If I understand correctly many PHP projects
depend on the deterministic firing of `__destruct()` function to cleanup
SQL transactions or connections and so forth.

HHVM elaborates on this:

> Eliminating destructors. Deterministic object destruction is the reason
why nonscalar PHP values require precise reference counting. This
requirement has long been, and continues to be, a sizable performance
bottleneck in our optimized JIT-compiled code. Using garbage collection
instead could unlock measurable performance improvements, and the behavior
of destructors could be closely imitated by a combination of try/finally
and other new language constructs.

(from http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html )

I'm curious about the answer here. Is ref counting necessary for all PHP
implementations like HHVM claims?

Thanks,

Sidharth

[PHP-DEV] Re: E_RECOVERABLE_ERROR for object to string conversion

[Christoph M. Becker]

On 27.09.2017 at 14:45, Marlies Heijkoop wrote:

> Hi Internals,
> 
> I stumbled upon a difference in behavior between PHP >=7.0 and HHVM when it 
> comes to object-to-string conversion for objects not implementing a 
> `__toString` which caught me by surprise.
> 
> It's probably a pretty common scenario, especially for inexperienced PHP 
> developers, as all it takes is to accidentally name your method `_toString()` 
> or `toString()` rather than `__toString()`.
> 
> When trying to use an object which does not implement a __toString(), PHP 
> will emit an E_RECOVERABLE_ERROR where HHVM throws an Error.
> See https://3v4l.org/WtJff  for a minimal example. HHVM's behavior makes more 
> sense to me here.
> 
> To me, PHP's behavior is especially unexpected if you consider the behavior 
> in https://3v4l.org/lF7gR where PHP *does* throw a (Type)Error because of the 
> typehint. Note this example works if you change `$a` for an instance of 
> something with a proper `__toString()`-method.
> 
> I searched through the discussions on the original 'Exceptions in the engine' 
> RFC and couldn't find any mention of this specific case so I was wondering if 
> anyone remembers if this was deliberately kept this way? I'm not sure if I 
> have the skill to write a patch, I'm willing to try, but it'd be a waste of 
> time if there is some good reason for having kept this an E_RECOVERABLE_ERROR 
> I'm unaware of.

I assume that this is closely related to the fact that PHP can't throw
from inside of __toString(), see  and
.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] E_RECOVERABLE_ERROR for object to string conversion

[Marlies Heijkoop]

Hi Internals,

I stumbled upon a difference in behavior between PHP >=7.0 and HHVM when it 
comes to object-to-string conversion for objects not implementing a 
`__toString` which caught me by surprise.

It's probably a pretty common scenario, especially for inexperienced PHP 
developers, as all it takes is to accidentally name your method `_toString()` 
or `toString()` rather than `__toString()`.

When trying to use an object which does not implement a __toString(), PHP will 
emit an E_RECOVERABLE_ERROR where HHVM throws an Error.
See https://3v4l.org/WtJff  for a minimal example. HHVM's behavior makes more 
sense to me here.

To me, PHP's behavior is especially unexpected if you consider the behavior in 
https://3v4l.org/lF7gR where PHP *does* throw a (Type)Error because of the 
typehint. Note this example works if you change `$a` for an instance of 
something with a proper `__toString()`-method.

I searched through the discussions on the original 'Exceptions in the engine' 
RFC and couldn't find any mention of this specific case so I was wondering if 
anyone remembers if this was deliberately kept this way? I'm not sure if I have 
the skill to write a patch, I'm willing to try, but it'd be a waste of time if 
there is some good reason for having kept this an E_RECOVERABLE_ERROR I'm 
unaware of.

Met vriendelijke groet,
 
Marlies Heijkoop
-
MobielWerkt BV / Belsimpel.nl
 
T. +31 (0)50 210 34 04
E. marlies.heijk...@belsimpel.nl
I. https://www.belsimpel.nl
 
Bezoekadres:
Waagstraat 1
9712 JX, Groningen
 
Postadres:
Postbus 3023
9701 DA, Groningen
 
Op deze e-mail is een disclaimer van toepassing, ga naar 
www.belsimpel.nl/disclaimer_email A disclaimer is applicable to this e-mail, 
please refer to www.belsimpel.nl/disclaimer_email


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Matteo Beccati]

On 27/09/2017 11:34, Lester Caine wrote:
> openBlob is a specific feature of SQLite so the decision to use it
> already rules out any other database. IN PDO access to it via the
> generic blob functions is the proper way forward so that a call for a
> blob gives a blob what ever the underlying datbase.

Seeing the RFC, I gave for granted that SQLite couldn't use the standard
LOB api provided by PDO, but maybe that isn't the case? I'll leave the
OP to reply.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Christoph M. Becker]

On 26.09.2017 at 04:03, BohwaZ/PHP wrote:

> following my patch and discussions on this list, here is the RFC
> requested by some people here to implement "openBlob" in the pdo_sqlite
> driver, to match the "openBlob" method from the SQLite3 extension.
> 
> https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> 
> Discussion should happen in the next two weeks before going to vote.
> 
> The actual patch is here: https://github.com/php/php-src/pull/2698
> 
> Suggestions and discussions welcome.

PDO already has support for large objects (LOBs)[1].  I don't know if
and how these are supported by the pdo_sqlite driver, but wouldn't it
make sense to use the existing API instead of introducing a new method?

[1] 

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Lester Caine]

On 27/09/17 10:17, Matteo Beccati wrote:
> On 27/09/2017 11:00, Lester Caine wrote:
>> The bigger question is - Should database specific extensions to PDO be
>> allowed at all? The WHOLE base of PDO was that it would allow easy data
>> management between DIFFERENT databases. This should be implemented in a
>> way that mirrors blobs generically otherwise the generic database driver
>> should be used since a switch to another PDO driver will fail. This
>> should apply to any targeted extension to PDO, so anything that breaks
>> the generic base data needs tidying up.

> That's a wrong assumption. PDO was born to allow quickly writing
> database drivers, not as an abstraction layer that allows you to
> seamlessly move from one another. I thought the same but I was corrected
> by someone that was involved in the process.

The whole base that PDO was allowed to be bundled was that it provided a
clean DATA abstraction that could be relied on. The fact that it
sidesteps the problems of SQL abstraction was pushed to one side as
something that could be handled later. If each driver is now producing
DIFFERENT sets of data then the whole generic base is broken. Why not
simply move back to the generic drivers which are a LOT more advanced
these days and rely on higher level abstraction layers where database
transparency is an advantage.

openBlob is a specific feature of SQLite so the decision to use it
already rules out any other database. IN PDO access to it via the
generic blob functions is the proper way forward so that a call for a
blob gives a blob what ever the underlying datbase.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Matteo Beccati]

Hey Marco,

On 27/09/2017 11:04, Marco Pivetta wrote:
> First time I agree with Lester here, so please take note :-P

Anything you say can and will be used against you ;-)


> Unless the type of the connection is PDOSQLiteConnection, this specific
> patch adds methods that are not interfaced, and need to be checked for
> existence every time. This is error-prone and just an annoyance that will
> likely need abstraction once it reaches "real world" (layers that isolate
> apps from PDO's inherent radioactivity).

This is the (possibly wrong) pattern that PDO has been using when
providing something that's relevant only for a specific driver. Such
methods should be used with caution.

What's your suggestion?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Matteo Beccati]

Hi Lester,

On 27/09/2017 11:00, Lester Caine wrote:
> The bigger question is - Should database specific extensions to PDO be
> allowed at all? The WHOLE base of PDO was that it would allow easy data
> management between DIFFERENT databases. This should be implemented in a
> way that mirrors blobs generically otherwise the generic database driver
> should be used since a switch to another PDO driver will fail. This
> should apply to any targeted extension to PDO, so anything that breaks
> the generic base data needs tidying up.

That's a wrong assumption. PDO was born to allow quickly writing
database drivers, not as an abstraction layer that allows you to
seamlessly move from one another. I thought the same but I was corrected
by someone that was involved in the process.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Marco Pivetta]

On Wed, Sep 27, 2017 at 11:00 AM, Lester Caine  wrote:

> On 27/09/17 09:47, Dan Ackroyd wrote:
> >> https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> >
> > Couple of questions:
> >
> >> $stream = $pdo->sqliteOpenBlob('test', 'data', 1);
> > I tried reading the code but failed; what happens when this is called
> > on a PDO connection that isn't to an SQLite database? Also, there
> > should probably be tests around that behaviour.
>
> The bigger question is - Should database specific extensions to PDO be
> allowed at all? The WHOLE base of PDO was that it would allow easy data
> management between DIFFERENT databases. This should be implemented in a
> way that mirrors blobs generically otherwise the generic database driver
> should be used since a switch to another PDO driver will fail. This
> should apply to any targeted extension to PDO, so anything that breaks
> the generic base data needs tidying up.
>

First time I agree with Lester here, so please take note :-P

Unless the type of the connection is PDOSQLiteConnection, this specific
patch adds methods that are not interfaced, and need to be checked for
existence every time. This is error-prone and just an annoyance that will
likely need abstraction once it reaches "real world" (layers that isolate
apps from PDO's inherent radioactivity).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Lester Caine]

On 27/09/17 09:47, Dan Ackroyd wrote:
>> https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo
> 
> Couple of questions:
> 
>> $stream = $pdo->sqliteOpenBlob('test', 'data', 1);
> I tried reading the code but failed; what happens when this is called
> on a PDO connection that isn't to an SQLite database? Also, there
> should probably be tests around that behaviour.

The bigger question is - Should database specific extensions to PDO be
allowed at all? The WHOLE base of PDO was that it would allow easy data
management between DIFFERENT databases. This should be implemented in a
way that mirrors blobs generically otherwise the generic database driver
should be used since a switch to another PDO driver will fail. This
should apply to any targeted extension to PDO, so anything that breaks
the generic base data needs tidying up.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Dan Ackroyd]

On 26 September 2017 at 03:03, BohwaZ/PHP  wrote:
> Kia ora,
>
> https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo


Couple of questions:

> $stream = $pdo->sqliteOpenBlob('test', 'data', 1);

I tried reading the code but failed; what happens when this is called
on a PDO connection that isn't to an SQLite database? Also, there
should probably be tests around that behaviour.

> Proposed PHP Version(s)
> Next PHP 7.x

Please can every RFC be explicit about the version it is aimed at?

Although it might be 'obvious' to you, in the future when someone is
looking back at declined RFCs trying to match up release dates with
RFCs that have 'next' as the version number is confusing.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Implement SQLite "openBlob" feature in PDO

[Adam Baratz]

>
> following my patch and discussions on this list, here is the RFC requested
> by some people here to implement "openBlob" in the pdo_sqlite driver, to
> match the "openBlob" method from the SQLite3 extension.


Thanks for taking the time to do the writeup. No objections from me.

Adam