[PHP-DEV] Re: Output, parameter

On 06/18/2015 11:12 AM, Dominic Grostate wrote: A feature I'd quite like to see is something similar to C# out arguments. Which is an argument provided empty to a function (or with a value to be ignored) that the function must write to before returning. Normally this wouldn't be necessary since

[PHP-DEV] Re: Throwable::addSuppressed()

On 07/31/2015 08:25 PM, Markus Malkusch wrote: Stephen Coakley: Interesting thought, but how is this different than including a previous throwable and throwing a new, more descriptive exception? } catch (Exception $e1) { try { $resource-close(); } catch

Re: [PHP-DEV] Re: Serializing exceptions

feature right now, and we should fix the feature instead of throwing it out. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Access of protected members

languages have, including Java and C#. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Throwable::addSuppressed()

new Exception(Exception 2); } } catch (Throwable $e) { var_dump($e-getSupressed()); } we would have $e be exception 2, and $e-getSupressed() return exception 1. The more I think about it, the better the idea sounds. Good thought, Markus! -- Stephen Coakley -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Re: Throwable::addSuppressed()

release, too, I think. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Throwable::addSuppressed()

On 08/02/2015 03:50 AM, Markus Malkusch wrote: Stephen Coakley: So what should be the desired behavior, in regard to bug #68270? One possible behavior would be to, if an exception is thrown inside a finally block, to attach the uncaught exception from the try block via the addSupressed

[PHP-DEV] Re: Move internals discussion to a better medium

other kinds of attachments and whatnot. The mailing list has been here for a long time, and it will be an uphill battle if you want to have this discussion. I'm sure many people would be open to the idea, but many also will not be. I'd love to be proved wrong, though. -- Stephen Coakley -- PHP

Re: [PHP-DEV] Re: Move internals discussion to a better medium

On 08/02/2015 05:31 PM, Rowan Collins wrote: On 2 August 2015 23:15:12 BST, Stephen Coakley m...@stephencoakley.com wrote: Heck, Thunderbird is technically a discontinued product. O/T, but to my knowledge Thunderbird is not discontinued, it's just changed management because Mozilla

Re: [PHP-DEV] Re: Move internals discussion to a better medium

with the current bug tracker). A forum is the correct alternative to a mailing list, if we were looking for an alternative. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Move internals discussion to a better medium

readers. Heck, Thunderbird is technically a discontinued product. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Move internals discussion to a better medium

. Of course, it's just my preference. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Move internals discussion to a better medium

a discussion system. On the other hand, more modern tools pose more advantages than disadvantages. I don't think GitHub issues is the right alternative, but I'm glad the OP brought the discussion up anyway. -- Stephen Coakley -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] Move internals discussion to a better medium

PHP uses a mix of wiki and nominated discussion threads, but you started this thread talking about the discussions, not the RFCs. Regards, Yeah, issue tracking isn't really the right thing for daily discussions. A forum would be a reasonable alternative to a mailing list, however. -- Stephen

Re: [PHP-DEV] Re: Move internals discussion to a better medium

invented). -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Exposing object handles to userland

spl_object_hash() to do the same thing but doesn't work well in conjunction with forking (probably due to the randomness factor). +1 -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Serializing exceptions

a problem that should be resolved in some way. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Serializing exceptions

serialize and unserialize with eval()'s. I think allowing the serialize to drop args in the trace and just include a warning in the docs about the serialization being lossy. My 2 cents. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

[PHP-DEV] Re: Throwable::addSuppressed()

something with $resource here... } finally { $resource-close(); } -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Move internals discussion to a better medium

server. That would make everyone happy... except for the people who want to avoid dual interfaces (I think I've heard this before...) -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Move internals discussion to a better medium

On 08/02/2015 06:40 PM, Lester Caine wrote: On 02/08/15 23:41, Stephen Coakley wrote: Thunderbird works great for reading nested replies and past archives, but replying has about a 50% chance of success for me. Oh well. I'm up to 24Gb of history over some 20 years and despite attempts by some

Re: [PHP-DEV] Re: Move internals discussion to a better medium

into an addition to the existing email channels? No need to MOVE anything! What is stopping development? NNTP is an ancient protocol. Nobody wants to bother writing *new* software for it. -- Stephen Coakley -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] Move internals discussion to a better medium

