Re: [PHP-DEV] Currently supported versions of PHP
On 10/28/2014 03:35 AM, Trevor Suarez wrote: Great job on this Adam. You whipped this up pretty quickly and it looks good! I second that emotion: great work, Adam! Thank you for your work! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 27/10/2014 20:27, Andrea Faulds wrote:
Tentative syntax. But this way, the visibility stays on the left. I think
that’s good for readability. If you omit the second specifier, then the first
one applies to getting and setting, as now. If you include it, the first one
applies to getting, the second one to setting.
It’d also be compatible with properties, too:
public/private $foobar {
get { return $this-bar * $this-foo; }
set($value) { $this-bar = $value / $this-foo; }
}
It doesn’t prevent truly read-only properties, either:
public $foobar {
get { return $this-bar * $this-foo; }
}
Does this sound like a good idea? A similar idea came up in the discussions 8
years ago on readonly.
I like it, except for the fact that if you add a custom getter to a
property suddenly it becomes readonly unless you remember to add ; set
to the end of the block, right?
How about this instead for readonly:
public $foobar {
get { return $this-bar * $this-foo; }; readonly
}
And if the flag isn't there, set is implicitly present.
That'd mean you also can keep public readonly $foobar; as a shorthand
for readonly properties without custom getter.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On Tue, Oct 28, 2014 at 2:17 PM, Jordi Boggiano j.boggi...@seld.be wrote:
On 27/10/2014 20:27, Andrea Faulds wrote:
Tentative syntax. But this way, the visibility stays on the left. I think
that’s good for readability. If you omit the second specifier, then the
first one applies to getting and setting, as now. If you include it, the
first one applies to getting, the second one to setting.
It’d also be compatible with properties, too:
public/private $foobar {
get { return $this-bar * $this-foo; }
set($value) { $this-bar = $value / $this-foo; }
}
It doesn’t prevent truly read-only properties, either:
public $foobar {
get { return $this-bar * $this-foo; }
}
Does this sound like a good idea? A similar idea came up in the
discussions 8 years ago on readonly.
I like it, except for the fact that if you add a custom getter to a property
suddenly it becomes readonly unless you remember to add ; set to the end
of the block, right?
How about this instead for readonly:
public $foobar {
get { return $this-bar * $this-foo; }; readonly
}
And if the flag isn't there, set is implicitly present.
That'd mean you also can keep public readonly $foobar; as a shorthand for
readonly properties without custom getter.
I like this idea.
Also confirmed what I was trying to say: While we can have many RFCs
covering the properties properties and behavior, having one covering
the needs in one go will allow us to be more consistent and developer
friendly.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 27 October 2014 20:27, Andrea Faulds a...@ajf.me wrote:
On 26 Oct 2014, at 19:16, Rowan Collins rowan.coll...@gmail.com wrote:
I just had a thought on both the naming and future-proofing concerns of
this proposal: what about pre-emptively reserving the skeleton of the
syntax needed for accessors, without actually implementing them?
I’ve been thinking about this. While `public readonly $foo;` does work, it
is confusing (only readonly to public) and limiting (no public/private
option). Plus, while it could work with getters/setters, it’s hardly ideal.
On the other hand, while having C#-style syntax here gives us a full
feature set, I don’t like that it inverts the order of a declaration. To
show you what I mean, here’s a normal property:
public $foobar;
Now, here’s a property with C#-style syntax:
var $foobar { public get; private set; };
See how the `public` moved to the right? I don’t like that, I want to
avoid that if possible. I’m all for C#-style syntax with the get and set,
but I don’t like that it moves the visibility specifier.
Similarly, I don’t like this either:
public $foobar { get; private set; }
Now the visibility is on both sides! Yuck. That’s the worst of both worlds.
What I’d like is probably something like this:
public/private $foobar;
Tentative syntax. But this way, the visibility stays on the left. I think
that’s good for readability. If you omit the second specifier, then the
first one applies to getting and setting, as now. If you include it, the
first one applies to getting, the second one to setting.
It’d also be compatible with properties, too:
public/private $foobar {
get { return $this-bar * $this-foo; }
set($value) { $this-bar = $value / $this-foo; }
}
Sorry, but I don't like this. This means that the visibility modifier is no
longer next to the thing that it applies to, IMO this is actually harmful
to the readability because the order in which the accessors were defined
then becomes significant so you have to either look at the ordering or have
the parser enforce a particular order, plus public/private looks
syntactically weird.
I would suggest something like this:
public $foobar {
get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}
...where only a single visibility modifier is permitted on the left, and
this is treated as the *default* visibility for the accessors, which are
free to declare another visibility if they want - so the following would be
equivalent:
public $foobar {
public get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}
Another bonus here is that the var keyword can still be permitted on the
left for those who prefer the C# syntax, as a synonym of public (i.e. the
current behaviour of var).
It doesn’t prevent truly read-only properties, either:
public $foobar {
get { return $this-bar * $this-foo; }
}
Does this sound like a good idea? A similar idea came up in the
discussions 8 years ago on readonly.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
On Mon, Oct 27, 2014 at 7:11 PM, Stas Malyshev smalys...@gmail.com wrote: Hi! As others noted, it also prevents a full-fledged objects-as-key implementation in the future. You do realize to have such implementation we'd need to rewrite our hash layer completely and also introduce the concept of immutable object, otherwise changing the object would make the hash completely broken? Which means it would probably never happen unless PHP engine is radically rewritten. You argue two things here: 1) it would need a big rewrite of the hash api, so it's unlikely to ever happen It would work almost exactly like string keys, except the hash would be computed in userland. As such I don't think it is fair to say it would require a complete rewrite. Non-trivial changes? Sure. But even if it did require a complete rewrite (and I have no strong evidence that it wouldn't), recent history has shown that much bigger rewrites are definitely possible and have happened (e.g. interned strings, ast, uniform syntax, ...). 2) Hash needs to be stable, so we need the concept of immutable objects Having non-stable hashes is always an issue, and these requirements would have to be made clear in the documentation. Your implementation suffers from the same usability problems if the hash is not stable (However it is true that it offers a simpler way to recover). So I don't think we would need to introduce the concept of immutable objects, or at least not more than we would with your implementation. In the end it causes issues and brings very little compared to an explicit call to convert an object to a key. Same as __toString obviously is useless as you could just call a method explicitly. Let me rephrase: The small expressivity gain of omitting a call comes at a quite high (IMO) cost in your implementation. I believe it is not worth it. Comparing only one side of this equation with another feature makes no sense. Best, -- Etienne Kneuss
Re: [PHP-DEV] [RFC] Serialize filtering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 27/10/2014 09:03, Stas Malyshev a écrit : Hi! I'd like to have a vote on unserialize() improvement proposal outlined here: https://wiki.php.net/rfc/secure_unserialize soon-ish, but since discussion on it has been more than a year ago I'd like to give it some prior notice and some time to re-consider. I still think it is a good improvement, not fixing all problems but allowing to fix some at reasonable cost. I've added some outline of arguments discussed before, but still open for comments. The patch is probably outdated but I'll fix it if it's accepted, if not I don't want to spend time on it. I'd like to have a vote sometime next week, but if there's more discussion it can be postponed. +1 as this seems to have a real benefit for security (implementation detail such as function or option name are... detail) Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRPmL8ACgkQYUppBSnxahhLrQCePtlnYkVuhSNFPF+pvjZ+DNZX GaoAoLXKHYtbblmT9G0Y/jPRDgUtgABT =mE9N -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: 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 developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. step back a bit here, stay professional, there is no need for passive aggressiveness. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Xdebug is *not* a php.net project, and Derick hash always managed to keep this line clear to everybody (since 10 years now). Derick has never asked to merge Xdebug to core, because (please confirm) probably he wants to keep the lead on the project, and make it evolve like *he, as author and maintainer* wants to. This is something that can not happen to a PHP-project code. phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to adhere the rules, you can keep your ideas yours, in a separate repo, like Derick does for Xdebug. People must understand that as soon as the code is part of the PHP project, it is owned by the PHP project, and not a single/duo person anymore. Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On Sun, Oct 12, 2014 at 12:10 PM, Nikita Popov nikita@gmail.com wrote:
On Sun, Oct 12, 2014 at 10:37 AM, Robert Stoll p...@tutteli.ch 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 writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed to call non-static methods with self or
static. Sure, it is just a small detail but for
someone who starts learning PHP it is an unnecessary supplement.
Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
know what you think about it and if someone
has a good reason why it is allowed nowadays then please help me out.
There's a common misconception that ::foo() denotes a static method call in
PHP. What it actually does is a *scoped* call (which is why :: is called
the scope resolution operator and not the static access operator).
What :: essentially does is give you the ability to call the implementation
of a method in a particular class. A common application is the use of
parent::foo() which will not call your implementation of foo(), but the one
found in the parent class. Similarly you can use A::foo() to target a
particular class that is even further up in the inheritance hierarchy
(like, the grandparent-class). You can also call call a class that is
completely outside your inheritance hierarchy, but that's deprecated since
PHP 5.6 and will hopefully be removed in PHP 7.
Yes please, remove that non-sense.
And that will simplify some parts of code into the engine as well :-)
Julien.P
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
Jordi Boggiano wrote on 28/10/2014 07:17:
How about this instead for readonly:
public $foobar {
get { return $this-bar * $this-foo; }; readonly
}
And if the flag isn't there, set is implicitly present.
That'd mean you also can keep public readonly $foobar; as a
shorthand for readonly properties without custom getter.
I think it could be problematic to have too many variants of the syntax,
as it leads to more inconsistencies that people have to understand, and
more complex code needed in third-party parsers (IDEs, alternative
implementations, etc).
Keeping the readonly attribute also keeps the ambiguity of what it
actually means: immutable, protected, private? Sticking to the existing
visibility modifiers makes it more explicit what's actually being set.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Tue, Oct 28, 2014 at 2:50 PM, Andrea Faulds a...@ajf.me wrote: On 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. Yes, this has been like that since the beggining of the PHP project. The PHP project is a human, collaborative open source adventure before anything else. The code and the ideas written behind php.net are collaborative and owned by everyone. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Using objects as keys
Hi Stas, On 27/10/2014 18:39, Etienne Kneuss wrote: I think it should be made clear that what the target of your RFC is not to support objects as keys, what you propose instead is an implicit translation from: $a[$obj] to $a[$obj-__hash()] This is clearly different. I agree the RFC should make it very clear that foreach, key(), array_keys(), etc. will just return the hash, not the object instance. I for one was a bit confused and couldn't tell if that was the case after reading the entire RFC. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
Chris Wright wrote on 28/10/2014 09:46:
I would suggest something like this:
public $foobar {
get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}
...where only a single visibility modifier is permitted on the left,
and this is treated as the *default* visibility for the accessors,
which are free to declare another visibility if they want - so the
following would be equivalent:
public $foobar {
public get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}
The reason I opted for using var rather than having modifiers on both
sides was because I wasn't sure what should be done with expressions
like this:
public $foo { private get; private set; }
Is that allowed, and actually creates a private property? Or does the
compiler detect it and give some kind of error? It feels like a bug in
the syntax that the same information is included in more than one place,
meaning it can express contradictions.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 28 Oct 2014, at 07:17, Jordi Boggiano j.boggi...@seld.be wrote:
I like it, except for the fact that if you add a custom getter to a property
suddenly it becomes readonly unless you remember to add ; set to the end of
the block, right?
Well, no. If you choose to specify getters and setters, and only specify a
setter, of course it is read-only. It doesn’t make sense to have a getter and
no setter and yet expect a property to be writeable.
How about this instead for readonly:
public $foobar {
get { return $this-bar * $this-foo; }; readonly
}
And if the flag isn't there, set is implicitly present.
This is really confusing and I don’t think it’s a good idea.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 28 Oct 2014, at 09:46, Chris Wright c...@daverandom.com wrote:
Sorry, but I don't like this. This means that the visibility modifier is no
longer next to the thing that it applies to,
I wouldn’t say that. The visibility modifier is an aspect of the property
itself, not its implementation. A property can be public-readable and
private-writeable regardless of whether it’s a plain property or is a getter
and a setter.
IMO this is actually harmful to the readability because the order in which
the accessors were defined then becomes significant
It wouldn’t be significant. The public/private doesn’t apply to the getters and
setters, it applies to reading and writing from the property, regardless of its
implementation.
If we did’t enforce order, got the read/write syntax and getters and setters,
hypothetically this would be possible:
public/private $foobar {
set($value) { … }
get { … }
}
However, hopefully coding style guides would discourage that.
I would suggest something like this:
public $foobar {
get { return $this-bar * $this-foo; }
private set($value) { $this-bar = $value / $this-foo }
}
...where only a single visibility modifier is permitted on the left, and this
is treated as the *default* visibility for the accessors, which are free to
declare another visibility if they want
I don’t like this, it’s moving the visibility again and having it split between
the start and end of the declaration.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sun, Oct 26, 2014 at 8:11 AM, Sebastian Bergmann sebast...@php.net wrote: 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 adherence to the RFC process. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As far as I can tell there are a couple of SAPIs(to be honest everything except cli/cgi/fpm/embed and apache*) and even some exts(like mysql*, pgsql, date, pcre, etc.) where there are dedicated maintainers who seemingly can introduce new features without discussing it on the list or following through the rfc process. I'm not saying that this is a bad thing(on the contrary, I think that most of the times this happens because the maintainer is the best suited for making those decisions), but I think it would be nice if we could clarify that what exact procedures do we want to be followed for exts/SAPIs inside the php-src tree. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Readonly Properties
Andrea Faulds wrote on 28/10/2014 14:08:
On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be wrote:
I like it, except for the fact that if you add a custom getter to a property suddenly it
becomes readonly unless you remember to add ; set to the end of the block, right?
Well, no. If you choose to specify getters and setters, and only specify a
setter, of course it is read-only. It doesn’t make sense to have a getter and
no setter and yet expect a property to be writeable.
I think the problem is that the get and set annotations are serving
multiple purposes - to change the visibility, to define custom
accessor/mutator code, but also to declare whether certain actions are
possible at all. Since the default is for the property to be readable
and writable, the fact that adding { get; } makes it readonly isn't
immediately intuitive, although it does makes sense once you think about it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 28 Oct 2014, at 14:24, Rowan Collins rowan.coll...@gmail.com wrote:
Andrea Faulds wrote on 28/10/2014 14:08:
On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be wrote:
I like it, except for the fact that if you add a custom getter to a
property suddenly it becomes readonly unless you remember to add ; set
to the end of the block, right?
Well, no. If you choose to specify getters and setters, and only specify a
setter, of course it is read-only. It doesn’t make sense to have a getter
and no setter and yet expect a property to be writeable.
I think the problem is that the get and set annotations are serving multiple
purposes - to change the visibility, to define custom accessor/mutator code,
but also to declare whether certain actions are possible at all. Since the
default is for the property to be readable and writable, the fact that adding
{ get; } makes it readonly isn't immediately intuitive, although it does
makes sense once you think about it.
Hmm. Perhaps we need this, then:
public $foobar; // public read, private write
public/private $foobar; // public read, private write
public readonly $foobar; // public read, not writeable at all
This then confined set/get entirely to implementation details. A read-only
property would be denoted by readonly.
With the last one, you can only have get, for the first two, you must have both
get and set.
Does that work? Seems pretty good to me.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 28.10.2014 um 14:50 schrieb Andrea Faulds a...@ajf.me: On 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. -- Andrea Faulds http://ajf.me/ http://ajf.me/ Just a tiny update on this subject: we’re working on it. https://github.com/bwoebi/phpdbg-docs https://github.com/bwoebi/phpdbg-docs is in markdown what’ll be at some point in the official docs, I hope. It may take some little time to finish this, but then we’ll probably redirect phpdbg.com http://phpdbg.com/ page to php.net http://php.net/. The phpdbg.com http://phpdbg.com/ page is currently just horribly outdated and a relict from that time before phpdbg was merged into php-src. Bob Weinand
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal. -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
1. Sure, but the frustrating thing is that the C code (for mime-parsing) is already there and just not being used for non-POST methods. Why make everyone use pecl/framework code that duplicates what exists in PHP already (albeit for POST only)? 2. You're right. That would be too many. That's why adding a single new variable of $_FORM/BODY/foo would work for everything (including POST). Of course, $_FILES (whose name is already method-agnostic) should be populated too and not restricted to POST only. On 26 October 2014 14:21, Stas Malyshev smalys...@sugarcrm.com 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 have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/
Re: [PHP-DEV] New globals for PUT and DELETE
On 28/10/14 16:58, Ben Ramsey wrote: On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal. This already is v2, and PHP-FIG has been, well, I don't know how to call that, dismissive(?) about the invitation to discuss. Anyway, there's not been a single question since the RFC announcement, except about the dependencies, so either nobody is interested, or those who use it are fine with it. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
$_FILES (whose name is already method-agnostic) The name appears method-agnostic but the implementation obviously isn't. It works with multipart/form-data, which is tightly coupled with POST, but which isn't the only way to transfer files, not by a long shot. If you ignore the HTTP method you're being completely arbitrary if you still only decode form-data into $_FILES. For example we PUT and POST bytearray/binary files thousands of times per day. You can PUT application/xml as a valid file, heck, you can PUT a tarball, a great way to send multiple files. Would the enhanced $_FILES be populated in those cases? And if not, why not? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: jbafford
I would like access to edit the wiki and submit RFCs. Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: jbafford
On Tue, 28 Oct 2014, John Bafford wrote: I would like access to edit the wiki and submit RFCs. I've given you access to the wiki's RFC space. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Readonly Properties
On 28/10/2014 15:08, Andrea Faulds wrote:
On 28 Oct 2014, at 14:24, Rowan Collins rowan.coll...@gmail.com wrote:
Andrea Faulds wrote on 28/10/2014 14:08:
On 28 Oct 2014, at 07:17, Jordi Boggianoj.boggi...@seld.be wrote:
I like it, except for the fact that if you add a custom getter to a property suddenly it
becomes readonly unless you remember to add ; set to the end of the block,
right?
Well, no. If you choose to specify getters and setters, and only specify a
setter, of course it is read-only. It doesn’t make sense to have a getter and
no setter and yet expect a property to be writeable.
I think the problem is that the get and set annotations are serving multiple purposes -
to change the visibility, to define custom accessor/mutator code, but also to declare
whether certain actions are possible at all. Since the default is for the property to be
readable and writable, the fact that adding { get; } makes it readonly isn't
immediately intuitive, although it does makes sense once you think about it.
Hmm. Perhaps we need this, then:
public $foobar; // public read, private write
public/private $foobar; // public read, private write
public readonly $foobar; // public read, not writeable at all
This then confined set/get entirely to implementation details. A read-only
property would be denoted by readonly.
With the last one, you can only have get, for the first two, you must have both
get and set.
Does that work? Seems pretty good to me.
Yup that's definitely better than having the readonly flag in the {}
block as I had it.
I'd however say that it should be possible to define a writable property
with only a getter and then the setter would implicitly be created.
Since readonly is the way to define writability why should I have to
specify a setter (even a default empty one) if none is needed?
P.S: Don't want to open pandora's box, but we could also have writeonly
for completeness perhaps. I don't really see the use case at all though
(immutability sure, mutant bottomless pit objects not so much:).
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
