[RFC] Weak References

14 years ago by Hannes Landeholm — view source — reply

unread

Hello,

This is the official RFC discussion thread for Weak References and an
announcement of the RFC.

Please read the RFC before replying: https://wiki.php.net/rfc/weakreferences

In a nutshell: The RFC proposes adding a single class called "SplWeakRef"
which provides the "Weak Reference" feature. This is the only change.

Previous thread was here: http://news.php.net/php.internals/53963

I'm creating this new thread for several reasons. First of all I feel that
the RFC is now somewhat complete and an announcement should be formally made
with the [RFC] subject in accordance to the voting procedure. Also the other
thread has more general discussion on internal reference counting and
garbage collection. Please keep this thread on topic - specifically about
Weak References and the RFC. If you plan on voting no to this feature,
please reply to this thread so we can discuss your concerns.

As I've previously stated, I hope that this feature can be released with PHP
5.4 since I need it for my own projects and open source framework. I don't
think this is unreasonable since it's such a simple class and also
non-controversial. It has been an established feature in many other major
OOP languages for years. I will therefore initiate voting as soon as
possible (In two weeks).

Thanks Etienne Kneuss for creating the first version of the RFC and the
patch and others for discussing it.

~Hannes

14 years ago by Adam Harvey — view source — reply

unread

In a nutshell: The RFC proposes adding a single class called "SplWeakRef"
which provides the "Weak Reference" feature. This is the only change.

This may just be Monday morning fuzziness, or I've just missed something in
the RFC, but is there a reason weak references would be limited solely to
objects, rather than any variable that can be dealt with by-reference?

Thanks,

Adam

14 years ago by Hannes Landeholm — view source — reply

unread

Weak references is an OOP concept. Scalar data types and arrays are not
OOP-related so I don't think that would make sense. Variable references is
not the same as object references. A variable reference is simply a variable
that is connected with another variable (if you set one it will change the
other). If two variables have the same object reference they are not
connected, if you set one variable the other is still set to the initial
object reference.

Also, arays and strings have special memory handling - they use lazy copying
so it's opaque if two equal arrays/strings refer to the same region of
memory. It's unclear what construction/destruction even mean in that sense.
An array might actually have been "constructed" by the compiler. A reference
to an object instance is a "pointer" but a reference to a variable is not.

http://us.php.net/manual/en/language.references.arent.php

I hope that illustrates the difference.

Do you have any special use case in mind?

~Hannes

This may just be Monday morning fuzziness, or I've just missed something in
the RFC, but is there a reason weak references would be limited solely to
objects, rather than any variable that can be dealt with by-reference?

Thanks,

Adam

14 years ago by Adam Harvey — view source — reply

unread

Weak references is an OOP concept. Scalar data types and arrays are not
OOP-related so I don't think that would make sense. Variable references is
not the same as object references. A variable reference is simply a variable
that is connected with another variable (if you set one it will change the
other). If two variables have the same object reference they are not
connected, if you set one variable the other is still set to the initial
object reference.

Also, arays and strings have special memory handling - they use lazy
copying so it's opaque if two equal arrays/strings refer to the same region
of memory. It's unclear what construction/destruction even mean in that
sense. An array might actually have been "constructed" by the compiler. A
reference to an object instance is a "pointer" but a reference to a variable
is not.

http://us.php.net/manual/en/language.references.arent.php

I hope that illustrates the difference.

Do you have any special use case in mind?

Nothing in particular, and I understand the differences in memory and
reference handling between objects and other variables within PHP. It just
seemed like an inconsistency, and I was curious whether it was a design or
technical decision.

I guess the answer to that is "yes". :)

Thanks,

Adam

14 years ago by Etienne Kneuss — view source — reply

unread

Hi,

In a nutshell: The RFC proposes adding a single class called "SplWeakRef"
which provides the "Weak Reference" feature. This is the only change.

This may just be Monday morning fuzziness, or I've just missed something in
the RFC, but is there a reason weak references would be limited solely to
objects, rather than any variable that can be dealt with by-reference?

Other kinds of variables does not allow us to define specific hooks
like for objects. Implementing weak references (note that in this
context reference != php reference, but object reference) for other
types would require considerable changes to the engine, which we are
trying to avoid here.

In this case, for objects, the implementation remains quite simple,
because objects allow such introspection already.

Last but not least, it also makes little sense to do so from a design
perspective, as other types do not provide the handle indirection that
objects do.

