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

> > On 02 Feb 2015, at 17:35 , Derick Rethans 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 h

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

On 09 Feb 2015, at 16:04 , Sebastian Bergmann 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 the RFC. He

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 con

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 wrote: > > Congratulations Anthony, and to Andrea for her initial proposal. > > Fi

[PHP-DEV] [RFC] Property write visibility

PHP's 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

ble: 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 p

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 e

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 s

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, thank

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] 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 o

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 th

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

> On Mar 17, 2015, at 18:04 , Leigh wrote: > > On 17 March 2015 at 08:37, Lester Caine 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 extract just what has now been

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

On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs wrote: > > > On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT > wrote: > >> 2011/12/27 Ilia Alshanetsky : >> > The change is inside 5.4 version which adjust breaks BC. >> >> I don't follow you here Ilia. >> >> As per https://wiki.php.net/rfc/release

Re: [PHP-DEV] 5.4.0 rc6 and release

On Fri, Jan 20, 2012 at 1:43 AM, Clint Byrum 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? > > > http://gcov.php.net/vi

Re: [PHP-DEV] 5.4.0 rc6 and release

On Tue, Mar 27, 2012 at 8:45 AM, Pierre Joye wrote: > hi, > hi, > > On Tue, Mar 27, 2012 at 8:38 AM, Clint Byrum 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 > > than needing to wait fo

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

On 7/16/12 5:29 PM, "Nikita Popov" wrote: >On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard >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 >> >> With my syntax: >> p

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

On 7/20/12 2:33 AM, "Anthony Ferrara" 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 compatibili

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

On 7/23/12 12:38 PM, "Amaury Bouchard" mailto:ama...@amaury.net>> wrote: 2012/7/23 André Rømcke mailto: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; } And when

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 mailto:kris.cr...@gmail.com>> wrote: On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara mailto:ircmax...@gmail.com>>wrote: Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass mailto:sv_for...@fmethod.com>>

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 = (Interface

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

On Oct 8, 2012, at 10:07 PM, Denis Portnov wrote: > 08.10.2012 15:52, Clint Priest пишет: >> public $Hours { >> get { return $this->Seconds / 3600; } >> set { $this->Seconds = $value; } >> isset { return >> isset($t

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

On Oct 11, 2012, at 4:59 AM, Clint Priest 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 readable

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`, or `immutable` for

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 all possible, as it > wou

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 would be that something l

Re: [PHP-DEV] Final properties

On 14. apr. 2016, at 11.47, Lester Caine 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 very little gain

Re: [PHP-DEV] Final properties

> On 16 Apr 2016, at 11:19 , Lester Caine 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. >>>> >>>> '

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); >> opcache_set($key, $value); >>

[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 leading

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

On Feb 18, 2013, at 23:03 , Christopher Jones 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 today's > semi-hum

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

On Feb 20, 2013, at 11:19 , Sebastian Krebs wrote: > 2013/2/20 Klaus Ufo > >> 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 : >> >> - no

Re: [PHP-DEV] Wake up

On Sep 11, 2013, at 15:52 , Terence Copestake 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 PHP into a professional >

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

Re: [PHP-DEV] Type hinting

Hi Lukas! On Wed, Jun 9, 2010 at 12:08 PM, Lukas Kahwe Smith wrote: > > 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 t

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

On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine 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 > prefer

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On Mon, Nov 1, 2010 at 9:47 PM, Felipe Pena wrote: > 2010/11/1 Richard Lynch > > > 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 please change the

Re: [PHP-DEV] Hold off 5.4

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

Re: [PHP-DEV] Hold off 5.4

On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke wrote: > On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans wrote: > >> On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote: >> >> > On 2010-11-23, Derick Rethans wrote: >> > > On Mon, 22 Nov 2010, Felipe Pe

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

On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT wrote: > 2010/11/30 Kalle Sommer Nielsen : > > Hi > > > > 2010/11/30 Patrick ALLAERT : > >> With this patch, something looks inconsistent to me: > >> Both properties and methods have a visibility > >> (public|protected|private) and a keyword: "var"

Re: [PHP-DEV] Re: [PATCH] Bug #49852 & Bug #53065 - Adding spl_autoload_case_sensitivity()

Wouldn't it be better to join forces with the SplClassLoader proposal[1]? A C implementation of PSR-0 has been prpoposed [2] as well, and would be nice to get something like that into 5.next However for your imminent performance needs, you should be aware that an hash map based autoloaders can be

Re: [PHP-DEV] Extensions to traits

On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt wrote: > 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: > > http://wiki.php.net/rfc/traitsmodifications > > I thi

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

On Wed, Aug 10, 2011 at 10:16 PM, Kalle Sommer Nielsen wrote: > Hi Sebastian > > 2011/8/10 Sebastian Krebs : > > 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" [1]. As far as I > can > > see its a

[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 C

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 f

Re: [PHP-DEV] SplClassLoader

On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei wrote: > 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(..., SplClassLoader::SILENT); > 2. Have

Re: [PHP-DEV] SplClassLoader

On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote: > 2011/10/26 André Rømcke : > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < > > guilhermebla...@gmail.com> wrote: > > > >> Hi internals, > >> > >> For all those intereste

Re: [PHP-DEV] SplClassLoader

scussion moot, making sure more people will standardize around PSR-0 ** making sure there is a autoloader in php that follows a convention that people actually use, and further standardized how such a basic thing is done in php projects in the wild. > > > > On Thu, Nov 3, 2011

Re: [PHP-DEV] SplClassLoader

With the point to being included in /ext/spl/; is to give a sense of > > "justification" of this standard and a base in which to push forward. > > It's also giving existing lib vendors to easily switch to a well-built > > autoloading mechanism bundled with PHP rath

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 > > 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* return null? >

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

ainly change, but I want to provide the most > options for the best 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 > >> > From: Will Fitch [

[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 ( https://wiki.php.net/rfc/releaseproc

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

On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans 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] 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 compiler doesn't pro

Re: [PHP-DEV] HYBRID VM

> On 10 May 2017, at 10:53, "li...@rhsoft.net" wrote: > > > Am 10.05.2017 um 08:21 schrieb André Rømcke: >>> On 5 May 2017, at 22:06, Dmitry Stogov wrote: >>> >>> It provides comparabele improvement on smal benchmarks, without degrada

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 ; >> St

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% > slow