Re: [PHP-DEV] On not rushing things at the last minute

On 10 July 2018 at 15:26, Dustin Wheeler wrote: *snip* > Personally (for Class Friendship), I opted to target either 7.4 or 8.0 > (whichever was decided to be next-in-line) > Seems to me this is one of the issues - that this is something that isn't just set in stone. If there was an overall

Re: [PHP-DEV] Mailing list moderation

On 3 Jan 2018 18:13, "Chase Peeler" wrote: On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev wrote: > Hi, > > On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler > wrote: > > > > I agree with Paul. It would be different if email clients

Re: [PHP-DEV] Re: PHP's mail servers suck

On 7 Nov 2017 16:40, "Eli White" <e...@eliw.com> wrote: On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <peter.e.l...@gmail.com> wrote: > Might be worth noting that fixing the mailing lists does not amount to > taking on the php.net mail servers. The two are separate - j

Re: [PHP-DEV] Re: PHP's mail servers suck

Might be worth noting that fixing the mailing lists does not amount to taking on the php.net mail servers. The two are separate - just in case someone should be up for one, but not both tasks. On 7 November 2017 at 14:48, Eli White wrote: > Just chiming in that I have constantly

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 13:15, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 12:09, Peter Lind wrote: > > And if all typos were switching 'e' and 'n', what a wonderful world it > > would be. That is not the case though - it's possible to accidentally &g

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 13:01, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 11:01, Peter Lind wrote: > > On 12 August 2016 at 11:54, Rowan Collins <rowan.coll...@gmail.com> > wrote: > > > >> On 12/08/2016 10:21, Lester Caine wrote: > >> &

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 12:52, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 11:23, Peter Lind wrote: > > On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote: > > > >> On 12/08/16 10:42, Peter Lind wrote: > >>> On 12 August

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 10:42, Peter Lind wrote: > > On 12 August 2016 at 11:25, Lester Caine <les...@lsces.co.uk> wrote: > > > > Thanks for the ideas on this feature. > > > > A few thoughts.

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 11:54, Rowan Collins wrote: > On 12/08/2016 10:21, Lester Caine wrote: > >> Many of my systems run on secure intra-nets and much of the 'safety >> concerns' that have been brought up recently as 'essential' simply don't >> apply. >> > > There's

Re: [PHP-DEV] Simple variable handling.

On 12 August 2016 at 11:25, Lester Caine wrote: > On 12/08/16 10:07, Christoph M. Becker wrote: > >> > I'm thinking > >> > $var->setConstraint() > >> > $var->setEscape() > >> > $var->setReadOnly() > >> > > >> > Rather than having to build 'reflections' classes to pull out

Re: [PHP-DEV] Function auto-loading

On 10 Aug 2016 19:05, "Bishop Bettini" <bis...@php.net> wrote: > > On Wed, Aug 10, 2016 at 5:37 AM, Peter Lind <peter.e.l...@gmail.com> wrote: >> >> On 10 August 2016 at 10:51, Lester Caine <les...@lsces.co.uk> wrote: >> >> > On 09/08/

Re: [PHP-DEV] Function auto-loading

On 10 August 2016 at 10:51, Lester Caine wrote: > On 09/08/16 06:54, Sara Golemon wrote: > > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine wrote: > >> So Composer IS now the rule rather than some optional extra? > >> > > Yes, the community has decided that

Re: [PHP-DEV] New RFC

On 2 August 2016 at 09:11, Dan Ackroyd wrote: > Hi Tomáš, > > It has been thought about, and several people are looking at an > implementation of generics: https://wiki.php.net/rfc/generics However, > it seems quite hard to implement. > > I am beginning to wonder if

Re: [PHP-DEV] [RFC] Pipe Operator

On 9 May 2016 at 08:45, Stanislav Malyshev wrote: > Hi! > > > I have the feeling that if everyone involved *explicitly* prefixed their > > opinions with "I think that", this would be a better and more fruitful > > Is there any other option? > As in "better options"? I don't

Re: [PHP-DEV] [RFC] Pipe Operator

On 9 May 2016 at 07:37, Stanislav Malyshev wrote: > Hi! > > > "|>" is just a building block for simpler coding. It could be used > badly, but > > it helps a lot. Procedural code could be much simpler and readable with > "|>". > > I don't see how it helps anything. It just

