On 03.09.2012, at 09:37, Jannik Zschiesche wrote:
> The main problem arises from the ambiguity for $array[-1] for arrays.
> But this is easily solvable: just introduce a slice operator.
>
> $array[:-1] and the ambiguity is gone.
That would return an array containing the last item as the sole me
On 03.09.2012, at 01:11, sle...@pipeline.com wrote:
>> I see how this may work for strings and simple vectors, but what about this:
>>
>> $a = array(-1 => "foo", -2 => "bar"); echo $a[-1];
>>
>> It should keep returning "foo", right? So then the question is - what
>> $array[-1] actually means?
On 25.08.2012, at 11:15, Lester Caine wrote:
> Many of my 'problems' with all of the 'progress' being made with PHP are
> caused because I'm using a core framework who's origins go back to PHP4 days.
I'm sorry, but what is the point of this email? This is a mailing list, not a
group therapy se
So the consensus so far is to drop notices from ob_clean(), ob_end_clean() and
ob_get_clean()? What about ob_flush() or others?
David
On 18.11.2011, at 14:08, Ilia Alshanetsky wrote:
> I agree with Stas' point there is really no need to force people do
> the while (ob_get_level()) ob_end_cle
On 17.11.2011, at 21:46, Matthew Weier O'Phinney wrote:
> * ob_get_clean() now raises a notice if no buffer to delete
> Prior to 5.4.0RC1, if there were no buffers left to delete,
> ob_get_clean() was silent. It now raises a notice -- which, when
> using PHPUnit, means an error is now raised
Had a few other tests failing, updated those accordingly and attached a newer
version.
David
On 12.11.2011, at 12:06, David Zülke wrote:
> I looked through the mailing list archives, and in several threads the
> consensus seemed to be that the setters should throw a warning, b
I looked through the mailing list archives, and in several threads the
consensus seemed to be that the setters should throw a warning, but the getters
should not...
> localhost:test dzuelke$ ~/Code/oss/php/php-5.4.0RC1/sapi/cli/php -v
> PHP 5.4.0RC1 (cli) (built: Nov 11 2011 19:53:40)
> Copyrig
FYI: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
This could impact PHP as well since it bundles the database.
David
P.S. I hope Google/IBM/Oracle/whoever just buys those guys and then fires
everyone.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
On 01.07.2011, at 01:29, Stas Malyshev wrote:
> Hi!
>
> On 6/30/11 2:34 PM, Michael Maclean wrote:
>> The same data also ends up in the bizarre $http_response_headers var
>> that gets spontaneously created in local scope - I've wondered about how
>> good that is to do.
>
> This thing is indeed b
On 28.06.2011, at 23:17, Pierre Joye wrote:
> A significant change is that now bugs.php.net is only available via
> https://bugs.php.net.
May I suggest that the interface doesn't redirect to https:// by default?
http:// plays much nicer with proxies, and browsers cache resources to disk,
which
On 29.06.2011, at 01:19, Johannes Schlüter wrote:
> On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote:
>> - Colours messages according to their response code (success=green,
>> client error=yellow, server error=red)
>
> I would prefer if this would be an ini option (if (cli_web_server.color
> &&
On 29.06.2011, at 23:05, Martin Scotta wrote:
> are you kidding, right?
>
> $class = 'stdClass';
> $instance = new $class;
> var_dump( $instance instanceof $class );
That still only works on instances. Not on class names. Which this dicussion is
about.
David
smime.p7s
Description: S/MIME c
On 29.06.2011, at 22:20, Paul Dragoonis wrote:
> On Wed, Jun 29, 2011 at 8:49 PM, Ralph Schindler wrote:
>> Correct.
>>
>> I was hasty in that example, the first was copied & tested (and is reflected
>> in the test, as is that variation of what I wrote up.)
>>
>> Either way, test and patch work
On 29.06.2011, at 21:39, Ralph Schindler wrote:
> interface A {}
> class B implements A {}
> class C extends B {}
> var_dump(is_subclass_of('B', 'A')); // true
Typo there; that should be 'C', not 'B'.
David
smime.p7s
Description: S/MIME cryptographic signature
On 28.06.2011, at 14:26, Johannes Schlüter wrote:
> On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote:
>
>> On 27.06.2011, at 01:55, Stas Malyshev wrote:
>>
>>> However, it still has a chance somebody's data won't work after the
>>> update if
On 27.06.2011, at 01:55, Stas Malyshev wrote:
> However, it still has a chance somebody's data won't work after the update if
> he had 8-bit data hashed with old crypt(). He would need either to re-hash or
> to change prefix from $2a to $2x.
IMO that's a fair trade-off; people could even implem
He means
function foo(callback derp = array('MyClass', 'ohai')) { ... }
David
On 08.06.2011, at 15:31, Anthony Ferrara wrote:
>> No default values, other then NULL allowed.
>> Otherwise we would need to support array("classname", "methodname")
>> too, and then people would want default array v
On 08.06.2011, at 00:38, dukeofgaming wrote:
> On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney <
> weierophin...@php.net> wrote:
>
>> On 2011-06-07, dukeofgaming wrote:
>>
>>> +1 for "callable", it is really more consistent.
>>
>> I was actually agreeing With David and Stas that "callb
On 07.06.2011, at 22:31, Stas Malyshev wrote:
> Hi!
>
>> callback is callable, the opposite could not be true.
>> a string --or a closure-- is callable, but the string is not a callback
>
> According to our docs, which were out there for years, it is. One of the main
> and widespread complaints
On 07.06.2011, at 21:12, Stas Malyshev wrote:
> Hi!
>
>> https://wiki.php.net/rfc/callable
>
> Note also that this pseudo-type is called "callback" in all of our
> documentation, which means we have now documentation that says:
>
> bool array_walk ( array &$array , callback $funcname [, mixed
On 07.06.2011, at 12:09, Jordi Boggiano wrote:
> On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev wrote:
>> Sure. How about reducing boilterplate code like this:
>>
>> if(is_readable($foo)) {
>> $var = file_get_contents($foo);
>> } else {
>> throw InvalidArgumentException();
>> }
>>
>> Why won'
my calculations are correct then a zval should be approx 216 bytes
> (excluding string contents):
>
>((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B
>
> Mike
>
> On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote:
>> memory_get_peak_usage() is the maximum
ut the meaning of memory_get_peak_usage incorrect?
>
> Mike
>
> On Tue, 2011-06-07 at 16:28 +0200, David Zülke wrote:
>> Please test the exact thing I suggested :)
>>
>> var_dump(memory_get_usage());
>> token_get_all(file_get_contents());
>> gc_collect_c
One thing to keep in mind of course is that each zval incurs an overhead. $x =
1; requires 144 bytes of memory in total IIRC.
David
On 04.06.2011, at 23:38, Mike van Riel wrote:
> Dear Internals,
>
> During development of DocBlox I encountered a (for me) unusual situation
> with regards to me
7;'));
var_dump(memory_get_usage());
And then, a comparison to this would be useful:
var_dump(memory_get_usage());
token_get_all(file_get_contents(''));
gc_collect_cycles();
var_dump(memory_get_usage());
David
On 07.06.2011, at 16:34, Ferenc Kovacs wrote:
> On Tue, Jun 7, 2011
sistance thus far.
>
> Mike
>
> On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote:
>> Seems like leak.
>>
>> Try disabling ZendMM to see if something noticeable happens (memory
>> peak should be lower).
>> USE_ZEND_ALLOC=0
>>
>> Cheers,
On 06.06.2011, at 20:03, John Crenshaw wrote:
> The desire is to be able to copy/paste things back and forth and make it work
> with only minor tweaks.
That sounds like a problem an IDE should solve, and not the language itself.
And again... there are potential encoding problems, plus single ve
<3
David
On 05.06.2011, at 17:52, Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009 which
> points to an interesting feature that I think makes sense for us, since we
> are now working with $f() using objects and strings, and the array('class'
On 04.06.2011, at 02:43, John Crenshaw wrote:
> This is a moot point. You wouldn't send that to json_decode. You would send
> it to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong
> in the first place, because json_decode requires a string, not an object.
Just to quickly
Smells like a memory leak if gc_collect_cycles() doesn't fix it.
David
On 05.06.2011, at 00:01, Mike van Riel wrote:
> Hey David,
>
> That gives me the following output:
>
>int(640720)
>int(244001144)
>
> Mike
>
> On Sat, 2011-06-04 at 23:51 +02
What does
var_dump(memory_get_peak_usage());
token_get_all(file_get_contents(''));
var_dump(memory_get_peak_usage());
get you?
David
On 04.06.2011, at 23:38, Mike van Riel wrote:
> Dear Internals,
>
> During development of DocBlox I encountered a (for me) unusual situation
> with regards to
I think for consistency's sake it should be a notice as the same is already
done in _convert_to_string(). In fact, couldn't zend_make_printable_zval() use
_convert_to_string()?
- David
On 03.06.2011, at 09:57, Derick Rethans wrote:
> On Thu, 2 Jun 2011, Ilia Alshanetsky wrote:
>
>> I like th
To clarify: I don't understand what the advantage would be, either. It seems
that those demanding it somehow confuse or blur the lines between the
declaration of data in the language and its representation in a serialization
format. A few people in the thread demanded that it be a syntax that co
end that to json_decode. You would send
> it to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong
> in the first place, because json_decode requires a string, not an object.
>
> John Crenshaw
> Priacta, Inc.
>
> -Original Message-
>
On 03.06.2011, at 22:38, Matt Pelmear wrote:
> Hello,
>
> I discovered today that the DOMNode::getAttribute() function (which is
> undocumented on the php site)
It's DOMElement::getAttribute()...
> returns an empty string if the requested
> attribute doesn't exist in the node.
Yes, but that's
This representation can be encoded in any
> ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
> directly in a Latin-1 encoded script is just fine.
>
> -Andrei
>
> On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
> wrote:
>> No we can't; I alread
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That is
not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: "ä", bar: "\u0123"}
Should that then give m
id UTF-8 sequence, or with latin1 character
soup.
David
>
> - M.
>
> --
> Marcel Esser
>
> Vice President of Engineering, CROSCON
> +1 (202) 470-6090
> marcel.es...@croscon.com
>
> Before printing this e-mail, please consider the rainforest.
>
>
>
Just because the MongoDB developers were stupid enough to build a query
language on top of JSON does not mean that JSON or JavaScript object literals
need to be supported in PHP. And it wouldn't be possible anyway since JSON
allows Unicode escape sequences, and PHP cannot even represent those as
On 30.04.2011, at 22:05, Ben Schmidt wrote:
> This adds a certain ambiguity to document creation if it is used, but it
> does add functionality not currently there. I guess it's only worth
> doing if there are specs out there in the wild that (wrongly IMHO)
> require "unqualified" names in XMLName
On 29.04.2011, at 09:44, Tom Samplonius wrote:
>
>> While I think this would make SimpleXML more stupid, not less, as it
>> seems
>> braindead to me to allow users to create documents ambiguously and/or
>> which
>> essentially violate the XML namespace spec, I think the way to do
>
> Allowing c
That patch is not a good idea.
Assume you have this situation:
Adding a child "baz" to bar and have it default to no namespace prefix would
result in this:
Now would be in the namespace "urn:lol".
Keep in mind that xmlns="" is, as per the XML spec, a perfectly valid way to
ResourceBundle::__construct() uses ures_open(), which performs validity checks
on the given locale identifier. That's reasonable, as the fallback
functionality only works with proper locale IDs (example: you pass "de_DE", but
no such bundle exist, it will then use the bundle "de" if that exists)
On 25.08.2010, at 15:51, Tyler Lawson wrote:
> Sebastian Bergmann wrote:
>
>> So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
>> options to PHP that offer choices to developers. If they do not use
>> them ... what can we do?
>>
>
> As a regular user of PHP, I like the id
On 17.08.2010, at 10:46, Ferenc Kovacs wrote:
> Tue, Aug 17, 2010 at 10:04 AM, Richard Quadling wrote:
>
>> On 17 August 2010 08:39, Jingcheng Zhang wrote:
>>> Hello internals,
>>>
>>> I wonder whether it is possible to implement "static initialization
>> block"
>>> feature in PHP, for example:
http://thread.gmane.org/gmane.comp.php.devel/60563 and
http://thread.gmane.org/gmane.comp.php.devel/57369 ;)
On 12.05.2010, at 22:23, Mathias Grimm wrote:
> What is the correct todo list ?
> I want to help us but a need to see the todo list to select my work!
>
> Any sugestion to start?
>
> -
On 25.03.2010, at 22:05, Michael Maclean wrote:
Currently, DateTime objects aren't properly mapped to and from
xsd:datetime objects when sending them via ext/soap. David Zülke
wrote a patch to fix this, and filed it under bug 44383, and mailed
the list with it - http://article.gman
It's already on the list for PHP6:
http://wiki.php.net/summits/pdmnotesmay09 (see Day 2, PHP 6, #13).
No need to discuss this further, I think. You might also want to have
that bug closed, it's redundant.
- David
On 07.11.2009, at 12:42, melfar wrote:
Hello!
I have filed a bug (suggest
On 05.10.2009, at 18:11, Israel Ekpo wrote:
This was actually not a bug with the PHP code.
The error was in the instance XML document.
I just closed the bug.
That should probably be closed as "bogus", not "closed".
- David
smime.p7s
Description: S/MIME cryptographic signature
On 28.07.2009, at 19:14, Jani Taskinen wrote:
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to c
On 28.07.2009, at 19:14, Jani Taskinen wrote:
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to c
On 28.07.2009, at 19:14, Jani Taskinen wrote:
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to c
On 28.07.2009, at 19:14, Jani Taskinen wrote:
Dmitry Stogov wrote:
David Zülke wrote:
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to c
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
I finally got around to writing a test case and opening a ticket
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
Issue: http://bugs.php.net/49144
.phpt: http://pastie.org/569897
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
Issue: http://bugs.php.net/49144
.phpt: http://pastie.org/569897
On 28.07.2009, at 13:32, Dmitry Stogov wrote:
Hi David,
I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least
into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.
The only thing I didn't understood - w
*bump*
Dmitry, did you have a chance to review this patch yet?
- David
On 22.06.2009, at 15:21, David Zülke wrote:
Hi folks,
attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as
requested in http
On 24.07.2009, at 12:45, Davide Romanini wrote:
David Zülke ha scritto:
Can do, but I wanted to figure out a way to create a reproduce case
first (I already have an idea).
- David
On 24.07.2009, at 12:20, Dmitry Stogov wrote:
Hi David,
Please report a bug on bugs.php.net (assign it to
Can do, but I wanted to figure out a way to create a reproduce case
first (I already have an idea).
- David
On 24.07.2009, at 12:20, Dmitry Stogov wrote:
Hi David,
Please report a bug on bugs.php.net (assign it to dmitry).
I'll look into it later.
Thanks. Dmitry.
David Zülke
This sounds like a serious issue, but I'm not sure if it's in libxml
or in ext/soap. Will have a look later; but maybe Dmitry or someone
else knows off the top of their heads?
- David
Begin forwarded message:
From: Davide Romanini
Date: 30. Juni 2009 11:49:30 MESZ
To: s...@lists.php.net
On 20.07.2009, at 12:42, Jani Taskinen wrote:
On 07/15/2009 08:49 PM, David Zülke wrote:
Hi there,
attached are patches for http://bugs.php.net/48929.
Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff
for
testing the stream wrapper is genius.
Ehem..was this ever
Hi there,
attached are patches for http://bugs.php.net/48929.
Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff for
testing the stream wrapper is genius.
- David
Index: ext/standard/tests/http/bug48929.phpt
===
On 10.07.2009, at 17:00, Hannes Magnusson wrote:
On Fri, Jul 10, 2009 at 16:58, Uwe Schindler wrote:
As far as I know, SOAP does not use the HTTP wrappers directly, it
uses only
sockets/ssl for communication (so the context applies only to the
lower
level SSL socket). So CURL is not used, be
On 07.07.2009, at 16:18, Brian A. Seklecki wrote:
On Tue, 2009-07-07 at 15:42 +0200, endrazine wrote:
It is lacking any type of authentication of the payment gateway,
which
is not acceptable.
I agree+++.
The problem is that PHP SOAP uses an internal "streams" library
instead
of libcur
On 04.07.2009, at 14:27, Derick Rethans wrote:
So I would propose to:
1. have ilia's strict typing patch (minus scalar and numeric)
2. have a patch that also adds for casting type hints from your RFC.
Those could (and should) be considered as *two* new features.
As for syntax, I believe the
Hi folks,
attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as requested
in http://bugs.php.net/44383
Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime,
but not for other types defined in W3C X
Patch updated to reflect the change. It's against 5.3 btw. Now who
will commit it so it makes it into the next RC? :)
- David
On 15.06.2009, at 15:47, David Zülke wrote:
On 15.06.2009, at 15:40, Matt Wilmas wrote:
Hi David,
Hey Matt,
- Original Message -
From: "D
On 15.06.2009, at 15:40, Matt Wilmas wrote:
Hi David,
Hey Matt,
- Original Message -
From: "David Zülke"
Sent: Monday, June 15, 2009
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering
why zend_hash_update doesn't automatically convert
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering why
zend_hash_update doesn't automatically convert numeric strings to
integers.
Doing $foo = array('1' => 'bar'); actually results in an integer key
with value 1, not in a string. The problem in the bug above was
As Jani put it:
PLEASE, let the dead horse be!
- David
On 14.04.2009, at 17:11, Arvids Godjuks wrote:
Hello everyone.
I've been writing for some time now at
the
last project and it really sucks. I understand reason on depricating
short_open_tag and I agree. But I have a proposal witch
On 17.02.2009, at 08:02, Eric Stewart wrote:
10. The production value of error_reporting has been changed to
E_ALL |
~E_DEPRECATED.
I guess you mean E_ALL & ~E_DEPRECATED
smime.p7s
Description: S/MIME cryptographic signature
Am 10.02.2009 um 03:27 schrieb Eric Stewart:
A new RFC for PHP's proposed INI files have been added to the wiki.
Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis
For -development, display_errors should *definitely* be on, and
error_reporting should be E_ALL | E_STRICT.
On 05.02.2009, at 17:32, Johannes Schlüter wrote:
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it
right:
The type hint
Am 04.02.2009 um 15:16 schrieb Sebastian Bergmann:
Rob Richards wrote:
The addition in 5.2.6 was a BC break and is fixed in 5.2.9
Removing the type-hint is only a short-term fix, IMHO. A better
solution
would be to introduce a marker interface that is implemented by the
respective classes
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocument type hints there
Am 28.01.2009 um 18:41 schrieb Scott MacVicar:
Nathanael D. Noblet wrote:
Peter Walther wrote:
it's only a bug if you always expect optional NULL parameters to be
ignored.
Well that's the question I'm asking. I assumed optional parameters
passed null should be ignored. If this isn't the beha
Am 25.01.2009 um 14:29 schrieb Lukas Kahwe Smith:
On 24.01.2009, at 17:40, Ilia Alshanetsky wrote:
I think our bug current tracker is pretty good and most importantly
makes it easy to report and update bugs which is conducive to more
issues being reported. Often extra features of bug track
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
Am 20.01.2009 um 18:41 schrieb Christian Seiler:
Hi,
maybe an IRC meeting is the easiest way to come to an agreement. How
about tomorrow evening 21:00 CEST in #php.closures on freenode?
Just for clarification: I assume you mean Wednesday, January 21st,
19:00
UTC (CEST == UTC+2) and thus 2
Am 13.01.2009 um 22:58 schrieb Marcus Boerger:
5) A closure assigned to a property can be called directly rather
than just by a temporary variable:
$obj->property = function() {}
$obj->property(); // valid call
This will get us into trouble IMHO, as it would not behave too well
with
__get
Am 13.01.2009 um 11:09 schrieb Alexey Zakhlestin:
On Tue, Jan 13, 2009 at 12:32 PM, troels knak-nielsen
wrote:
In a recent mail, some kind of issue regarding queryparams was
mentioned (Possibly related to namespaces). Could anybody explain
what
the issue is, or point to where it's discussed
Am 06.01.2009 um 16:52 schrieb Lukas Kahwe Smith:
On 16.12.2006, at 19:50, Hannes Magnusson wrote:
On 12/16/06, Derick Rethans wrote:
On Fri, 15 Dec 2006, Andi Gutmans wrote:
> Time to turn it off in php.ini-dist in addition to php.ini-
recommended?
I would instead change them to php.in
On 03.01.2009, at 15:47, Marcus Boerger wrote:
However if that is the intention, then something we might want to look
into in order to make it easier for those people is to fix something
that propbably looks wrong to them. That is binding a closure to a
property outside of the scope of the objec
Marcus,
thanks!
Why is it
Test::{closure}()
{closure}()
and not
Test::{closure}()
Test::{closure}()
in that test, though? Is it because func1() "was there" from the
Engine's POV after the ctor was called? AFAICT, that's the only
difference between the two.
Cheers,
- David
On 01.01.20
Hi folks,
first of all, thank you Marcus for implementing this. Very cool.
As for the __get()/__getClosure() stuff, I don't think it's necessary
or even an issue. One can never simply do $this-
>getOverloadPropertyWithInvoke() anyway, because if the prop is not
there, a fatal error would be
On 25.12.2008, at 06:11, Lars Strojny wrote:
Hi David,
Am Dienstag, den 23.12.2008, 17:02 +0100 schrieb David Zülke:
[...]
This gives a fatal "Call to undefined method DateTime::getAtom()"
$d = new DateTime();
$d->getAtom = Curry::create(array($d, 'format'), DATE_AT
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$t
Am 03.11.2008 um 16:41 schrieb Marcus Boerger:
2) Ther are iterator_apply()
owww that sounds like it really needs docs :>
smime.p7s
Description: S/MIME cryptographic signature
Am 15.10.2008 um 09:04 schrieb Derick Rethans:
As we're getting really close to 5.3, I would suggest to remove
namespaces from this release as we're simply not done with even
agreeing
on how things should work. PHP 5.3 has many other cool things, and
leaving namespaces for PHP 6 means we're a
On 14.10.2008, at 21:20, Lukas Kahwe Smith wrote:
On 14.10.2008, at 21:01, Steph Fox wrote:
We are in alpha indeed, and still looking at proposals, and still
without consensus. The last thing I'd want is to see namespace
support pushed under the carpet, but I'd rather see it at this
stage
I recommend you and your fellow programmers read the discussion again.
It's nost just about syntax.
On 14.10.2008, at 21:53, Arvids Godjuks wrote:
People, why you just don't change the namespace separator to something
except :: and sole all the problems one and for all? God damn,
use :> i
Am 14.10.2008 um 14:10 schrieb Steph Fox:
> On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote:
>
> 1) rip them out
>
> I'm +1 on this. We simply don't have consensus, and I don't see
anyway > we
> can have consensus by the time 5.3 has to be frozen. Once
namespaces > are in,
> we're gonna h
Am 14.10.2008 um 14:39 schrieb Steph Fox:
Many people have starting working on top level application using
namespaces, so there will a very bad buzz over the php community if
namespaces are ripped out...
People working with a development branch take their own chances. We
keep BC for released
just curious, why is ext/soap internally duplicating this http stuff
instead of using the http stream stuff directly? or did I
misunderstand something?
Am 29.09.2008 um 10:11 schrieb Dmitry Stogov:
Hi Brian,
I think you patch does the things you like properly, but why do we
need
such
Totally hating to bring this up again (and hijacking this thread), but
can we please enable ext/xsl by default in 5.3? :>
- David
Am 29.09.2008 um 13:24 schrieb Marcus Boerger:
Hello Jani,
we're in alpha and fix all of those issues.
in contrast to 99.9% of our users it is very easy for
+1, or: "Do, or do not. There is no 'try.'"
- David
On 28.09.2008, at 16:29, Steph Fox wrote:
Hi Greg,
The patch I posted here:
http://pear.php.net/~greg/ns.element.patch.txt
does exactly what you are talking about. For some reason, some
people
find this too difficult to digest. I've
Am 18.09.2008 um 21:02 schrieb Michael Wallner:
In case the original with patches attached doesn't get through:
http://dev.iworks.at/PATCHES/php53-backport_output.txt
http://dev.iworks.at/PATCHES/pecl-backport_output.txt
Isn't there a typo in colorer.cpp:
+php_outout_get_contents(ret
Am 22.09.2008 um 21:45 schrieb Stanislav Malyshev:
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about what we'd like to do with namespaces, and we arrived at the
following conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax
On 17.09.2008, at 22:24, Richard Quadling wrote:
Hi.
Where can I find out how a PHP array gets converted to an XML
document for
transmission using SOAP using a WDSL file?
Ideally I would like to see some sort of trace of the conversion
process.
I'm helping someone else. They seem to be d
1 - 100 of 261 matches
Mail list logo
