hi pierre,
i've tested the patch that you proposed via IRC (attached) and it seems
to work for me against 5.2.8. passes valgrind too, without any detected
errors or leaks.
it's unfortunate that there isn't a more surgical fix (301 insertions!),
but i'll take your word for it that it would be too
On Thursday 22 January 2009 8:21:28 am Christian Seiler wrote:
> Hi everybody,
>
> We had that chat that Lukas announced yesterday and I promised Lukas to
> sum up the results of that chat.
>
> Problem was: There were only four people really there: Stas, Lukas,
> David and me. Lukas was interested
Hello,
On Tue, Jan 20, 2009 at 2:38 PM, Etienne Kneuss wrote:
> Hello,
>
> On Tue, Jan 20, 2009 at 2:23 PM, Guilherme Blanco
> wrote:
>> Etienne,
>>
>> We all already considered to not implement spl_object_id as long as
>> spl_object_hash is optimized.
>
> Ok then, I'll provide a patch to improv
On Thu, Jan 22, 2009 at 9:12 PM, Lukas Kahwe Smith wrote:
>
> On 22.01.2009, at 21:08, Pierre Joye wrote:
>>
>> I'm talking about the features we already have, not about adding more
>> major features. If one of the new features is not complete and we know
>> it, why do you want to go ahead then? I
On 22.01.2009, at 21:08, Pierre Joye wrote:
I'm talking about the features we already have, not about adding more
major features. If one of the new features is not complete and we know
it, why do you want to go ahead then? I can't find any good reason.
because it means all the other features
Hi!
I'm talking about the features we already have, not about adding more
major features. If one of the new features is not complete and we know
it, why do you want to go ahead then? I can't find any good reason.
You can argue every feature is not complete because there's always
something som
On Thu, Jan 22, 2009 at 8:48 PM, Lukas Kahwe Smith wrote:
>
> On 22.01.2009, at 20:39, Pierre Joye wrote:
>
>> hi,
>>
>> On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler
>> wrote:
>>>
>>> Hi again,
>>>
>>> ok, I just verified that the current PHP 5.3 CVS has the same behaviour
>>> as PHP 5.3 alp
On 22.01.2009, at 20:39, Pierre Joye wrote:
hi,
On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler
wrote:
Hi again,
ok, I just verified that the current PHP 5.3 CVS has the same
behaviour
as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
suggest the following:
* Feat
hi,
On Thu, Jan 22, 2009 at 7:36 PM, Christian Seiler wrote:
> Hi again,
>
> ok, I just verified that the current PHP 5.3 CVS has the same behaviour
> as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
> suggest the following:
>
> * Feature freeze as Lukas and Johannes had plan
Hi again,
ok, I just verified that the current PHP 5.3 CVS has the same behaviour
as PHP 5.3 alpha 3 (which is the original design). So basically, I'd
suggest the following:
* Feature freeze as Lukas and Johannes had planned tomorrow with *no*
more changes wrt. closures for beta1, then releas
On Thu, 2009-01-22 at 13:38 +0100, Pierre Joye wrote:
> > It's been a long time for 5.3 already ... let's try to make release
> > cycles shorter, not longer!
>
> There is no pressure on us to push a release.
Yes, if we decide to never release it's fine, but if we want to release
ever we have to d
Why not just enhance get_class() function to accept the object itself
(not only the instance)?
This means:
- No new keyword
- No magic Foo::__MIRACLEHERE__
- No 50 pages documentation to help user
Hi,
You can't do this. get_class(SomeClass) would attempt to pass constant named
SomeClass t
Hi!
There is no pressure on us to push a release. If some features are
missing to make the new additions complete then let us complete them
before 5.3.0-final. That's exactly why we have test releases or tests
phases. It is really annoying to have half backed features
Yes there is pressure. We
Hi!
I like conformity. If my voice counts, I would be happy to accept this
as a BC. If necessary, all for "class" to be implied until V6 or V5.4
But "use" doesn't import classes, it imports names. The name doesn't
have to be class at all.
and mark it as an E_STRICT or E_DEPRECATED ("use Fo
Hi,
As a former GSoCer I think the php-gsoc@ mailing list would be a great idea.
One thing I noticed was that I really had no idea how most other studen't
projects were going besides the few that poped into IRC from time to time.
Another advantage of the php-gsoc list is that the internals list ca
Hi Dmitry,
> The only difference is in binding/creation. You suggest
>
> $obj->method2 = Closure::bind ($obj, function () { ... });
>
> and I would prefer something like
>
> create_prototype_method($obj, "method2", function () { ... });
I prefer a static method of the Closure class because it
I like the proposal. I got near the same idea few hours ago :)
The only difference is in binding/creation. You suggest
$obj->method2 = Closure::bind ($obj, function () { ... });
and I would prefer something like
create_prototype_method($obj, "method2", function () { ... });
But it's not a big
Hi everybody,
We had that chat that Lukas announced yesterday and I promised Lukas to
sum up the results of that chat.
Problem was: There were only four people really there: Stas, Lukas,
David and me. Lukas was interested in getting results in order to be
able to release PHP 5.3 beta 1, Stas and
Hi Marcus,
I've just got an idea how prototyping may be implemented without magic
you solution had. We can use a special function
function attach_method($object, $name, $closure);
This function should clone the $closure bind $this of clone of $closure
to $object and assign it into $object->n
Removing an already working feature is just weird IMHO.
Also... this proposal reminds me to an older discussion (please for
God sake, no flaming mails!) that Greg did some time ago that if using
"use class Foo\Bar;" was enough to differ between a static call and a
ns call. It as one of the proposa
Marcus Boerger wrote:
Aren't we able to bind these at least partially to the function call
opcode, in case we know they are constant? If all is constsnt we could
even store the whole lookup in the opcode. Well you'd have to convince
Zend to do that because os far they have always been against t
Why not just enhance get_class() function to accept the object itself
(not only the instance)?
This means:
- No new keyword
- No magic Foo::__MIRACLEHERE__
- No 50 pages documentation to help user
Regards,
On Thu, Jan 22, 2009 at 5:24 AM, Stan Vassilev | FM
wrote:
>
>
>> Especially in namespace
On Thu, Jan 22, 2009 at 1:19 PM, Johannes Schlüter wrote:
> On Wed, 2009-01-21 at 14:19 -0600, Greg Beaver wrote:
>> [RFC]
>> Implement importing of functions to complement importing of classes and
>> namespaces.
>
> It was aid that import should only work with classes. We might extend
> that but
On Wed, 2009-01-21 at 14:19 -0600, Greg Beaver wrote:
> [RFC]
> Implement importing of functions to complement importing of classes and
> namespaces.
It was aid that import should only work with classes. We might extend
that but not for 5.3! The only engine feature to change are closures and
there
Hi Pierre,
In general you are right.
I fixed the behavior of realpath() to do the same as php-5.2, where
"c:file" means the same as "c:\file".
However, on Windows "c:file" means different thing. It means the "file"
from current working directory on drive "c" (each drive has its own CWD
which
2009/1/22 Larry Garfield :
> On Wednesday 21 January 2009 2:19:53 pm Greg Beaver wrote:
>> 2) adds new syntax to namespaces
>
> If I'm reading the RFC properly, it extends the existing syntax in a logical
> way without introducing any new reserved words. My only question then would
> be should we
There are already empty placeholders for this kind of informations in
the PHP documentation. These could be filled.
Sara's book is a good start, but it could be updated to wash out all
PHP4 stuff and put in new things developed since then.
Some more informations on memory management would be fine
On Thu, Jan 22, 2009 at 9:04 AM, Hannes Magnusson
wrote:
> On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
> wrote:
>> I think we really should encourage at least two active mentors for each
>> project this year. I think it helps both the students (always someone
>> to annoy) and the mentors (l
I think that's a great idea. The normal weekly/bi-weekly reports could
be CCed to internals@, with all discussion happening on gsoc@
- David
Am 22.01.2009 um 09:04 schrieb Hannes Magnusson:
On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
wrote:
I think we really should encourage at least
On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith
wrote:
> I think we really should encourage at least two active mentors for each
> project this year. I think it helps both the students (always someone
> to annoy) and the mentors (less stress and time out of their lives) and
> provides a safety n
30 matches
Mail list logo