Re: [PHP-DEV] [RFC] Pipe Operator

On 30 Apr 2016 16:43, "Lester Caine" wrote: > > On 30/04/16 14:57, Marco Pivetta wrote: > > Relevant: https://youtu.be/UvD1VjRvGIk > > Trimming the now useless error code > > As I said in the message ... no problem if you simply have a SINGLE > pathway through the code.

Re: [PHP-DEV] Re: Improving PHP's type system

On 14 April 2016 at 01:43, Zeev Suraski wrote: > > > On 14 באפר׳ 2016, at 7:14, Larry Garfield > wrote: > > > >> On 4/13/16 3:24 PM, Stanislav Malyshev wrote: > >> Hi! > >> > >>> May I suggest you the following article (more of a starting point into > >>>

Re: [PHP-DEV] Handling of withdrawn RFCs

On 21 January 2016 at 21:53, Ronald Chmara wrote: > On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana > wrote: > > An RFC could still be valuable for the project, even if the original > > author leaved, so taking it over should be possible. And it should

Re: [PHP-DEV] Handling of withdrawn RFCs

On 21 January 2016 at 22:24, Ronald Chmara <rona...@gmail.com> wrote: > On Thu, Jan 21, 2016 at 12:59 PM, Peter Lind <peter.e.l...@gmail.com> > wrote: > > On 21 January 2016 at 21:53, Ronald Chmara <rona...@gmail.com> wrote: > >> On Thu, Jan 21

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

On 13 January 2016 at 16:49, Adam Howard wrote: > Alright, you want a straight up answer, I'll provide you one. Here is > my constructive criticism. I'd like to be able to opt-out of this > conversation and not further have it flood my inbox and be able to actually >

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 7 Jan 2016 20:59, "Chase Peeler" wrote: > > On Thu, Jan 7, 2016 at 2:51 PM, Pierre Joye wrote: > > > On Jan 8, 2016 2:44 AM, "Paul M. Jones" wrote: > > > > > > > > > > On Jan 7, 2016, at 13:39, Pierre Joye

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 6 January 2016 at 21:43, François Laupretre wrote: > Le 06/01/2016 20:38, Ryan Pallas a écrit : > >> >> I agree, a conflict resolution document *and team* seems infinitely >> better. >> This team's job is to resolve things quietly and without further incident, >> however if

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 16:59, Stanislav Malyshev wrote: > Hi! > > > How exactly would you feel about having all of this made explicit to all > > the other PHP devs? Presumably you look up to some of these people - > > I presume you would feel bad. However your example is

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

> > +1. The proposed CoC is too vague for a multi-cultural environment like > ours. Reference to ethics, for example, is subjective by nature. But I'm OK > for a more precise text that everybody must explicitely approve before > getting any karma. > > But I am opposed to any form of law

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 19:53, Stanislav Malyshev wrote: > Hi! > > > Yes, I thought it up, hence it's theoretical. If you think that means it > > hasn't happened countless times along those lines, you need to learn how > > to google. > > I hope you realize how weak is an

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 20:26, Stanislav Malyshev wrote: > Hi! > > > That is the problem: you cannot discuss how to protect the accused > > without having the context of the abused. As you have yourself pointed > > out with examples, it is a tradeoff. > > But that is exactly

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 19:42, Stanislav Malyshev wrote: > Hi! > > > It's interesting to note how few people in this thread consider the > > perspective of potential harassed or abused people - instead only > > focusing on how to protect the accused. > > We do not discuss it

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 05:49, Paul M. Jones wrote: > > > On Jan 4, 2016, at 22:42, Sara Golemon wrote: > > > > Formalized rules and due process are terrible for a free and open > society? > > This proposal is neither formalized, nor due process. You're great

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 4 September 2015 at 09:43, Pavel Kouřil <pajou...@gmail.com> wrote: > On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.l...@gmail.com> wrote: > > On 4 September 2015 at 08:44, Pavel Kouřil <pajou...@gmail.com> wrote: > > > > You're arguing that,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 4 September 2015 at 08:44, Pavel Kouřil wrote: *snip* > But even just #3 seems kinda "harder" to read than the form without > any parenthesis. > > function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); } > > I know the parenthesis are optional in just

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

On 4 August 2015 at 10:13, Lauri Kenttä lauri.ken...@gmail.com wrote: On 2015-08-03 23:54, Scott Arciszewski wrote: $AES = new \PCO\Symmetric('openssl:cipher=AES-128'); It would be great if you could just ask for cipher=AES-128 without explicitly specifying the provider (openssl).

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

On 4 August 2015 at 13:56, Scott Arciszewski sc...@paragonie.com wrote: Hi Peter, It's not really a made-up string format, in the sense that it has a precedent (PDO). True, and that format sucks royally. It trips people up. Combining several arguments into one string is bad design. If it

Re: [PHP-DEV] DateInterval bug

On 13 April 2015 at 22:20, Derick Rethans der...@php.net wrote: On Sun, 12 Apr 2015, Peter Lind wrote: Hi, I wanted to get into PHP code development so I grabbed a random bug from bugs.php.net. Which turned out to be https://bugs.php.net/bug.php?id=69378 The problem the bug report

Re: [PHP-DEV] DateInterval bug

On 13 April 2015 at 22:20, Derick Rethans der...@php.net wrote: On Sun, 12 Apr 2015, Peter Lind wrote: Hi, I wanted to get into PHP code development so I grabbed a random bug from bugs.php.net. Which turned out to be https://bugs.php.net/bug.php?id=69378 The problem the bug report

[PHP-DEV] DateInterval bug

Hi, I wanted to get into PHP code development so I grabbed a random bug from bugs.php.net. Which turned out to be https://bugs.php.net/bug.php?id=69378 The problem the bug report describes is that creating a diff between two dates and then subtracting the diff from the later date does not give

Re: [PHP-DEV] Debugging code ...

It sounds like you're suggesting that all work on PHP that does not boil down to bug fixes be stopped. I'd suggest an alternative: fork PHP and only merge bugfixes in to your own version. Best of both worlds, you get to keep your beloved PHP pristine without any of the cumbersome new features,

Re: [PHP-DEV] New globals for PUT and DELETE

Last time it stranded here: https://www.mail-archive.com/internals@lists.php.net/msg67294.html And I believe it's been up a number of times before that. On 14 October 2014 14:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT

Re: [PHP-DEV] Cases Where Bash Shellshock Does Not Apply (mod_php, php-fpm )

On 26 September 2014 12:48, Andrea Faulds a...@ajf.me wrote: On 26 Sep 2014, at 11:46, marius adrian popa map...@gmail.com wrote: Maybe we need an official stance about shellshock Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m not sure there’s much we can

Re: [PHP-DEV] Cases Where Bash Shellshock Does Not Apply (mod_php, php-fpm )

On 26 September 2014 13:37, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Sep 26, 2014 at 12:59 PM, Peter Lind peter.e.l...@gmail.com wrote: On 26 September 2014 12:48, Andrea Faulds a...@ajf.me wrote: On 26 Sep 2014, at 11:46, marius adrian popa map...@gmail.com wrote: Maybe we

Re: [PHP-DEV] [VOTE][RFC] intdiv()

On 30 July 2014 19:57, Sara Golemon poll...@php.net wrote: On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote: On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote: -1 explanation: I don't think %% is clear enough % returns the 2nd part of the integer division, %%

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

On 28 September 2013 11:27, Madara Uchiha mad...@tchizik.com wrote: You guys are missing the point. This isn't a language level issue. I can imagine some sort of package or a library being made, some sort of wrapper around the current session commands, perhaps integrated into some sort of

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

On 28 September 2013 12:25, Leigh lei...@gmail.com wrote: On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote: So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

On 27 September 2013 12:12, Leigh lei...@gmail.com wrote: On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: There's several scenarios where a users IP changes and you don't want to drop their

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

On 27 September 2013 12:54, Leigh lei...@gmail.com wrote: On 27 September 2013 11:39, Peter Lind peter.e.l...@gmail.com wrote: On 27 September 2013 12:12, Leigh lei...@gmail.com wrote: So on a successful session hijack (correct SID, new IP) the attacker gets a new SID and keeps the valid

Re: [PHP-DEV] Re: Parsing PUT data

On 24 September 2013 16:59, Daniel Lowrey rdlow...@gmail.com wrote: The bigger issue here is that the superglobals are a leaky abstraction. Any HTTP request method is allowed to have an entity body, so should we also create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

Interesting to note that although Perl 6 is apparently capable of decrementing strings, it doesn't fully mirror the incrementing: http://feather.perl6.nl/syn/S03.html#line_516 Specifically: decrementing 'AAA' would not turn into 'ZZ' but would error, according to that link -- hype WWW:

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

On 19 July 2013 11:18, Dan Cryer d...@dancryer.com wrote: What's the intended use case for string increment / decrement? Personally, I instantly think of mirroring spreadsheet columns - works quite well in that context. It just seems like madness to me, using mathematical operators with

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

On 19 July 2013 12:34, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, 2013/7/19 Peter Lind peter.e.l...@gmail.com On 19 July 2013 11:18, Dan Cryer d...@dancryer.com wrote: What's the intended use case for string increment / decrement? Personally, I instantly think of mirroring spreadsheet

Re: [PHP-DEV] RFC Proposal: New assign value operator

On 27 June 2013 11:04, Tom Oram t...@scl.co.uk wrote: Hi Richard, Thanks for your reply, the main reason would be operator overloading rather than the typecasting example, the typecasting version is more for consistency. I am also fairly that there might be situations where it would be

Re: [PHP-DEV] property de-referencing

On 1 May 2013 14:35, Rasmus Schultz ras...@mindplay.dk wrote: This is a fringe feature, as evidenced by the fact that you are having a hard time convincing people that it is needed As with anything that isn't already established and well-known, it's hard to convince anyone they need

Re: [PHP-DEV] property de-referencing

On 1 May 2013 14:55, Rasmus Schultz ras...@mindplay.dk wrote: Then why are you not convincing them first to get them on board as support for your proposal. It's not a proposal yet - I didn't want to write a lengthy RFC just to learn that all I had was a brainfart, or that everyone was going

Re: [PHP-DEV] Proposed changes to PHP language

On 6 March 2013 15:50, Alexandre TAZ dos Santos Andrade alexandre...@gmail.com wrote: This item 2. Introduce base class for all PHP classes. E.g. Object. It would help in type hinting and allow to add new common methods without any magic. StdClass Already do that ?php class A {}

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

On 20 February 2013 00:12, Nikita Nefedov inefe...@gmail.com wrote: On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/19/2013 03:07 PM, Nikita Nefedov wrote: Are you grepping for all the functions or you are grepping just for some specific function? If so,

Re: [PHP-DEV] Re: release frequency?

As an outsider I would say consistency is king. Knowing that I can rely on when new versions come out is much more important than whether they contain 9 or 11 bug fixes. So, pick a schedule that works and stick to it. Just my thoughts. -- hype WWW: plphp.dk / plind.dk CV:

Re: [PHP-DEV] Core liason for PHP FIG

You realize that this is not the list of PHP FIG, right? On 16 December 2012 15:26, Lester Caine les...@lsces.co.uk wrote: Lars Strojny wrote: for all of you who don’t know, PHP FIG (Framework Interoperability Group,http://www.php-fig.org/) discusses ways frameworks and libraries can work

Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?

On 4 September 2012 15:09, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk wrote: ??? OH YES IT DOES !!! MANY times I get a a few lines of text on a white screen ... Switch off E_STRICT and everything works fine ...

Re: [PHP-DEV] RFC for Adding __toString to DateTime

Best solution from a random developers perspective: - stick the 4-line solution in the docs and on to the bug report. Then mark as won't implement It's a far better solution than choosing a random format for users, as should be more than evident by now. Regards Peter -- hype WWW: plphp.dk /

Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions

On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote: *snip* Also, be aware that BCrypt only uses the first 72 characters of the password field. So if you use a hex encoded sha512 output, a good deal of entropy would be lost (almost half of it)... Seeing as the hashing function

Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions

On 31 July 2012 22:02, Anthony Ferrara ircmax...@gmail.com wrote: Peter, On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote: On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote: *snip* Also, be aware that BCrypt only uses the first 72 characters

Re: [PHP-DEV] Adding a simple API for secure password hashing?

* snip* Stas has the right approach, not only should the methods be simplified and platform/algorithm agnostic but have a proper salt built in (there are a few CSPRNG implementations around), I've seen salts used from numbers to md5's to just being skipped altogether. Well, just to be

Re: [PHP-DEV] Adding a simple API for secure password hashing?

On 14 June 2012 15:35, Anthony Ferrara ircmax...@gmail.com wrote: Peter, Whether or not a CSPRNG is needed depends on what you're doing, your needed level of security. Perhaps add a parameter to control this, so it would be possible to make use of this function even if you need the maximum

Re: [PHP-DEV] Adding a simple API for secure password hashing?

On 14 June 2012 17:50, Ángel González keis...@gmail.com wrote: *snip* May I ask how would you end up at the situation where the attackers have the password hashes but not the salt? Any process which needs to read the password hashes will also need knowledge of the salt. Thus an attacker

Re: [PHP-DEV] running tests in parallel?

On 3 May 2012 13:12, Derick Rethans der...@php.net wrote: On Thu, 3 May 2012, zoe slattery wrote: (a) Would it still be helpful if the tests could be run faster? Yes. Running the tests on my netbook takes a very long time - yet is presumably still a good thing to do. Having them run in

Re: [PHP-DEV] [RFC] skipping optional parameters

On 18 April 2012 07:56, Alexey Shein con...@gmail.com wrote: *snip* One question about implementation: Given we have this function   function create_query($where, $order_by, $join_type='', $execute = false, $report_errors = true) {} and this statement On the engine level, it will be

Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)

On Feb 22, 2012 7:05 PM, Larry Garfield la...@garfieldtech.com wrote: On 2/21/12 5:45 PM, Tjerk Meesters wrote: On 22 Feb, 2012, at 2:03 AM, Ralf Langl...@b1-systems.de wrote: I see no reason why it would be not desirable to have PHP raise the exception rather than putting more or less

Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)

