Hi,
On Fri, Sep 9, 2011 at 10:14, Nicolas Grekas
wrote:
>
> I don't understand how the code you just gave would be useful in practice?
>>
>
> Is that question for me ? If yes, which code are you talking about ?
>
> $pseudoWeakMap = array();
> $pseudoWeakMap[spl_object_**hash($obj)] = new WeakRef
> I don't understand how the code you just gave would be useful in practice?
>
Is that question for me ? If yes, which code are you talking about ?
I've implemented a WeakMap class in the weakref pecl ext, see:
>
For ref:
https://github.com/colder/php-weakref/blob/master/tests/weakmap_001.phpt
Hi,
On Sat, Sep 3, 2011 at 19:21, Nicolas Grekas
wrote:
> >
> > $pseudoWeakMap = array();
> > $pseudoWeakMap[spl_object_**hash($obj)] = new WeakReference($obj);
> >
> > or did I misunderstand the concept? I hope I'll have a chance to use
> > WeakReferences soon in my project;)
>
>
>
> I also beli
>
> $pseudoWeakMap = array();
> $pseudoWeakMap[spl_object_**hash($obj)] = new WeakReference($obj);
>
> or did I misunderstand the concept? I hope I'll have a chance to use
> WeakReferences soon in my project;)
I also believe that this is the logic, but from the doc, when an object is
destroyed,
Hi,
On Sat, Sep 3, 2011 at 17:14, Lars Schultz wrote:
> Am 03.09.2011 13:56, schrieb Etienne Kneuss:
>
>> Indeed, I planned to implement that as well, I haven't had the time to do
>> it
>>
>> yet though. It should happen in the following weeks.
>>
>
> Not to keep you from doing this...but couldn'
Am 03.09.2011 13:56, schrieb Etienne Kneuss:
Indeed, I planned to implement that as well, I haven't had the time to do it
yet though. It should happen in the following weeks.
Not to keep you from doing this...but couldn't that easily be solved by
using a simple associative php array like this:
On Sat, Sep 3, 2011 at 13:57, Ferenc Kovacs wrote:
> > Weak references have been implemented in a PECL extension since weeks
> now:
> > http://php.net/weakref and/or http://pecl.php.net/weakref
> >
> > It feels like you're beating up a dead horse here.
> >
> > A discussion for bundling it might o
> Weak references have been implemented in a PECL extension since weeks now:
> http://php.net/weakref and/or http://pecl.php.net/weakref
>
> It feels like you're beating up a dead horse here.
>
> A discussion for bundling it might occur in the future, but given the
> feedbacks PECL might very well
Hi,
On Fri, Sep 2, 2011 at 14:25, Nicolas Grekas
wrote:
> How about adding weak maps to this RFC?
>
>
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/WeakMap
>
> This would be fantastic!
>
> Nicolas
>
Indeed, I planned to implement that as well, I haven't had the time to d
Hi,
On Tue, Aug 9, 2011 at 14:22, Arvids Godjuks wrote:
> I have mixed feelings about this proposal - from one point it's quite
> neat - ability to mark circular references for the memory manager so
> it can free them sounds very delicious, especially for some cases. I
> had run into my own bunch
How about adding weak maps to this RFC?
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/WeakMap
This would be fantastic!
Nicolas
On Tue, Aug 9, 2011 at 14:55, Lars Schultz wrote:
> Am 09.08.2011 14:22, schrieb Arvids Godjuks:
>
> I have mixed feelings about this proposal
Am 09.08.2011 14:22, schrieb Arvids Godjuks:
I have mixed feelings about this proposal - from one point it's quite
neat - ability to mark circular references for the memory manager so
it can free them sounds very delicious, especially for some cases. I
had run into my own bunch of problems with m
I have mixed feelings about this proposal - from one point it's quite
neat - ability to mark circular references for the memory manager so
it can free them sounds very delicious, especially for some cases. I
had run into my own bunch of problems with memory in PHP in the past
and right now I'm runn
Am 06.08.2011 14:09, schrieb pierre@gmail.com:
Out of curiosity, which bc issue blocks the move?
The fact that after 5.2.6 we can't set "mbstring.func_overload"
PHP_INI_PERDIR anymore, but need to set it for the whole installation
(PHP_INI_SYSTEM). Which wasn't even mentioned in the chang
Am 06.08.2011 02:14, schrieb Hannes Landeholm:
Yeah I think there's a lot of misunderstandings going on with weak/soft
references and how the garbage collector works. Weak/soft references is not
some kind of solution to the cyclic reference problem. The GC takes care of
that already. You can use
Hannes Landeholm wrote:
- Weak references solves the loose coupled object indexing problem. "I need
this reference as long as it's referenced somewhere else."
- Soft references solves the caching problem. "I need this reference as long
as we have plenty of memory available."
- The GC solves the c
Good explanation Ferenc.
Yeah I think there's a lot of misunderstandings going on with weak/soft
references and how the garbage collector works. Weak/soft references is not
some kind of solution to the cyclic reference problem. The GC takes care of
that already. You can use whatever OOP patterns w
> A parent references its childs and each child references its parent.
> circular-reference nightmare...with WeakReferences I could use a
> weakReference for storing the parent...so that if the parents last real
> reference is discarded the childs will cleaned out as well.
that is why we added the
Am 05.08.2011 18:29, schrieb Hannes Landeholm:
It's interesting to think about though.
I'd definitely find a use for them;) I might just patch our
installations to provide me with the zval-refcount and go with that for
now...I have been warned, but I have to burn myself before I believe
that
Am 05.08.2011 19:46, schrieb Jezz Goodwin:
As Chris Stockton points out http://news.php.net/php.internals/54391
there is always going to be additional code that has to check to see if
the reference is still valid.
But don't you see that in exchange for one little IF you get so much
more...what's
It sounds to me that weak/soft references are only really half a
solution to a problem.
As Chris Stockton points out http://news.php.net/php.internals/54391
there is always going to be additional code that has to check to see if
the reference is still valid.
If the only concern here is runni
Soft references could theoretically be implemented if PHP only implemented
weak references even though the implementation would consist of a very ugly
and "coincidental" hack.
Lets say you had an object A that you wouldn't want to be collected until
approximately when PHP needs more memory. E.g. w
Am 05.08.2011 14:58, schrieb John LeSueur:
Are there other advantages I'm missing?
If I may, I'll respond to your questions with 3 examples.
A) Naive, straight forward approach (this will run out of memory if
objects are heavy)
http://pastie.org/2325252
B) Previous approach taking memory int
On Thu, Aug 4, 2011 at 2:53 PM, Ferenc Kovacs wrote:
>
> On Thu, Aug 4, 2011 at 6:35 PM, Stas Malyshev wrote:
> > Hi!
> > On 8/4/11 5:34 AM, Lars Schultz wrote:
> >>>
> >>> Do not keep object references, keep object IDs. This would make your
> >>> code a bit more verbose and a bit slower, but wea
Am 05.08.2011 08:07, schrieb Rasmus Lerdorf:
Ticks have been in PHP forever. See
http://www.php.net/manual/en/control-structures.declare.php#control-structures.declare.ticks
woha! interesting read. thanks:)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
On 08/04/2011 11:00 PM, Lars Schultz wrote:
> Could you explain ticks?...to me a tick is a nasty little creature that
> bites and gives you infections;)
Ticks have been in PHP forever. See
http://www.php.net/manual/en/control-structures.declare.php#control-structures.declare.ticks
-Rasmus
--
PH
Am 04.08.2011 23:19, schrieb Chris Stockton:
I myself oppose WeakReference in java and I do not see my opinion
changing for PHP ... unfortunately I think WeakReference's are even
nastier in PHP because of it's error handling. You see it is very
common when weak references are used in java too fol
Hello,
On Thu, Aug 4, 2011 at 1:53 PM, Ferenc Kovacs wrote:
> so as I see you didn't really addressed the proposed use-case of the
> Weak References, just stated what everybody is aware of: one can cache
> and free objects "manually" without the need of Weak References.
> and while that is true,
On Thu, Aug 4, 2011 at 6:35 PM, Stas Malyshev wrote:
> Hi!
> On 8/4/11 5:34 AM, Lars Schultz wrote:
>>>
>>> Do not keep object references, keep object IDs. This would make your
>>> code a bit more verbose and a bit slower, but weak refs would
>>> essentially do the same anyway.
>>
>> This is like
Am 04.08.2011 18:35, schrieb Stas Malyshev:
No, it's not even remotely like that. Using one intermediary function
and doing the DB call is orders of magnitude apart. You asked how you
can solve the problem, I showed you how. You can claim you don't like
the solution, that's fine, everybody has hi
Hi!
On 8/4/11 5:34 AM, Lars Schultz wrote:
Do not keep object references, keep object IDs. This would make your
code a bit more verbose and a bit slower, but weak refs would
essentially do the same anyway.
This is like saying: do not use objects at all and use the DB for
storage. verbosity and
Am 04.08.2011 09:17, schrieb Stas Malyshev:
I'm sorry but you putting forth contradictory requirements here - you
want to keep the objects (to avoid "expensively reconstructing" them)
and you don't want to keep them (memory problems). You'll have to give
up one of these requirements. As I see, yo
On Thu, Aug 4, 2011 at 10:37 AM, Lester Caine wrote:
> Stas Malyshev wrote:
>>>
>>> I am open to any suggestions how I could solve my problem without
>>> WeakReference or zval-refcount (short of keeping a ref-count in
>>> userland).
>>
>> Do not keep object references, keep object IDs. This would
Stas Malyshev wrote:
I am open to any suggestions how I could solve my problem without
WeakReference or zval-refcount (short of keeping a ref-count in
userland).
Do not keep object references, keep object IDs. This would make your
code a bit more verbose and a bit slower, but weak refs would
es
Hi!
On 8/3/11 11:03 PM, Lars Schultz wrote:
(from the cache). This works very well and keeps me from expensively
reconstructing objects from the DB. What it does not work well with is
Garbage collection, since the an object will always be referenced at
least once (by the cache). The longer a scr
Am 04.08.2011 02:32, schrieb Stas Malyshev:
I'm not sure I understand why you need week refs there - can't you just
always use $prodDb->getProduct(1) and when you don't need it anymore
just do $prodDb->drop(1)? Or let it drop it whenever it wants to?
My Project requires lots of DB-Record <=> PH
Hi!
On 8/3/11 12:22 PM, Jan Dolecek wrote:
Thanks Etienne,
I was waiting for this for a while! I wrote a blog post how to get
best benefits from weak references:
http://blog.juzna.cz/2011/08/weak-references-in-php/
Perhaps this will help showing people what are they good for.
I'm not sure I
On Thu, Aug 4, 2011 at 12:35 AM, Jonathan Bond-Caron wrote:
> On Wed Aug 3 05:16 PM, Lester Caine wrote:
>> Jan Dolecek wrote:
>> > I was waiting for this for a while! I wrote a blog post how to get
>> > best benefits from weak references:
>> > http://blog.juzna.cz/2011/08/weak-references-in-php/
On Wed Aug 3 05:16 PM, Lester Caine wrote:
> Jan Dolecek wrote:
> > I was waiting for this for a while! I wrote a blog post how to get
> > best benefits from weak references:
> > http://blog.juzna.cz/2011/08/weak-references-in-php/
> > Perhaps this will help showing people what are they good for.
Jan Dolecek wrote:
I was waiting for this for a while! I wrote a blog post how to get
best benefits from weak references:
http://blog.juzna.cz/2011/08/weak-references-in-php/
Perhaps this will help showing people what are they good for.
This again relates to MySQl's method of working ...
ibase_
Thanks Etienne,
I was waiting for this for a while! I wrote a blog post how to get
best benefits from weak references:
http://blog.juzna.cz/2011/08/weak-references-in-php/
Perhaps this will help showing people what are they good for.
And thanks to PECL extension I hope we can start using them in
On Wed, Aug 3, 2011 at 4:29 PM, Etienne Kneuss wrote:
> Hi,
>
> http://pecl.php.net/package/Weakref has been created, and the
> standalone code should compile fine (I checked for 5_3 only but
> everything should be smooth for 5_4/trunk)
Not exactly (for the record here):
weakref.c
g:\php-sdk\ph
Hi,
On Wed, Aug 3, 2011 at 16:35, Gustavo Lopes wrote:
> Em Wed, 03 Aug 2011 15:29:20 +0100, Etienne Kneuss
> escreveu:
>
>> Hi,
>>
>> http://pecl.php.net/package/Weakref has been created, and the
>> standalone code should compile fine (I checked for 5_3 only but
>> everything should be smooth f
Em Wed, 03 Aug 2011 15:29:20 +0100, Etienne Kneuss
escreveu:
Hi,
http://pecl.php.net/package/Weakref has been created, and the
standalone code should compile fine (I checked for 5_3 only but
everything should be smooth for 5_4/trunk)
The next planned addition is a StrongRef class, following
Hi,
http://pecl.php.net/package/Weakref has been created, and the
standalone code should compile fine (I checked for 5_3 only but
everything should be smooth for 5_4/trunk)
The next planned addition is a StrongRef class, following the exact
same interface as WeakRef only that it is always valid a
Good idea. I will see what I can do when I get time.
~Hannes
On 3 August 2011 12:32, Pierre Joye wrote:
> hi Hannes,
>
> I would suggest to still update the RFC with the various very
> instructive comments and example use cases you use in this thread.
> Doing the same in the long run should help
hi Hannes,
I would suggest to still update the RFC with the various very
instructive comments and example use cases you use in this thread.
Doing the same in the long run should help as well to understand the
goals, implementations, etc., for the pecl users or for the 2nd
attempt to get it in the
Hello,
We had a healthy discussion around WR and I have been able to express
my concerns. The consensus is clearly to put it in a PECL extension so
I think this discussion should move on to the practical matters of
doing this. I suggest aborting the vote and changing the RFC state to
something lik
Am 03.08.2011 09:35, schrieb Lester Caine:
I think this is were I am sitting at the moment ... If a script needs to
tidy up memory because something has gone wrong, then in my book the
script is faulty? The example of why it is needed does not make sense to
me, probably because I don't understand
Rasmus Lerdorf wrote:
I think the only valid point for putting this in core is that it does
feel more like a core feature than a pecl add-on. However, a number of
us are uncomfortable with the impact of it and would like to understand
better how people other than yourself would use it, or more li
On 08/02/2011 06:25 PM, Hannes Landeholm wrote:
> I have no problem compiling extensions and I also don't have any
> customers on share hosting. Although it wastes a bit more of my time
> I'm personally fine with PECL. I'm contributing to open source though
> so I'm concerned with the users that wo
Hi!
On 8/2/11 6:25 PM, Hannes Landeholm wrote:
I'm referring to the fact that PHP has a major update once a year.
Looking at it from an agile perspective this is insanely slow. I think
you should use smaller iterations and release faster. The new Mozilla
release schedule is a good example.
Hav
Tired...
> I don't agree with the concept of putting new feature in PECL itself...
should of course be:
>I don't disagree with the concept of putting new feature in PECL itself...
~Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Hello Stas,
On 3 August 2011 02:39, Stas Malyshev wrote:>
> I notice some tone of hostility here.
I'm not hostile. Perhaps a bit disappointed that the PECL objection
wasn't brought up earlier in the discussion period so It could have
been toughly discussed.
> /* snip */
> This is why we tend to
On 08/02/2011 05:44 PM, Hannes Landeholm wrote:
I had a two week discussion period that was mostly silent and I felt
the consensus was generally in favor of the feature which is why I
started the vote.
@internals silence on new features can be interpreted both ways.
Looking at the general fe
On 2 August 2011 23:32, Chris Stockton wrote:
> I would like to make a couple points here, first I is that PECL is not
> a place for a extension to rot, that statement makes absolutely no
> sense to me. PDO I recall years ago getting from PECL, Http a
> extension I often use, was recently on this
Hi!
On 8/1/11 3:30 PM, Hannes Landeholm wrote:
lists or write RFC's or learn C or jump trough endless hoops in a
process designed so that the core development team can ignore the
community more democratically. The users that just suck it up and
design their applications or frameworks poorly inst
Hannes Landeholm wrote:
Certain function in the application runs a MySQL procedure that updates a
> certain complex selection of products in the products database rendering the
> currently loaded products in memory obsolete since they might have been
> updated.
Then you are caching the wrong da
Adding a new feature to the latest version of PHP will not make it
available to users of shared hosting. Many of these are running on older
versions and it takes time for them to get updated to the latest.
- Frank
On 8/2/11 11:06 AM, Hannes Landeholm wrote:
I've talked to Etienne and he sti
Hello,
On Tue, Aug 2, 2011 at 11:06 AM, Hannes Landeholm wrote:
> I've talked to Etienne and he still believes we should vote on this so the
> vote is still up. He just replied to quickly. If the vote fails the patch
> can still be implemented in a PECL extension. There's no point canceling the
I've talked to Etienne and he still believes we should vote on this so the
vote is still up. He just replied to quickly. If the vote fails the patch
can still be implemented in a PECL extension. There's no point canceling the
vote or the RFC - it's still valid and ongoing, and there is still time
Hannes Landeholm wrote:
I've been a PHP fan for years and endured the patchy OO implementation
and the limitations that has come with the language for the
simplicity. Unfortunately I don't have time to wait for years even if
many of you guys do. If I did I wouldn't have bothered writing the RFC
o
On Tue, 2 Aug 2011, Hannes Landeholm wrote:
> (This announcement was sent twice since the last announcement was
> merged with the existing thread instead of starting a new thread.)
No it wasn't. There were no References or In-Reply-To headers. Anything
that merged it did it wrongly.
Derick
--
On Aug 2, 2011 2:50 AM, "Hannes Landeholm" wrote:
> aharvey: I'm surprised you voted no since you seemed content with the
> answers you got earlier. Do you have some special objection in mind?
Sorry, I meant to send an e-mail last night explaining the -1 and
completely forgot before I went to bed
Hello,
Voting is now open for the weak references RFC.
The RFC and patch can be found here:
https://wiki.php.net/rfc/weakreferences
You can vote here:
https://wiki.php.net/rfc/weakreferences/vote
(This announcement was sent twice since the last announcement was
merged with the existing thread i
> However, I feel like it is premature to vote on that one. For one, I'm
> not convinced by this feature yet. I'm not sure it is the right way to
> do it, or if it is actually needed.
Using weak references is the only way to design non caching references
and the only way to correctly implement the
Hello,
On Mon, Aug 1, 2011 at 21:16, Pierre Joye wrote:
> hi,
>
> You have to start a new thread to begin a vote, see the voting RFC. So
> everyone will see it.
>
> However, I feel like it is premature to vote on that one. For one, I'm
> not convinced by this feature yet. I'm not sure it is the r
hi,
You have to start a new thread to begin a vote, see the voting RFC. So
everyone will see it.
However, I feel like it is premature to vote on that one. For one, I'm
not convinced by this feature yet. I'm not sure it is the right way to
do it, or if it is actually needed. The more I look at it
Hello,
I would just like to remind you that the voting will take place for 7
more days so there are still time to discuss your concerns. If you
find something confusing or have objections I would be very interested
in hearing them and discussing that _before_ you vote as I have
reminded you twice
Sorry that this was unclear,
$obj is defined in the comment that says "// compute $obj"
Imagine a SQL query there or otherwise code that constructs $obj from
an external data source.
Regards,
Hannes
On 1 August 2011 20:27, guilhermebla...@gmail.com
wrote:
> Hi,
>
> I like this idea. But I'd l
Hi,
I like this idea. But I'd like to ask something; maybe someone could
please correct the Example section of RFC?
Unfortunately, I cannot understand how it could work on "else"
conditional block, because $obj is undefined.
Cheers,
On Mon, Aug 1, 2011 at 1:46 PM, Hannes Landeholm wrote:
> Hell
Hello,
Voting is now open for the weak references RFC.
The RFC and patch can be found here:
https://wiki.php.net/rfc/weakreferences
You can vote here:
https://wiki.php.net/rfc/weakreferences/vote
I don't seem to be able to vote myself and I'm not sure if that's an
error or not.
Regards,
Hanne
72 matches
Mail list logo
