Am 25.10.2014 um 20:20 schrieb Stas Malyshev:
> somewhat relaxed rules there, but even then introducing new debugging
> protocol into PHP core seems to be something that warrants some
> notification.
That would have been my next question. I think it does not only
warrant notification but adheren
On 25/10/14 17:24, Levi Morrison wrote:
> The reason I bring this up in this discussion is that switching to
> something like Polymer is going to require a few changes on how we
> generate the HTML and CSS. The the best time to refactor code is when
> you are already changing it for something alrea
On 24/10/2014 12:54, Andrea Faulds wrote:
On 24 Oct 2014, at 10:29, Jordi Boggiano wrote:
Thanks for the work (again). It's an interesting small idea but I'd much prefer
revisiting the original getter/setter RFC [1] which had a majority but just
fell short of the 66% mark.
This RFC only im
On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins wrote:
> I'd like to everyone to stay grounded in reality and say that we have
> been checking code into php-src for months, very very few people have
> expressed an interest in what we were actually doing, you aren't one of
> them Stas.
As much as I
> Am 26.10.2014 um 12:58 schrieb Pierre Joye :
>
> On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins wrote:
>
>> I'd like to everyone to stay grounded in reality and say that we have
>> been checking code into php-src for months, very very few people have
>> expressed an interest in what we were actu
On Sat, 25 Oct 2014, Joe Watkins wrote:
> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
> > On Fri, 24 Oct 2014, Bob Weinand wrote:
> >
> > > Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
> > > Author:Bob Weinand Fri, 24 Oct 2014
> > > 19:29:50 +0200
> > > Parents:
> On 26 Oct 2014, at 15:09, Derick Rethans wrote:
>
> On Sat, 25 Oct 2014, Joe Watkins wrote:
>
>> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
>>
>> A few weeks ago, I was at a conference where you told a room filled
>> with hundreds of developers that phpdbg was no good, because
On Sat, 25 Oct 2014, Weinand Bob wrote:
> Just a minor question, Derick. If you care about phpdbg, why are you
> only dropping any comment about it by the time it got into php-src
> repo?
Yes, my mistake. I should have voted -1, but as I thought there was a
conflict of interest, I stayed silen
On Sat, 25 Oct 2014, Leigh wrote:
> On 25 October 2014 12:00, Weinand Bob wrote:
> > ...
>
> Thanks Bob.
>
> So my question is: Obviously the phpdbg requirements do not map to
> DBGp. However, can all of the requirements of DBGp be mapped to the
> phpdbg XML?
>
> Going forward does the XML p
On Sat, 25 Oct 2014, Stas Malyshev wrote:
> That said, we are where we are, and I think it would be great if this
> would somehow server as a starting point for developing a unified
> protocol for debugging PHP.
It already exists: DBGp. It's implemented by dozens of editors and
plugins.
cheer
On Sat, 25 Oct 2014, Joe Watkins wrote:
> We will notify internals of our intentions to make such changes in
> future, if we thought there was any chance of any feedback before today,
> we would already be doing so.
"We will notify internals". Really? Sadly, this phpdbg stuff is part of
internal
On Sun, 26 Oct 2014, Andrea Faulds wrote:
>
> > On 26 Oct 2014, at 15:09, Derick Rethans wrote:
> >
> > On Sat, 25 Oct 2014, Joe Watkins wrote:
> >
> >> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
> >>
> >> A few weeks ago, I was at a conference where you told a room filled
> >>
> Am 26.10.2014 um 16:17 schrieb Derick Rethans :
>
> On Sat, 25 Oct 2014, Weinand Bob wrote:
>
>> Just a minor question, Derick. If you care about phpdbg, why are you
>> only dropping any comment about it by the time it got into php-src
>> repo?
>
> Yes, my mistake. I should have voted -1, bu
> Am 26.10.2014 um 16:22 schrieb Derick Rethans :
>
> On Sat, 25 Oct 2014, Joe Watkins wrote:
>
>> We will notify internals of our intentions to make such changes in
>> future, if we thought there was any chance of any feedback before today,
>> we would already be doing so.
>
> "We will notify i
> Am 26.10.2014 um 16:26 schrieb Derick Rethans :
>
> On Sun, 26 Oct 2014, Andrea Faulds wrote:
>
>>
>>> On 26 Oct 2014, at 15:09, Derick Rethans wrote:
>>>
>>> On Sat, 25 Oct 2014, Joe Watkins wrote:
>>>
On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
A few weeks ago
> Am 26.10.2014 um 16:09 schrieb Derick Rethans :
>
> On Sat, 25 Oct 2014, Joe Watkins wrote:
>
>> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote:
>>> On Fri, 24 Oct 2014, Bob Weinand wrote:
>>>
Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7
Author:Bob Weinand
On 26/10/14 15:41, Bob Weinand wrote:
> Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
> They just initially requested it because they didn’t knew any better
> protocol. That’s all.
PHPStorm like PHP-FIG have their own agendas which do not play well with
other groups of d
> Am 26.10.2014 um 17:23 schrieb Lester Caine :
>
> On 26/10/14 15:41, Bob Weinand wrote:
>> Ask them at PhpStorm. They were pleased to not have to use DBGp for it.
>> They just initially requested it because they didn’t knew any better
>> protocol. That’s all.
>
> PHPStorm like PHP-FIG have the
> there's really nothing missing from PHP today to enable successful & easy
implementation of RESTful interfaces.
Zeev,
I could not create a REST interface that accepted "multipart form data" in
uploading a file and form data in one PUT request.
This is a valid part of a RESTful interface, yet PH
On 24/10/2014 00:36, Andrea Faulds wrote:
Good evening once again,
Here’s another RFC: https://wiki.php.net/rfc/readonly_properties
It proposes, with a working implementation, a modifier for properties that
makes them readable and writeable from different scopes.
Since I am a big proponent of
On 24.10.2014 20:54, Andrea Faulds wrote:
>> On 24 Oct 2014, at 19:52, Marc Bennewitz wrote:
>>> Floats are special, they are not expected to be precise. If we reject this,
>>> then perhaps we should also reject 0.1, because it can’t be precisely
>>> represented by a float?
>> It's a difference
On 12.10.2014 12:10, Nikita Popov wrote:
> On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll wrote:
>
>> Hey,
>>
>>
>>
>> I just stumbled over a method call of a non-static method with self and
>> was asking myself again, why does PHP support
>> this behaviour. An example to outline what I am writi
> The only way to do this in PHP now is write a userland function that parses
> multipart form data, which is non-trivial.
In addition to PECL HTTP, you might try PECL Mailparse, which is also
going to be better-tested than anything written in userland.
I sympathize with your overall point: even
Hi!
> The only way to do this in PHP now is write a userland function that parses
> multipart form data, which is non-trivial. I had written one, but would
It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
Hi!
On Sun, Oct 26, 2014 at 10:21 PM, Stas Malyshev
wrote:
> Hi!
>
> > The only way to do this in PHP now is write a userland function that
> parses
> > multipart form data, which is non-trivial. I had written one, but would
>
> It is true that PUT data need to be parsed, however it is not true
> On Oct 26, 2014, at 4:21 PM, Stas Malyshev wrote:
>
> Hi!
>
>> The only way to do this in PHP now is write a userland function that parses
>> multipart form data, which is non-trivial. I had written one, but would
>
> It is true that PUT data need to be parsed, however it is not true you
> h
2014-10-26 23:24 GMT+02:00 Florian Margaine :
> I think Rasmus made it clear what the original naming meant: it were form
> methods, not related at all to HTTP methods.
Yes, this would be logical to have access to the input data, as single
interface, do not make exceptions for POST, input data sen
Hi!
I would like to present to your attention an RFC about using object as keys:
https://wiki.php.net/rfc/objkey
It was discussed in the past on the list:
http://marc.info/?t=14114596961&r=1&w=2
and I think it makes sense to propose a formal RFC for it. Both the text
and the code in the patc
> On Oct 26, 2014, at 5:00 PM, Park Framework wrote:
>
> 2014-10-26 23:24 GMT+02:00 Florian Margaine :
>> I think Rasmus made it clear what the original naming meant: it were form
>> methods, not related at all to HTTP methods.
>
> Yes, this would be logical to have access to the input data, as
> On Oct 26, 2014, at 8:37 PM, Stas Malyshev wrote:
>
> Hi!
>
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
>
Hi Stas!
I’m trying to wrap my head around a real-world use-case with this. We have
spl_object_hash, which eff
Hi!
> I’m trying to wrap my head around a real-world use-case with this.
> We have spl_object_hash, which effectively provides a unique hash for
This hash has nothing to do with object's contents. But imagine number
GMP("42") and imagine you actually want two GMP objects expressing "42"
actually
> On Oct 26, 2014, at 9:43 PM, Stas Malyshev wrote:
>
> Hi!
>
>> I’m trying to wrap my head around a real-world use-case with this.
>> We have spl_object_hash, which effectively provides a unique hash for
>
> This hash has nothing to do with object's contents. But imagine number
> GMP("42") an
> pecl/http is available
To a degree, but no binaries for Windows == not a universal
prescription. Mailparse by contrast does have a shipping DLL.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Oct 26, 2014, at 10:38 PM, Sanford Whiteman wrote:
>
>> pecl/http is available
>
> To a degree, but no binaries for Windows == not a universal
> prescription. Mailparse by contrast does have a shipping DLL.
I’m confused. pecl/http does have Windows binaries:
http://windows.php.net/downlo
You're right. Guess the build system didn't update
http://pecl.php.net/package/pecl_http with the DLL link as for other
exts.
-- S,
On Mon, Oct 27, 2014 at 12:31 AM, Will Fitch wrote:
>
> On Oct 26, 2014, at 10:38 PM, Sanford Whiteman
> wrote:
>
> pecl/http is available
>
>
> To a degree, but
> PUT, DELETE, must be available in a single global variable, the
> variable name is not important
> file_get_contents(‘php://input') - uncomfortably
If the quibble were with file_get_contents(‘php://input') that's not
sufficiently uncomfortable to warrant a new superglobal. I assume you
mean pars
On Sun, 2014-10-26 at 18:37 -0700, Stas Malyshev wrote:
> Hi!
>
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
>
> It was discussed in the past on the list:
> http://marc.info/?t=14114596961&r=1&w=2
> and I think it makes se
Hi!
> It seems __toScalar might be a good name, this is what the method
> actually does, the engine then coerces to a type suitable for use as a
> key, but you can return a double. It might be more forward thinking
> therefore to use the name __toScalar, while today we'd only be using
> it for thi
> On Oct 27, 2014, at 1:36 AM, Stas Malyshev wrote:
>
> Hi!
>
>> It seems __toScalar might be a good name, this is what the method
>> actually does, the engine then coerces to a type suitable for use as a
>> key, but you can return a double. It might be more forward thinking
>> therefore to use
Am 27.10.2014 02:37 schrieb "Stas Malyshev" :
>
> I would like to present to your attention an RFC about using object as
keys:
>
>https://wiki.php.net/rfc/objkey
I don't like this, mainly because it blocks a future direct use and storage
of objects as keys in an array, i.e. what SplObjectStorage d
40 matches
Mail list logo