On 22 February 2012 20:04, Larry Garfield la...@garfieldtech.com wrote: On 2/22/12 12:37 PM, Peter Lind wrote: I would also support this.  There's a myriad reasons why something may return NULL or FALSE when you expect it to return an object, some of them even legitimate.  Any function

Re: [PHP-DEV] 5.4's New De-referencing plus assignment

On 30 November 2011 19:59, Will Fitch will.fi...@gmail.com wrote: Again, back to my question of why not use: MyComponent::factory($bar, $option); Depending on what ::factory does, it could then pass $option(s) to the constructor or method getting your instance needed. It brings to mind a

Re: [PHP-DEV] Final version, RFC release process

On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote: Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's

Re: [PHP-DEV] Final version, RFC release process

On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated

Re: [PHP-DEV] Final version, RFC release process

On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release

Re: [PHP-DEV] [PATCH] Notice on array to string convertion

On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean

Re: [PHP-DEV] Final version, RFC release process

On Jun 2, 2011 12:46 AM, Pierre Joye pierre@gmail.com wrote: hi Chris On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones christopher.jo...@oracle.com wrote: On 06/01/2011 03:09 AM, Pierre Joye wrote: URL: https://wiki.php.net/rfc/releaseprocess Pierre, There are some

Re: [PHP-DEV] [RFC] Return type-hint

