Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility

On 7/16/12 5:29 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard ama...@amaury.net wrote: Yes, but only if you have to write an accessor. If you just want an attribute that is: - readable from everywhere - writable from the current class only

Re: [PHP-DEV] Regarding PHP6, string/array APIs

On 7/20/12 2:33 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, So I've been thinking about this for a while. Here's what I've come up with: 1. We want to maintain loose typing, so implementing a different API on string than on int types would be bad. 2. We want to retain backwards

Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility

On 7/23/12 12:38 PM, Amaury Bouchard ama...@amaury.netmailto:ama...@amaury.net wrote: 2012/7/23 André Rømcke andre.rom...@ez.nomailto:andre.rom...@ez.no I think these two proposals can be synced up, what if: public readonly $a; Is shorthand for: public $a { get; protected set

Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces

On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote: On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig kris.cr...@gmail.commailto:kris.cr...@gmail.com wrote: On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara ircmax...@gmail.commailto:ircmax...@gmail.comwrote: Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan

Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces

( resending with correct formatting, and missing context while at it, sorry about that ) On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote: (...) Another aspect here is that there is no reasonable syntax for this feature, at least I can't think of one: * The syntax `$foo = (InterfaceName)

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 8, 2012, at 10:07 PM, Denis Portnov denixp...@gmail.com wrote: 08.10.2012 15:52, Clint Priest пишет: public $Hours { get { return $this-Seconds / 3600; } set { $this-Seconds = $value; } issethttp://www.php.net/isset { return

Re: [PHP-DEV] [RFC] Propety Accessors v1.1

On Oct 11, 2012, at 4:59 AM, Clint Priest cpri...@zerocue.com wrote: Why is everyone so dead set against read-only and write-only? I could not disagree more with you on what is pretty and readable. To me: public read-only $hours { get { ... } } Is infinitely more

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

On Feb 18, 2013, at 23:03 , Christopher Jones christopher.jo...@oracle.com wrote: On 02/18/2013 10:52 AM, Christopher Jones wrote: I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. In the so bad I can't resist sending it category is

Re: [PHP-DEV] PHP 6 : a new API ?

On Feb 20, 2013, at 11:19 , Sebastian Krebs krebs@gmail.com wrote: 2013/2/20 Klaus Ufo klaus...@yahoo.fr Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages

Re: [PHP-DEV] Property get/set syntax

On Wed, Aug 10, 2011 at 10:16 PM, Kalle Sommer Nielsen ka...@php.netwrote: Hi Sebastian 2011/8/10 Sebastian Krebs sebastian.krebs.ber...@googlemail.com: Hi, From time to time I'm looking over the existing RFCs and I'm wondering what happens to them. For example Property get/set syntax

[PHP-DEV] Anonymous functions are currently implemented using the Closure class. This is an implementation detail and should not be relied upon.

Despite several mentions in the manual, lots of php 5.3 code uses this with instanceof or in function signature (eg: Doctrine 2). If you don't want to support this in the future, could this be cleaned-up in 5.4? ( the longer you wait, the more you break ) Possibly by creating a interface called

Re: [PHP-DEV] SplClassLoader

On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, For all those interested, I have updated the RFC with better explanation, included example implementation and also example usage. If you have any other wishes, doubts, etc, feel free to

Re: [PHP-DEV] SplClassLoader

On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei kont...@beberlei.dewrote: I think the following two requirements should be covered by configuration aswell: 1. Have the autoloader be silent, i.e. doing a file_exists() check. API idea $loader = new SplClassLoader(...,

Re: [PHP-DEV] SplClassLoader

On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote: 2011/10/26 André Rømcke a...@ez.no: On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, For all those interested, I have updated the RFC with better explanation

Re: [PHP-DEV] SplClassLoader

standardized how such a basic thing is done in php projects in the wild. On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke a...@ez.no wrote: On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote: 2011/10/26 André Rømcke a...@ez.no: On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla

Re: [PHP-DEV] SplClassLoader

. This appears to be the general consensus of PSR-0 and my opinion on the matter. Regards, Paul Dragoonis. On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke a...@ez.no wrote: On Thu, Oct 27, 2011 at 4:30 AM, Laruence larue...@php.net wrote: 2011/10/26 André Rømcke a...@ez.no

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:55 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi Nikita, Thanks. It's your option and I won't fight. But it seems my proposal is not yet 100%. Some things I have either identified or people have reported. 1- Remove -register() and

Re: [PHP-DEV] Return Type Hinting for Methods RFC

2011/12/23 John Crenshaw johncrens...@priacta.com From: Will Fitch [mailto:will.fi...@gmail.com] I would like to take this opportunity to query on a consensus: Would you prefer to allow methods with type hinted return values to return null at will, or add a marker noting that it *may*

Re: [PHP-DEV] Return Type Hinting for Methods RFC

solution. This looks fine to me, looks more php like then the C# examples. On Dec 23, 2011, at 6:31 PM, André Rømcke wrote: 2011/12/23 John Crenshaw johncrens...@priacta.com From: Will Fitch [mailto:will.fi...@gmail.com] I would like to take this opportunity to query on a consensus

[PHP-DEV] REQUEST_TIME change in PHP 5.4

Hi, a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4 instead of adding a new parameter? (like REQUEST_MICROTIME) Is the Release Process not followed yet? - x.y.z to x.y+1.z - (...) - Backward compatibility must be kept (

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans der...@php.net wrote: On Sat, 24 Dec 2011, Pierre Joye wrote: hm, I should read better... The REQUEST_TIME value inside server now returns a floating point number How does it break BC except if one is doing a strong type test? which

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2011/12/27 Ilia Alshanetsky i...@ilia.ws: The change is inside 5.4 version which adjust breaks BC. I don't follow you here Ilia. As per

Re: [PHP-DEV] 5.4.0 rc6 and release

On Fri, Jan 20, 2012 at 1:43 AM, Clint Byrum cl...@ubuntu.com wrote: Excerpts from Stas Malyshev's message of Thu Jan 19 16:08:28 -0800 2012: Hi! - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems?

Re: [PHP-DEV] 5.4.0 rc6 and release

On Tue, Mar 27, 2012 at 8:45 AM, Pierre Joye pierre@gmail.com wrote: hi, hi, On Tue, Mar 27, 2012 at 8:38 AM, Clint Byrum cl...@ubuntu.com wrote: I think the lesson here is to get the necessary bits from Suhosin into PHP's core so that users can feel safe when using stock PHP, rather

Re: [PHP-DEV] Type hinting

Hi all: On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Lukas: On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote: Same deal as E_NOTICE. Either you care about them or you dont. Exactly. The type hinting situation is unique.

Re: [PHP-DEV] Type hinting

Hi Lukas! On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 09.06.2010, at 12:01, André Rømcke wrote: Example: function fetchById( int $id, bool $asObject = true ) If weak type hints are accepted, type hints would be useless in this case as consumer

Re: [PHP-DEV] PHP 5.4: Adding APC

On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine les...@lsces.co.uk wrote: Derick Rethans wrote: Actually, Kalle just pointed out that it compiles just fine. In that case, I think we should put it in trunk and in the 5.4 alpha. As long as it is disabled by default and can easily be replaced by

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On Mon, Nov 1, 2010 at 9:47 PM, Felipe Pena felipe...@gmail.com wrote: 2010/11/1 Richard Lynch c...@l-i-e.com On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we

Re: [PHP-DEV] Hold off 5.4

On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote: On 2010-11-23, Derick Rethans der...@php.net wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: . classes named as any of the type hint scalar types do not work

Re: [PHP-DEV] Hold off 5.4

On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke a...@ez.no wrote: On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote: On 2010-11-23, Derick Rethans der...@php.net wrote: On Mon, 22 Nov 2010, Felipe Pena wrote

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.netwrote: 2010/11/30 Kalle Sommer Nielsen ka...@php.net: Hi 2010/11/30 Patrick ALLAERT patrickalla...@php.net: With this patch, something looks inconsistent to me: Both properties and methods have a visibility

Re: [PHP-DEV] Extensions to traits

On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt mail_ben_schm...@yahoo.com.auwrote: On 11/02/11 3:37 AM, Philip Olson wrote: You now have rights to the wiki rfc namespace. Thanks a lot, Philip. I have now made an RFC based on the most recent discussions:

Re: [PHP-DEV] Wake up

On Sep 11, 2013, at 15:52 , Terence Copestake terence.copest...@gmail.com wrote: (.. ) a concern brought up repeatedly both here and in various blogs is the lack of direction or vision. There's a conflict between people who want to keep PHP simple and accessible and people who want to make

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 09 Feb 2015, at 19:24 , guilhermebla...@gmail.com wrote: Hi Andrea, I totally see your viewpoint. That's why initially I voted YES, because your proposal somehow makes sense. My when I thought over and use a weak/strict boolean type conversion on my own brain, I came to the conclusion

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

On 02 Feb 2015, at 17:35 , Derick Rethans der...@php.net wrote: On Mon, 2 Feb 2015, Dmitry Stogov wrote: As I already told, in my opinion, version 0.1 was the perfect solution that fit into PHP semantic very well. declare(strict_types=1); - is really weird solution. It changes type

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 09 Feb 2015, at 16:04 , Sebastian Bergmann sebast...@php.net wrote: Am 09.02.2015 um 15:50 schrieb Pierre Joye: Not strict? You loose me here. I want support for scalar types in signatures. I want these type declarations to be strictly enforced. This is not wanted and not proposed by

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

Congratulations Antony, Andrea and (yes) Zeev! Thanks to everyone involved, this is a great step forwards and a perfect wrap for PHP 7.0 RFC proposal freeze :) André On Mar 16, 2015, at 23:05 , Chris Harvey ch...@chrisnharvey.com wrote: Congratulations Anthony, and to Andrea for her

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On Mar 17, 2015, at 18:04 , Leigh lei...@gmail.com wrote: On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to

Re: [PHP-DEV] Final properties

> On Apr 9, 2016, at 09:39 , Sebastian Bergmann wrote: > > Am 05.04.2016 um 11:13 schrieb Marco Pivetta: >> First of all: +1 to this: very useful for value objects! > > My thought exactly. Big +1 on this feature for the exact same reasons. > >> do we want to use `final`,

Re: [PHP-DEV] Final properties

> On Apr 11, 2016, at 06:59 , Larry Garfield wrote: > ... > (Which leads to "can interfaces define properties", which leads right back to > "well what can you do with them", which leads back to the Properties RFC. > Which I still want to see happen at some point if at

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

> On 25 Apr 2016, at 16:36 , Rowan Collins wrote: > > S.A.N wrote on 25/04/2016 15:09: >> In userland lacks the ability to store data in the shared memory >> modules, do not use pecl modules, it would be very nice to have a >> function: >> >> opcache_get($key); >>

Re: [PHP-DEV] Final properties

On 14. apr. 2016, at 11.47, Lester Caine <les...@lsces.co.uk> wrote: > >> On 14/04/16 08:52, André Rømcke wrote: >> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 > > This actually summarises many of the problems all of these 'extras' are > creating for v

Re: [PHP-DEV] Final properties

> On 14 Apr 2016, at 00:36 , Stanislav Malyshev wrote: > > With getters/setters, the answer is clear - yes, you can extend it with > setters, but if your invariant relies on immutability, you'd be > violating LSP. With properties, not clear. So in summary preference

Re: [PHP-DEV] Final properties

> On 16 Apr 2016, at 11:19 , Lester Caine <les...@lsces.co.uk> wrote: > > On 16/04/16 06:56, André Rømcke wrote: >>>> This actually summarises many of the problems all of these 'extras' are >>>> creating for very little gain. >>>> >&

[PHP-DEV] Request for Karma

Hello PHP Team, Even if to late for 7.1, it’s summer time and I’d like to contribute to moving forward on updating a RFC for Property Accessors Syntax to bring that up to level of 7.x. I’m not a C programmer so I’m interested in finding someone to co-write this with. As for background I’m

Re: [PHP-DEV] HYBRID VM

> On 5 May 2017, at 22:06, Dmitry Stogov wrote: > > It provides comparabele improvement on smal benchmarks, without degradation > on real apps. > It can be compiled in reasonale time (GOTO requres significant time anda lot > of memory). > Finally HYBRID fallbak to CALL if

Re: [PHP-DEV] HYBRID VM

> On 10 May 2017, at 10:53, "li...@rhsoft.net" <li...@rhsoft.net> wrote: > > > Am 10.05.2017 um 08:21 schrieb André Rømcke: >>> On 5 May 2017, at 22:06, Dmitry Stogov <dmi...@zend.com> wrote: >>> >>> It provides comparabele improvem

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

> On 19 Jul 2018, at 13:34, Dmitry Stogov wrote: > > I've run few benchmarks, to measure the performance penalty of this proposal. > > > https://gist.github.com/dstogov/b9fc0fdccfb8bf7bae121ce3d3ff1db1 > > > In most cases real-life apps become ~1% slower. In the worst case, I got 6% >

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

On 7 Jul 2018, at 23:13, Zeev Suraski wrote: >> -Original Message- >> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara >> Golemon >> Sent: Friday, July 6, 2018 10:36 PM >> To: Christoph M. Becker >> Cc: Nikita Popov ; s...@php.net; Björn Larsson >> ; Dan Ackroyd ; >>

Re: [PHP-DEV] [RFC] Property write visibility

>> "Attempting to pass a property value outside of allowed writable scope >> as a reference, results in an error." > > ... we definitely shouldn't do this, because it goes against existing > language semantics. You can take a reference to a normal private property > (i.e. private get, private

Re: [PHP-DEV] [RFC] Property write visibility

> Perhaps another option could be to use attributes: > > <> > public int $id; I’d actually also like a syntax like that as well for ReadOnly and Immutable in the end. It's more readable and it would be possible to annotate on the class level as well (to affect all properties). So I initially

Re: [PHP-DEV] [RFC] Property write visibility

> > ergonomic, and in the case of magic method usage improve performance. >> > > I think this is a good direction to explore, but would recommend delaying > it until PHP 8.1. As the RFC and discussion note, the design space here > overlaps significantly with both readonly/immutability and property

Re: [PHP-DEV] [RFC] Property write visibility

> > I think the only thing worth mentioning where references are concerned is > that "$x =& $this->prop" is considered a write of $this->prop, not a read, > so it is subject to the write visibility. But once the reference is > acquired, visibility no longer factors into the behavior. > > Ok,

[PHP-DEV] [RFC] Property write visibility

properties. These are the common use cases where users tend to resort to magic methods or setter/getter methods. This proposal will as such avoid unnecessary boilerplate, makes coding easier and more ergonomic, and in the case of magic method usage improve performance. Best, André Rømcke

Re: [PHP-DEV] [RFC] Property write visibility

i32, Essentially a feature using "attributes": https://docs.rs/readonly/0.1.6/readonly/ -- Best André Rømcke

Re: [PHP-DEV] [RFC] Property write visibility

> > >> I agree that there is a use case for it, however I don't think the > proposed syntax `public:private` is intuitive. Maybe we can come up with > something better? > Would something closer to Swift be better? If so I expanded the RFC with that syntax option as well: class User { public

Re: [PHP-DEV] Re: [RFC] Readonly properties

> Yes, this is a possible alternative interpretation of the readonly concept. > The current proposal is closer to how Java final variables work, which never > allow reassignment, while your suggestion is closer to C# readonly, which > does allow reassigning in the constructor. > > I went with

Re: [PHP-DEV] Re: [RFC] Readonly properties

> > It's okay to vote against this if cloning is a deal breaker. In that case > > I'll probably either work on cloning before re-proposing this, or pivot to > > asymmetric visibility -- it's not my first preference, but it may be the > > more pragmatic choice. Cloning is definitely the weak point