Thanks,

Adam

--
Etienne Kneuss
http://www.colder.ch

14 years ago by Hannes Landeholm — view source — reply

unread

Hello guys,

I'd just like to remind you that I plan to initiate voting for this RFC on
Monday (less than 2 days) so if you plan on voting no, please reply here
asap so we can discuss your concerns.

Thank you for your time,

~Hannes

14 years ago by Hannes Landeholm — view source — reply

unread

Hi,

I'd like to initiate voting on this RFC today since the minimum period of
two weeks has now passed. Can someone with the right wiki
powers/responsibilities start a vote and announce the [VOTE] on the mailing
list?

Thank you,

~Hannes

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

Hi,

I'd like to initiate voting on this RFC today since the minimum period of
two weeks has now passed. Can someone with the right wiki
powers/responsibilities start a vote and announce the [VOTE] on the mailing
list?

I think I'm missing some important point here. Why this can't be
implemented as PECL extension? I looked at the patch and saw nothing
that requires engine involvement. So why not just create a PECL
extension? If people start using it and it gets popular, we can merge it
to core as we did with many others.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Hannes Landeholm — view source — reply

unread

Arguably the feature is already "popular". I have pointed this out many
times before but many other major OO languages provides weak references
natively. Read the introduction in the RFC.

Pragmatically speaking (as a framework designer) you are unfortunately not
so privileged on what PECL/PHP extensions people should use and have loaded
or not. Many hosting providers does not give you the option to load your own
extensions and does not change the default configuration. So you are really
avoiding non standard features when designing generic
applications/frameworks that should be usable by anyone. This means that the
PECL extension popularity proves nothing. Implementing it as a PECL
extension will most likely prevent people from using it. I wouldn't.

Finally to fully support Weak References in the future it has too make some
small adjustments to the GC so the collection event can actually be caught
(see rfc/additional cleanup and __destruct()). That might also be reason to
why it should be implemented directly. Etienne Kneuss should be able to
answer this better.

~Hannes

Hi!

I think I'm missing some important point here. Why this can't be
implemented as PECL extension? I looked at the patch and saw nothing that
requires engine involvement. So why not just create a PECL extension? If
people start using it and it gets popular, we can merge it to core as we did
with many others.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Hannes Landeholm — view source — reply

unread

Hi,

Yes, I'm also interested in caching - It's a very interesting subject...
borderline philosophical. When you are caching model instances in a database
object relation layer you could clearly benefit from implementing some kind
of caching mechanism that retains object even though it's unclear whether
they actually need to be used (because you can't look into the future and
known if the web application will select this ID again). I think it's bad
design though to cache everything you can lay your hands on - memory usage
is important. Also, database drivers and servers supply internal query
caching. The programmer can achieve memory optimization caching by putting
objects in a static variable if he knows he will need those objects later if
the framework supplies internal weak-referencing. Trying to achieve this
automatically with statistics and guessing would obviously not be as good a
solution. But I stand by that "weak references" is not designed to solve
this problem since it achieves the opposite - it removes caching - and it
also solves other problems in other domains.

If I was really looking for a solution to this caching problem I would
instead suggest an RFC that supplied a cache where you could put objects in
a "recycle bin" state instead with different priority levels when
destructing. The GC would then be allowed to make intelligent decisions on
whether to allocate more OS memory or deallocate objects in the recycle bin
pool depending on total PHP memory usage, total system memory and object
recycle bin priorities. A userland programmer could also be allowed to
"restore" objects from the recycle bin on demand. But that would be a
completely separate RFC. Feel free to make a draft if you like.

~Hannes

And yes, my main concern is to keep it simple so SplWeakRef could be
implemented as quickly as possible.

Hi Hannes,

I think I like it after all;) What I don't understand is why you insist on
WeakReferences not being about caching, when your first usecase clearly is
at least related to caching. When mapping a DB-Record on a PHP-Object
on-demand and then keeping it instead of recreating it every time you need
it...of course you can argue it's not about caching because you'll be
dropping it as soon as you're not using it anymore...but isn't that a
deficiency rather than a different mechanism? As I've read in your quoted
article SoftReferences are used for that kind of stuff...and I'd really be
interested in that.

But I guess your main concern is to keep it simple to make sure that it
gets accepted into 5.4?...

Thanks for the RFC and the proposal...it seems like a useful feature to me
now.

Cheers.
Lars