On Apr 29, 2011 4:47 PM, Martin Scotta martinsco...@gmail.com wrote: Martin Scotta On Thu, Apr 28, 2011 at 5:15 PM, Peter Lind peter.e.l...@gmail.com wrote: 2011/4/28 Martin Scotta martinsco...@gmail.com: * snip * IMHO I would not trust on any return value, as PHP did not ensure

Re: [PHP-DEV] [RFC] Return type-hint

2011/4/28 Martin Scotta martinsco...@gmail.com: * snip * IMHO I would not trust on any return value, as PHP did not ensure anything about them. Even more, I do not write code that depend on return values, I prefer to use input/output parameters, I cannot help but wonder why PHP is your

Re: [PHP-DEV] How deep is copy on write?

On 19 January 2011 20:05, la...@garfieldtech.com la...@garfieldtech.com wrote: So it sounds like the general answer is that if you pass a complex array to a function by value and mess with it, data is duplicated for every item you modify and its direct ancestors up to the root variable but not

Re: [PHP-DEV] [RFC] new foo()-bar()

On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote: Hi all, I'm here again to presents another proposal, which adds support for instantiating a class and calling its methods and accessing its properties on same command. Example: ?php class bar {  public $x = 'PHP'; }

Re: [PHP-DEV] [RFC] new foo()-bar()