On 08/04/2015 11:36 AM, Ferenc Kovacs wrote: On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley wrote: You have to admit, NNTP news is an aging

Re: [PHP-DEV] Re: Move internals discussion to a better medium

On 08/04/2015 12:28 PM, Florian Anderiasch wrote: On 08/03/2015 12:22 AM, Stephen Coakley wrote: Personally, I'd like to see the mailing list move to a forum-type system. Lower barrier of entry, more visible archives, and more modern medium that supports other kinds of attachments and whatnot

[PHP-DEV] Re: Some words about the basic ideas of PHP

On 10/26/2015 05:09 AM, Frank Meier wrote: Hi to all of you, first I want to apologize for may bad English, .. . . I write because I feel that that the way how you see your own product PHP is totally wrong. I do not mean with it that the construction of the language is wrong. Ah, OK. So

[PHP-DEV] Support for writing and executing compiled opcode

Hello all, I've been thinking about PHP optimization and distribution, and I would like to hear some opinions on introducing a new feature for a future PHP 7 version. Here's the concept: allow PHP opcode to be both saved after parsing a file, and to be loaded and executed, similar to the

Re: [PHP-DEV] Support for writing and executing compiled opcode

On 11/13/2015 03:45 PM, Sebastian Bergmann wrote: On 11/13/2015 04:35 PM, Stephen Coakley wrote: This is quite similar to Python's ability to execute Python scripts compiled to bytecode as *.pyc files. The feature has seen great success in Python, mostly for distributing releases of software

Re: [PHP-DEV] Support for writing and executing compiled opcode

On 11/13/2015 05:46 PM, Rasmus Lerdorf wrote: On Nov 13, 2015, at 17:00, Stephen Coakley <m...@stephencoakley.com> wrote: On 11/13/2015 03:45 PM, Sebastian Bergmann wrote: On 11/13/2015 04:35 PM, Stephen Coakley wrote: This is quite similar to Python's ability to execute Python s

[PHP-DEV] Re: Friend class/function

On 11/01/2015 10:04 AM, georges wrote: ​Hi php internals, I recently discovered ​the "friendship concept" in c++ and i really love the concept. And i wonder if the php internals would be interested to implements it in the next 7.x major version. ​The concept is simple: It would allow

Re: [PHP-DEV] [VOTE] Void Return Type RFC

On 10/29/2015 07:44 AM, Dan Ackroyd wrote: Hi Internals, Stanislav Malyshev wrote: every PHP function actually returns something (at least null). So this type would not actually be right and would not reflect what actually is happening. Well obviously we would need to have a followup RFC to

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On 10/08/2015 04:14 PM, Larry Garfield wrote: On 10/01/2015 01:59 AM, Stephen Coakley wrote: So then, in summary, threads & multiprocessing enables you to do more *work* simultaneously, while async **maximizes the usefulness of each thread you have**. So using both is actually an incred

[PHP-DEV] Re: Let's discuss enums!

On 09/17/2015 06:06 PM, Rowan Collins wrote: Hi All, This has come up in passing a few times recently, but I'm not sure there's ever been a dedicated discussion of it: would it be useful for PHP to have a built-in Enumeration type, and if so, how should it look? Many other languages have enum

Re: [PHP-DEV] Re: Generic classes and methods RFC

On 09/07/2015 02:02 PM, George Bond wrote: On 7 September 2015 at 11:37, Ben Scholzen wrote: Hello, Hi Ben! Generics are a feature I'd love to see in PHP. I think this RFC could do with a little elaboration, though. Something that's particularly important to me is if it

[PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

On 09/29/2015 11:15 AM, Daniel Lowrey wrote: On Sep 28, 2015, at 3:29 AM, S.A.N wrote:> > Are there any future plans for - async/await?> This need to know now, not to use these words to constants, and class names...> > -- > PHP Internals - PHP Runtime Development

[PHP-DEV] Re: Arrow function expressions in PHP

On 09/26/2015 11:17 AM, Levi Morrison wrote: (Email in gist format: https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c) In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create an anonymous function with one parameter `x` that will return `x * 2`. For example: (x) =>

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On 09/29/2015 10:22 AM, Thomas Hruska wrote: On 9/29/2015 6:52 AM, Joe Watkins wrote: We shouldn't reserve words on a whim ... async/await doesn't solve any problems for multithreaded programming, at all ... it solves problems for asynchronous programming, a different concept ... let's not

Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?

On 09/29/2015 01:04 PM, S.A.N wrote: Implementing elegant, readable, and stable asynchronous code in userland PHP code is very possible. In fact, I’ve done exactly this with Icicle (https://github.com/icicleio/icicle). Icicle uses generators and promises to implement coroutines. When a

Re: [PHP-DEV] Re: Arrow function expressions in PHP

On 10/01/2015 06:52 AM, Levi Morrison wrote: On Wed, Sep 30, 2015 at 11:59 PM, Stephen Coakley <m...@stephencoakley.com> wrote: On 09/26/2015 11:17 AM, Levi Morrison wrote: (Email in gist format: https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c) In EcmaScript 201

Re: [PHP-DEV] Re: Arrow function expressions in PHP

On 10/01/2015 06:52 AM, Levi Morrison wrote: > On Wed, Sep 30, 2015 at 11:59 PM, Stephen Coakley <m...@stephencoakley.com> wrote: >> On 09/26/2015 11:17 AM, Levi Morrison wrote: >>> >>> (Email in gist format: >>> https://gist.github.com/morrisonlevi/f

[PHP-DEV] Re: RFC: Generics

On 09/24/2015 03:43 PM, Dominic Grostate wrote: Hi Ben & Internals, I spent most of today and yesterday just getting used to the parser language. I was able to implement the basic syntax on most of the constructs, just to get a partial proof of concept going.

[PHP-DEV] Re: RFC Operator Overloading in Userspace

On Mon, 04 Jan 2016 16:34:21 +, Andrea Faulds wrote: > Hi Sara, > > Sara Golemon wrote: >> Patricio Tarantino has asked me to help him propose Operator >> Overloading in PHP 7.1 (based in part on my operator extension in >> PECL). I think we can expose this to usespace as magic methods with

[PHP-DEV] Re: [RFC] Square bracket syntax for array destructuring assignment

On 04/07/2016 07:21 AM, Andrea Faulds wrote: Hi everyone, Bob and I have made an RFC which proposes an alternative syntax for list(): https://wiki.php.net/rfc/short_list_syntax Please tell us your thoughts. Thanks! Mhm, yes, I like it a lot! +1 -- Stephen -- PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuringassignment

On 04/07/2016 07:37 AM, Lester Caine wrote: Do we really need to make everything so shorthand that one has no idea what one is looking at when scanning code? That's the goal right? We're trying to make Perl 7 here. Just kidding. I like it because it makes the syntax look consistent with

Re: [PHP-DEV] [RFC Discussion] Typed Properties

On 04/06/2016 11:33 AM, Phil Sturgeon wrote: We polled pretty hard and had a bunch of discussions about how multiple declarations should work, and ended up siding with Zeev and Larry, and all those others saying that type declarations should work for all just as visibility does currently:

[PHP-DEV] Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: So I want to "return a NULL". I want to express uncertainty, a nonexistence. But I want to express that I will return something. And I want to have this NULL checking at interpretation time. I want everything, and none of the drawbacks. As

Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution timepolymorphic methods

On 03/21/2016 11:09 PM, Levi Morrison wrote: This requires you to query state with `isSome()`. This is hardly any different from a null case, just more code. We can already accurately distinguish between `null` and another value. If we want an option for safer PHP code I think we need a safer

[PHP-DEV] Re: [RFC] Traits with interfaces

On Wed, 17 Feb 2016 09:25:50 -0500, Kevin Gessner wrote: > Hello internals team! I'd like to propose an RFC to allow traits to > implement interfaces. > > I've noticed s pattern in Etsy's code and elsewhere, where a trait > provides a common implementation of an interface. Classes that use the

[PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

On 02/18/2016 06:41 AM, Nikita Popov wrote: Hi internals! I've created a bulk-deprecation RFC for PHP 7.1: https://wiki.php.net/rfc/deprecations_php_7_1 I'm using this RFC to collect various deprecations targeting PHP 7.1, as having individual RFCs for these is too much management overhead.

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

On 03/04/2016 07:53 AM, Johannes Schlüter wrote: On Thu, 2016-02-18 at 19:57 +, Andrea Faulds wrote: I've actually used create_function on occasion for programmatically generating functions (in particular to create a function for each PHP operator), but it's trivially polyfillable, and it'd

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

On 03/04/2016 01:17 AM, Davey Shafik wrote: On Thu, Mar 3, 2016 at 2:19 PM, Stephen Coakley <m...@stephencoakley.com> wrote: On Wed, 17 Feb 2016 09:25:50 -0500, Kevin Gessner wrote: Hello internals team! I'd like to propose an RFC to allow traits to implement interfaces. I've not

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On 03/05/2016 12:26 PM, Walter Parker wrote: For software written for other people and for projects that don't have ongoing tech staffs that do tech debt maintenance, they would like to keep old, working code running. Telling them that they must spend money to update the software so that the

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

On 03/04/2016 03:49 PM, Johannes Schlüter wrote: On Fri, 2016-03-04 at 12:29 -0600, Stephen Coakley wrote: Not a complete polyfill, since $newfunc is a closure and not a string, so you cannot print out the function name. I have no idea if any code relies on the lambda itself being a string

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1

On 02/18/2016 04:45 PM, Zeev Suraski wrote: With rand functions, I don't think we need to touch them. For some applications, low-key randomness is just fine - if you need to shuffle array of 20 elements or randomize unit test to ensure you're not testing same value all the time, low-quality

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

On 05/04/2016 05:59 AM, S.A.N wrote: EventLoop interface, on development stage: https://github.com/async-interop/event-loop That's a userland design for event loops; async/await and coroutines don't necessarily depend on an event loop. They could be added to the language without an event

Re: [PHP-DEV] Re: async/await - is future reserved words in PHP 7.x?

On 05/04/2016 11:44 AM, Niklas Keller wrote: 2016-05-04 16:40 GMT+02:00 Stephen Coakley <m...@stephencoakley.com>: Why do we have to wait until PHP 8? Should be mostly backwards compatible and be fine in 7.2 or so. Issue is probably more deciding on an API. I don't think we should w

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

On 04/30/2016 01:05 PM, Larry Garfield wrote: On 04/29/2016 07:19 PM, Stanislav Malyshev wrote: In a way... Sara, this syntax feels like it's only one step removed from promises; if any of the chained steps involve IO, it becomes basically what promises are for. Am I barking down the wrong

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

On 04/30/2016 06:14 PM, Rowan Collins wrote: On 29/04/2016 20:58, Sara Golemon wrote: Let's say I want to add a condition just before getFileArg(); with the current version I've got to: - go to the beginning of the chain, and assign to something other than $ret - go to where I want to break the

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

On Wed, 13 Apr 2016 10:53:13 -0600, Levi Morrison wrote: > Continued (hit send by hotkey accident): > > On Wed, Apr 13, 2016 at 10:50 AM, Levi Morrison wrote: >> First, some background: several versions of PHP ago authors of >> functions and methods could only restrict types to

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

On 05/09/2016 11:41 AM, Sara Golemon wrote: On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote: Neither of these is true for |>-$$ thing - it does not have any matches in any languages I can think of. You lack imagination. Here's three to get you started:

[PHP-DEV] Re: Method compare()

On 08/09/2016 12:33 PM, David Rodrigues wrote: Currently PHP has a method called "version_compare()". Should be great if we have the same function but to general usage. There are some implementations on web for that, but I guess that it could be done natively. compare(mixed $a, mixed $b,