On 26 November 2010 21:37, Ferenc Kovacs i...@tyrael.hu wrote: On Fri, Nov 26, 2010 at 9:25 PM, Peter Lind peter.e.l...@gmail.com wrote: On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote: Hi all, I'm here again to presents another proposal, which adds support

Re: [PHP-DEV] [RFC] new foo()-bar()

On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote: It seems fairly handy and I've been in situations where I wanted to do something like that - in fact, I use factories to achieve something

Re: [PHP-DEV] [RFC] new foo()-bar()

On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote: It seems fairly handy and I've been in situations where I wanted to do something like that - in fact, I use factories to achieve something

Re: [PHP-DEV] Feasibility of additional support around constants.

*snip* Seems to me that some of this could be handled with a custom built function wrapping http://dk2.php.net/manual/en/function.get-defined-constants.php Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals -

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Den 2010 10 30 03:51 skrev Chad Emrys ad...@codeangel.org: * snip * What is in a name anyway? There's something VERY ironic about a statement like that given what you're asking for ... Regards Peter

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On 30 October 2010 09:09, Mike Van Riel mike.vanr...@naenius.com wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your answer faster..) Most of the people coming to ##php on freenode asking questions like that have a hard time

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On 30 October 2010 09:34, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 02:16 AM, Peter Lind wrote: On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com  wrote: * snip * (additionally I wonder why people ask such a simple question on IRC whilst googling provides your

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On 30 October 2010 19:18, Chad Emrys ad...@codeangel.org wrote: On 10/30/2010 11:58 AM, Daniel P. Brown wrote: On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.org  wrote: It's not that I'm that sure of myself, it's that I believe that my opinion has merit, and I keep seeing the

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On 30 October 2010 22:13, Chad Emrys ad...@codeangel.org wrote: *snip* I actually know Etienne, he does spend some of his time fighting the good fight of supporting PHP :p.  Anyway he has said the lemon parser project is going kind of slow as it is proving to be more difficult because some

Re: [PHP-DEV] [RFC] Array Dereferencing

On 8 June 2010 17:28, Brian Moon br...@moonspot.net wrote: The operator that really determines this is 'new' - which is already documented. So there isn't any ambiguity. Not to say that documenting the other operators would be bad, just saying there's no ambiguity here :)  Also, allowing new

Re: [PHP-DEV] Type hinting

On 23 May 2010 07:52, Larry Garfield la...@garfieldtech.com wrote: On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote: At 01:01 23/05/2010, Hannes Magnusson wrote: On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 22.05.2010, at 18:30, Josh Davis wrote:

Re: [PHP-DEV] Obscure token name

On 29 April 2010 15:42, mathieu.suen mathieu.s...@easyflirt.com wrote: Steven Van Poeck wrote: Folks, can't you just accept that T_PAAMAYIM_NEKUDOTAYIM is intended to make you smile?  There's nothing to see here, please move along. - Martin +1 Don' t you read what I say? I'd be

Re: [PHP-DEV] A critique of PHP 6

On 21 April 2010 11:46, Adi Nita adi.n...@gmail.com wrote: I cannot agree with the idea of preferring working applications to good working applications. Except that's not what's at stake. The application does not become one bit better or worse by using an updated function that's more consistent

Re: [PHP-DEV] Assign array with __get

Kneuss wrote: On Thu, Mar 18, 2010 at 5:47 PM, mathieu.suen mathieu.s...@easyflirt.com  wrote: Peter Lind wrote: On the contrary, it's quite obvious what's going on. In both examples __get() returns an array as PHP would normally do it (i.e. NOT by reference) which means that if you try

Re: [PHP-DEV] Assign array with __get

I think there is a lot  to say why is not working but just look at those 2 execution: 1st class A {        public function __get($name)        {                $this-$name = array();                return $this-$name;        }        public function test()        {