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 hinting behavior per file scope, so, just to try strict >> type hinting in a big project, people will have to change every single PHP >> file. declare() might not be beautiful, but it is pragmatic as it already exists. As for full project switch, can’t we easily do a followup RFC with a command line flag/ini setting to run unit tests in strict mode for instance? > > THis is why I believe it makes more sense to have this switch on the > callee side, instead of on the calling side. I’m not sure I see why that would make more sense. On the callee side what you get is strictly what you asked for anyway, no matter what mode on the calling side. This is the true beauty of what Andrea has come up with here, allowing weak PHP like forgiveness to co-exists with opt in for strict behavior. Best, André
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. Hence my vote. It is, from your point of view, the provider of a API, strictly enforced: you’ll get exactly the type you asked for. The current RFC is clever in this way, it makes sure the library author gets the types they want, and the user of it can freely choose mode as he see fit and is skilled for. I’m sure we can easily do a followup RFC to add a ini setting/argument, to be able to run unit test in strict mode by default, unless for instance code specifically declares strict_types=0. Which I guess would be great for PHPUnit runs to really get full control over what kind of types we use throughout our code. So to summarize: This RFC gets you a ton of a lot closer to the strictness you (and I), would like to use for at least our test runs.. Best, André
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 my real wish does not get fully > addressed with a "YES", leading me to switch my vote. > I really wanted to expose the motivation of my change here, so everyone is > aware that I do love strict typing, and I really want this in for PHP, but > not in this RFC way. To me this is the best compromise that can be made here. In case of boolean: if you specify boolean, boolean is what you get, no matter what user of your library do. So you are in full control here! You are not, however, in control over other peoples code, which you shouldn’t be anyway. After all you didn’t write it. The RFC quite elegantly allows both strict and weak camps to be pleased, bikeshedding on declare() aside. So it is a pity people in those camps don’t see that, as this is rather overdue* feature. Best, André * It is a feature that allows us all to write more reliable, shorter, and better self documented code. We got it for all other types up until now, only scalars missing.
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. > > Finally, we have scalar type hints in PHP. > > PHP 7 is going to be a real game changer! > > Chris > >> On 16 Mar 2015, at 9:03 pm, Anthony Ferrara wrote: >> >> All, >> >> Voting has been closed on the scalar type declarations v0.5 RFC: >> >> https://wiki.php.net/rfc/scalar_type_hints_v5 >> >> At a final score of 108:48, it has been accepted for PHP 7. >> >> Thank you. >> >> Anthony >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
[PHP-DEV] [RFC] Property write visibility
Good morning Internals, I'd like to start discussion on a new RFC proposing a way to be able to (optionally) specify property write visibility, separate from read: https://wiki.php.net/rfc/property_write_visibility This enables readonly, write-only and immutable like semantics for 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
man. 29. jun. 2020 kl. 12:06 skrev Deleu : > Are there any other languages that have a similar syntax? Has any other language syntax been considered The only one I could find that matches is Swift: public private(set) var numberOfEdits = 0 https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html#ID18 Beyond that there are some notable related examples: C# public readonly Color Black = new Color(0, 0, 0); The semantics of readonly is closer to what we refer to as immutable here: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#readonly-fields If you want other semantics in C# you'll need to resort to Accessors: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#accessors Rust: // This field can be read (but not written) by super. #[readonly] pub(super) readable: 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 private(set) int $id;
public protected(set) string $name;
public function __construct(int $id, string $name) {
$this->id = $id;
$this->name = $name;
}}
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 explored* in this direction, however if we go that way first we'll likely end up with any reflection code having to deal with attributes and understand their underlying visibility semantics. If we rather go this route of first introducing the concept of disconnected visibility. The reflection API is far clearer / understandable, more future proof, and adding the attributes as immediate syntax sugar followup is far more straightforward. * initial explorative draft rfc: https://wiki.php.net/rfc/readonly_and_immutable_properties
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 set), pass it outside the class and then modify it. This was copied from some other source actually. I’m all for staying as close as possible to how the language behaves on this, changing it should be different RFC. Should I just remove this section or do you have suggestions for what we need to specify when it comes references?
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, thanks! So instead of : "Attempting to pass a property value outside of allowed writable scope as a reference, results in an error." Instead maybe: "Assigning variable by reference is subject to write visibility, meaning ''$x =& $this->prop'' is considered a write of $this->prop, not a read" ?
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 > accessors. We should take enough time to consider these > alternatives/extensions as well, to ensure that we don't end up with > multiple distinct and possibly incompatible mechanisms. We don't have that > time before PHP 8.0 feature freeze. > I've updated the RFC to rather aim for 8.1, I fully agree this should in any form be made asure to align well with the related requests. Larrye's email is a good example of what kind the language might look like when several such features are potentially accepted in the future. May I propose that some of us interested in this do a short call over the summer on this topic to see if we can align on direction?
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 of this > > proposal. > > I already went through the clone-arguments mental exercise in my earlier > analysis, and the code > it produces is totally disgusting. :-) clone-with is a considerably better > approach if you're starting > from readonly. (It's also better if you start from asymmetric visibility, > although that version needs > a clone-help feature far less.) Internals have been here before, it's a recurring problem in PHP that fundamentally missing features are voted down because people want other complementary features first. read only has been voted down by people rather wanting type properties first, or rather wanted assessors first. And then in turn accessors multiple times were voted down by the other 2 camps. But these features are interconnected and need to be done step by step, during the process things won't be perfect either way, Now we have read only vs clone with vs accessors vs ... IMO problem caused by no clear roadmap / vision of the project that people can be united behind. -- Anyway, even though I tried to push for asymmetric visibility last year I'd gladly vote +1 on this. It's not perfect, but it's the right direction, and there are multiple starting points to get there. This solves 80-90% of the use cases out there for read only properties, which is a very good start. -- Nikita: Probably a small thing, but the only detail I'm unsure of is why focus on write-once logic? Why not aim for aligning it with a future *:init visibility, where I would think the property in PHP should be writable in __construct(), __destruct() and __clone(). This won't solve the separate clone with feature request. But it would make it more flexible and language design wise would set it up for possible asymmetric visibility + init option later. For now it would at least allow setting default values on the property, for instance if argument to constructor is not 1 to 1 with property type/value and needs some light logic in __construct to determine if property should be set to something else then default. But again, don't see a blocker here in current RFC, as it starts out with a narrow scope of read only, and this can be widened later. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
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 the current proposal, because it integrates nicely with the > initialization concept introduced by typed properties. At the time, we also > had lots of discussions about how typed property initialization should work, > and requiring that all typed properties be initialized by the end of the > constructor was one of the contenders. However, we ultimately decided against > such an approach, because it does not integrate well with other aspects of > the language. In particular we need to have the ability to initialize an > object while bypassing the constructor, and we don't have the ability to > determine initialization statically, so an uninitialized state would have > been required in any case. > > If we had gone with that alternative initialization model at the time, then > we would also use the same one for readonly properties. But that's not how > things work now. Doing something like this now would require introducing an > entirely new scoping concept. This brings up awkward questions like: How do > you bind a closure to this new "initialization scope"? Closure rebinding is a > common way to bypass visibility restrictions. What happens if you want to > call a helper method to do the initialization, does that still count as > initialization scope? What if you call $object->__construct() directly, will > that allow changing properties? > > The current proposal tries to provide a simple, absolute guarantee: Once > initialized, the property will never change again. I think that makes the > feature easy to understand and reason about. Thanks for the detailed explanation, I'm sold! And it seems it can evolve further once complementary features are introduced. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
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 agreed for that area of >> type hinting. A base that can be used to review some of the other >> discussions to put that to bed. Others might appreciate a similar >> summary of the 'type_error' mode as well? As a base for the >> documentation on the user manual updates? > > > Not sure what is "difficult to extract" > > https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks > > It's all right there... That part answers what has been agreed (or rather accepted), but not who the weak mode is for, and why. Tried to sum that up last week when there was still discussions on this: http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective TL;DR; weak mode is for api consumers, aka normal php users, while strict is for the actual target users of this features: api (library/framework) creators. Post also argues for why Zeev's adjustments to weak sth handling should still be done, as well as arguing for disallowing/fixing closure hint in strict mode. ar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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/releaseprocess:
>> * "Backward compatibility must be respected with the same major
>> releases, for example from 5.2 to 5.6."
>> * Going from x.y.z to x.y+1.z, it is ok to break *binary*
>> compatibility but "Backward compatibility must be kept".
>>
>> However:
>>
>> new DateTime("@{$_SERVER['REQUEST_TIME']}");
>>
>> works in 5.3 but not in 5.4.
>> AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
>> exotic thing.
>> For sure, the fix is easy, but that is not the point, it *will*
>> actually break applications.
>>
>> Did I miss something?
>
>
> I think that he is referring to that we already break BC with 5.4
> (removing magic_quotes, register_globals, break/continue
> $var, allow_call_time_pass_reference, some deprecated session_ functions,
> safe_mode, etc. for a complete list see
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
> )
>
These are mostly removal of features, and most of these have been
deprecated for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)
>
> However I tend to agree with you, that this BC break isn't really worth
> it, we can see that there are common apps stumbling across this change, and
> albeit the new behavior can be useful for many people, they wouldn't really
> mind if we add this as a new variable imo.
>
Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable called
REQUEST_TIME_FLOAT.
+1
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/viewer.php?version=PHP_5_4 > > > > Most of them appear so, I'll go through them again to be sure and > > encourage others to do so too and raise red flags if somebody sees > > something bad there. > > Unfortunately, some tests are environment-dependent or otherwise have > > subtle dependencies or structure that make them work on one system and > > fail on another not because of the bug in PHP but because of the test > > itself. So, I have 0 fails on my Linux build but 6 fails on my Mac > > build. Other times some systems may not support some capability, use old > > version of the library, etc. and the test may not account for that. > > These tests should be skipped or marked as XFAIL on platforms they are > known to fail on. Better to have no test than one that cannot be relied > upon. All supported platforms should pass with 0 fails. These intentional > skips should have open bugs that are documented in the test code so that > a developer can find out why this test was disabled when trying to make > a change covered by the test. > > > > > I do not think it is practical to postpone release until we solve all of > > such problems, since this being volunteer-driven open-source project > > this means not having any release schedule at all. I prefer having the > > schedule even if that means we'd have to release with some known > > deficiencies. > > > > Its pretty bad actually. For all of PHP's success, this is something that > continues to baffle me, and many others I have talked to who are charged > with measuring quality and with patching systems in a timely manner. How > better to document unreliable tests than to skip them with something like > "SKIPPED - known to fail on Mac". > > Its precisely this unreliability that forced me to take a conservative > approach for Ubuntu 12.04 and recommend to the community that we ship > 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but > even if all the tests pass on the machine we run the test suite on, > how can we be sure they won't fail in another time zone, or in some > other strange configuration? > Given that 12.04 beta2 will be out on Thursday, and the unit tests where fixed before shipping 5.4 (I naively assume), is this in or out? ref: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 With beta freeze on march 22 I guess the "mistake" of bundeling 5.3 instead of 5.4 is already made, and we will have to live with that for the next 2 years for prod, and the next 7 months for dev. > > > > - There was this problem with 5.3.7 and the crypt() bug. Has there been > > > some improvement in the process of handling test failures? For example > > > mark expected failures as expected failures, and fix the tests or the > > > code? Or are the failing tests "stable" since month and all of them are > > > minor problems? > > > > Yes, there was work done on these. Most of those were fixed, but few > > still remain, especially across various environments (i.e. test may be > > fine on some but not others). I of course am all for fixing that further > > and welcome any help on that. > > > > > - There have been 319 unique failed tests in RC5, reported by user > > > tests. Is someone looking into them and trying to classify and/or fix > them? > > > http://qa.php.net/reports/ > > > > Non-reproducible failures usually mean the problem is with the test > > itself, or with the difference of expectations in the test and local > > environment, not with PHP. It may still be PHP problem, of course, so > > the person running the test should check it out and submit a bug if > > appropriate and if it's bad enough, also send a message to this list. > > > > > All in all the number of test failures still feels very high, I would > be > > > interested in your opinion. Is this "normal" for big projects like > this? > > > > I do think it should be reduced, however if the choice is between > > waiting forever and have release with some bugs, I think it is practical > > to choose the latter. Of course, if we discover a major problem that > > makes PHP unusable or seriously impacts many PHP users, it will be dealt > > with immediately, and had been so in the past, but otherwise we have to > > work within the realities of a big project with limited resources and > > realize that while we strive for 0 bugs in every release, it may never > > be possible. > > All software will have bugs. The test suite, however, should reflect > the bits of code that you know work reliably... not the bits of code > you know work most of the time. > > The fact that its all being running regularly is a fantastic improvement. > I'd like to see a commitment to getting 100% pass/xfail/skip
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 for the good and generous folks at the hardened > > PHP project to catch up. > > I disagree. The lesson here is that the Ubuntu's security team should > have discussed with us to see what are actually their worries instead > of not following what is actually a good move for everyone. > Why? It is common practice to avoid .0 releases, including those from PHP :) Actually, this is not a bad thing at all. It makes sure lots of PHP projects and Frameworks stays on 5.3 as a common base for the next 1-3 years, introp wise that is a good thing. And those that want the extra 5.4 stuff can get it somehow anyway, and as part of the distro in 7 months. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
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:
>> public:private $a; (read it aloud "public reading, private
>>writing")
>>
>> With the existing RFC:
>> public $a {
>> private set { $this->a = $value; }
>> }
>>
>> Which one is better? Why should I write code for that?
>>
>> If you read the existing RFC, you'll see that all examples involve a
>> specific case: when you have a "fake" attribute, which manipulates date
>> stored in other attributes. The given example is an $Hours attributes,
>>which
>> is calculated from the private $Seconds attribute.
>> Again, it could be very useful. But it doesn't work all the time.
>
>You can also just write public $a { get; private set; }. I see that
>the syntax is a bit more verbose, but I definitely prefer it to the
>obscure public:private notation. With the getters/setters the meaning
>is somewhat clear (public get, private set), with the colon notation
>it isn't really clear.
He probably went with that syntax to retain full flexibility.
In our case (eZ), we almost exclusively use magic getters and setters to
make properties read only. So just like Matthew and others writing api's
we would really appreciate a way to be able to defined read only
properties, without the overhead of function calls.
I think these two proposals can be synced up, what if:
public readonly $a;
Is shorthand for:
public $a { get; protected set; }
And when no function is defined, no function overhead is added.
>
>Nikita
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 compatibility to some extent with the >legacy >API. > >3. We want the ability to simplify the standard library. > >So here's my thought. Make $var->method($arg1, $arg2) on scalar types a >"short-hand" for \php\method($var, $arg1, $arg2). > >So we re-organize the base API into \php, cut down to just the base >methods. So: > >\php\length() > - If array, count(), else strlen() >\php\substr() > - Treat as string always >\php\replace() > - Normal str_replace semantics >\php\split() > - Treat as string always >\php\join() > - Treat as array always >\php\shuffle() > - If array, array_shuffle, otherwise str_shuffle >\php\pos() > - if array, array_search(), else strpos() >\php\reverse() > - if array, array_reverse(), else strrev() >\php\merge() > - If array, array_merge, if not, string concat >\php\type() > - return type information about variable >etc > >Now, those that are clearly type specific, or are too specialized to >belong >on a "global" type, would then be sub-namespaced: > >\php\array\map() >\php\array\keys() >\php\math\min() >\php\math\max() >\php\math\round() >\php\string\number_format() >\php\string\chr() >\php\string\ord() >etc. I think I like it, as it is close to how I would proposed it before: Provide optional PHP6 type classes* and provide an fully oop api on them in line with other languages. But this is close enough, as it will give you possibility to explore available methods in IDE if you hint on type. And you avoid the total chaos you would get if new functions are introduced in global namespace. It doesn't automatically gives me strict type hinting possibilities in api's, but one step at a time.. :P One nitpic though: method names should be consistently formatted, and most methods in PHP (5+: DateTime, PDO, XML ...) and user land oop libraries is often ->lowerCamelCase(). * This is where that proposal is usually shoot down, at least it was by Rasmus and other internals. Argument being the added cost of objects, but is this the case in other implementations of PHP like HPHP? > >The benefit here, is that user types can implement the same "core" >interface and be used polymorphically with the core types (for at least >the >base API). So then, countable() would disappear. > >Now, there's one more thing that needs to happen. If you call >\php\length($var) directly (procedurally, not as a method call), we'd need >to check if $var is an object that implements ->length(), and if so, call >to that instead of an error. > >That's the base idea. It could be extended further to include true objects >for scalars, which would implement the rest of the core API. So, you could >do: > >(new \php\Array($array))->keys(); > >This would then assume standard object semantics for the "wrapped" type, >while at the same time losing the dynamic typing ability of the language >(but it's done on purpose here to keep the API clean). > >For BC, we'd need to modify zend_parse_parameters to extract the array >from >a wrapped array object, to keep BC code functioning correctly in either >case, but it should be pretty transparent to the user which is passed... > >Is it perfect? Absolutely not. But it tries to get around the BC breaks, >as >well as the dynamic typing issue that ints can be strings, and vise versa. > >Thoughts? > >Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 no function is defined, no function overhead is added.
Well, this code:
public read-only $a;
introduces a new keyword (that should be avoided when not absolutely necessary).
It's pretty easy to understand what it does (it's an attribute with public
access, but it's not writable), but you loose meanings (visibility).
read-only is already mentioned here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties
But I see now that it is defined as full read only, not even the class itself
can write to it, so ignore my code examples.
My point was just; we also have the need for public:protected / public:private
and would like to avoid the overhead of function calls, hence why I looked into
if there would be ways to sync the two proposals to improve possibility of
acceptance (ref feedback in thread).
Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not
straightforward.
More, should you write
public read-only $a;
or
public $a { get; private set; }
?
Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.
Another examples:
public read-only $a;
vs
public:const $a;
public $a { get; private set; }
vs
public:private $a;
public $a { get; protected set; }
vs
public:protected $a;
We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility information
shouldn't be distributed on several locations (before the attribute; sometimes
with a new "read-only" or "write-only" keyword; sometimes inside brackets,
before a new "get" or "set" keyword).
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>> wrote: Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean "casting" actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My point was that what I posted was the only way that I can see for the original proposal to be useful. Anthony Though I'm clearly in the minority on this, I for one think this proposal does have more merit than is being argued. There seems to be general agreement all around that this would provide a benefit as it pertains to code readability-- Not just by humans, but theoretically by doc/etc parsers as well. This is where we get into arbitrary, subjective territory. To me, that benefit in and of itself is sufficient to warrant this feature. To many of you, it is not enough. The tie-breaker for me is the fact that, though the benefits are modest, there's really no noticeable cost, either. The argument seems to, essentially, break down as follows: "This feature isn't worth our time." "Yes, it is!" "No, it isn't." Every feature has a cost, even if that cost is just maintaining the code. Doing language changes for minority use cases, which already have sensible solutions, doesn't make much sense. 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) $container->service` is completely out of question. It looks like a cast, but wouldn't actually do a cast. * Same is to be said about `InterfaceName $foo = $container->service`. This syntax implies that the $foo variable will always be of type InterfaceName, even if it is later reassigned. It's not a sensible syntax for a one time validation * The other three syntaxes that were mentioned were just as unclear. E.g. `$foo = $container->service as InterfaceName` again looks like a strange cast syntax and `$foo = $container->service is InterfaceName` looks like the assignment should evaluate to a boolean (i.e. `is` is some kind of `instanceof`). good points On the other hand, the current ways of accomplishing the same goal are well-established and easy to understand: * Using a docblock: /** @var $foo IntefaceName **/ * Using an assertion: assert($foo instanceof InterfaceName). I think that the assertion is a rather concise and clear way to do this. It is much more obvious than some new and obscure `$foo = (InterfaceName $container->service)` syntax. @Stan: If you make sure you configure your container to injection dependencies and in case of lazy loading inject factories with type hinting in doc istead of passing the [dependency injection] container around as a registry, then you almost don't get this problem at all, and you will avoid introducing container awareness/dependency in your architecture. Only place you will have this original problem though is in the code that gets the first dependency of the execution, but even then you can have Container interface for the most common root dependencies. Like: https://github.com/ezsystems/ezp-next/blob/master/eZ/Publish/API/Container.php Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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) $container->service` is > completely out of question. It looks like a cast, but wouldn't > actually do a cast. > * Same is to be said about `InterfaceName $foo = > $container->service`. This syntax implies that the $foo variable will > always be of type InterfaceName, even if it is later reassigned. It's > not a sensible syntax for a one time validation > * The other three syntaxes that were mentioned were just as unclear. > E.g. `$foo = $container->service as InterfaceName` again looks like a > strange cast syntax and `$foo = $container->service is InterfaceName` > looks like the assignment should evaluate to a boolean (i.e. `is` is > some kind of `instanceof`). good points In addition, the root cause that triggered this proposal in the first place: serve container / object registry doc issue, is kind of moot, ref bellow. > > On the other hand, the current ways of accomplishing the same goal are > well-established and easy to understand: > > * Using a docblock: /** @var $foo IntefaceName **/ > * Using an assertion: assert($foo instanceof InterfaceName). > > I think that the assertion is a rather concise and clear way to do > this. It is much more obvious than some new and obscure `$foo = > (InterfaceName $container->service)` syntax. To expand on that, @Stan: If you make sure you configure your container to injection dependencies (and in case of lazy loading, inject factories* with type hinting in doc) instead of passing the [dependency injection] container around as a registry, then you almost don't get this problem at all, and you will avoid introducing container awareness/dependency in your architecture. Only place you will have this original problem though is in the code that gets the first dependency of the execution, like in index.php for instance, but even then you can have Container interface for the most common root dependencies. In the cases that doesn't fit, you should plainly use the doc block referred to by Nikita, it is already supported by IDE's and won't need additional 3 years to get support. * As alternatives to factories with or without container knowledge, there is one alternative that some containers support: Proxy objects: container generates proxy objects whenever you want dependencies to be lazy loaded, they have container awareness, but this becomes 100% transparent to your code, but it probably adds some overhead. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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($this->Seconds); }
>> unset {
>> unset($this->Seconds); }
>> }
>
>
> Hi Clint,
>
> I've noticed some magic variable '$value' is introduced. And except for
> superglobals I guess there is no such thing in PHP, so it looks bit puzzling
> to me. I'd suggest on of the following:
>
> - variable for value has the same name as property
>public $Hours {
>set { $this->Seconds = $Hours * 3600; }
>}
>
> - magic constant
>public $Hours {
>set { $this->Seconds = __VALUE__ * 3600; }
>}
>
> - setter resambles setter method, wich also allows typehinting
>public $Hours {
>set ($value) { $this->Seconds = $value * 3600; }
>}
>
>public $Hours {
>set (DateTime $dateTime) { $this->Seconds = $dateTime->getTimestamp();
> }
>}
If this function inspired syntax is used, then it kind of hints the possibility
of future parameter overloading, like:
public $Hours {
set ( DateTime $dateTime ) { $this->Seconds = $dateTime->getTimestamp(); }
set ( int $hours ) { $this->Seconds = $hours*60*60; }
}
So for me +1 on that syntax, or using/future-proofing for the syntax from C#:
public DateTime $Hours {
set { $this->Seconds = $value->getTimestamp(); }
}
However the example doesn't make much sense (hours being datetime).
>
> - or at least have it in same format as superglobals
>public $Hours {
>set { $this->Seconds = $_VALUE * 3600; }
>}
>
> What do you think?
>
> Thanks
> Denis
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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 and understandable than:
>
> public $hours {
>get() { ... }
>private final set($value) { ... }
> }
>
> The latter implies that it can be "set" within the right context (internally
> to the class), which is precisely the opposite of what is desired (read only).
If it can be used on normal properties as well (w/o the overhead of function
calls) then: +1
Otherwise it would not be consistent to introduce it.
On the topic of consistency, could not see any other keyword in php that uses
hyphen in it.
>
> From: Jazzer Dane [mailto:tbprogram...@gmail.com]
> Sent: Wednesday, October 10, 2012 9:18 PM
> To: Clint Priest
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
>
> This all sounds about right.
>
> In regards to #4 - read-only/write-only:
> I think that, from a "pretty syntax" point of view, private final set() {}
> and private final get() {} are definitely our best bets. But... from a
> logical point of view, I prefer read-only/write-only.
>
> private final get() {} is technically saying it will always return null.
> private final set() {} is technically saying that setting doesn't do anything
> - but it still works.
>
> But I don't see any sane scenario where someone would want to do the above.
> Therefore, it may just be best to use them in place of the currently proposed
> read-only/write-only.
> On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest
> mailto:cpri...@zerocue.com>> wrote:
> Okay, I would like this to be the last time there are revisions to this RFC.
>
> To sum up the last few days of conversations, I have these down as points of
> contention:
>
> 1. Accessor functions should not be present on the object and callable
> directly, for example, $o->__getHours() should not be allowed.
> 2. Preferred syntax for accessors should be "public set($value) { ... }"
> with no "magic" $value (with possible type hinting)
> 3. Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing most everyone.
> 4. read-only / write-only keywords, keep them or get rid of them? There is
> no directly suitable replacement but I believe a private final set() { } will
> take care of it, even though it much more verbose.
> 5. Error handling for thrown exceptions should be made more appropriate for
> accessors
> 6. The "truth" of reflection. Should it reveal details internal to how PHP
> works on the inside or should it reflect the way PHP presents it as options?
>
> Did I miss anything?
>
>
> I will come up with some way for people to vote on the issues at hand and we
> can cast our votes and be done with it, then I will finish the project and
> get it out the door.
>
> -Clint
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 these properties? > > I have the same sentiment you have, that "final" would be confusing > and "immutable" would be better. But it's also confusing to have > the same concept another language has under a different name. Hm. > > I think I tend towards "immutable". I tend to as well. However as noted on misc C# pages* about immutable, this can be slightly confusing also; If the variable is ArrayAccess you will still be able to call offsetSet on it. “readonly"** would be another option, even if some might assume class can always write to it. Since there is no perfect name, maybe let the name be open for vote as part of RFC? To avoid to much focus on the naming during discussions/specification? * http://stackoverflow.com/a/6849164 ** https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx
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 > would also subsume this question quite nicely.) > And by Properties RFC you mean Property Accessors Syntax RFC right? https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 like Property Accessors Syntax* is re opened and updated? >From user land main motivation to support this and typed properties is to be >allowed to type hint and make properties readonly to simplify use cases for >entities and value objects, using properties, and not having to resort to >magic methods which tends to become slow(er) and messy. For how this is >archived, not violating LSP, and making sure the language and internals are >kept as consistent as possible would be high up there as reasoning to pick >approach * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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. > > 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a > value from some OS's will be a floating point number[...] It wasn't really the example I intended to point to, it does not represent the cases me and others refer to. I was linking to it for the possible solution to handle type and immutability. Examples for the latter: https://en.m.wikipedia.org/wiki/Value_object > > I don't see how the idea of 'optimizing' the compiled code has any > bearing on handling a 'typed property' when one has to have an object to > contain even the simple of type information? What is this regarding? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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. >>>> >>>> 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a >>>> value from some OS's will be a floating point number[...] >> It wasn't really the example I intended to point to, it does not represent >> the cases me and others refer to. I was linking to it for the possible >> solution to handle type and immutability. >> >> Examples for the latter: >> https://en.m.wikipedia.org/wiki/Value_object > > Working from and SQL base ... the schema provides both validation beyond > simply 'int' or 'float' and 'read only' all simply extensions to the > basic variable returned. readonly in this case is more about application logic and not db logic. If you want to take a swing at it a more relevant example would be to just ask everyone to use get() and in case of writable properties set($value) and stop asking about expanding the language to cover the use cases and hence simplify use. > >>>> I don't see how the idea of 'optimizing' the compiled code has any >>>> bearing on handling a 'typed property' when one has to have an object to >>>> contain even the simple of type information? >> >> What is this regarding? > > People have been claiming they need to be able to identify the type in > order to optimize the compiled code. […..] True, for me is more about the benefits in user land. There are lots of cases where those claims won’t be true, as in scalars changing types. So even with type hints it will still need some sort of tracing JIT compiler that uses type info from todays runtime to machine compile hot spots, the type hints will merely make sure the type is somewhat more predictable. And even then you’ll need to account for possible type misses and sometimes have to pop back to interpreter effectively loosing time. All of which Javascript has done for years and continue on to do, afaik latests on that is https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ But even if discussing that would be neat, and it’s relevance since there have been discussions on using LLVM with PHP over the years. This thread is not really about type, it’s about readonly properties or whatever you would like to call them :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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); >> >> Is planned in PHP 7.1? >> > > This was identified as a difference between APC and OpCache when the latter > was added to core several releases ago, and that's exactly why APCu exists: > http://php.net/apcu > > There's not really a huge connection between opcode caching and optimization > (OpCache) and shared memory data caches (APCu, memcached, etc), so I don't > think there's any particular logic to calling such functions "opcache". > > So I guess the question becomes: "should APCu be made part of core?" I'm not > aware of anyone having proposed that, so don't know if there are strong > feelings for or against such a thing. As long as it’s cache is not shared among processes, rather not. A user cache needs to be able to be shared between cli and web process to cover the main use cases imo.
[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 the teams involved in developing and maintaining eZ Publish and now eZ Platform. Open source CMS solutions that has PHP roots since it’s start around 2000. I have been voting member of FIG and member of this mailing lists for several years, and hope to find a viable solution for everyone. For now please grant my wiki user edit access, and if any core member would have interest in mentoring me on this, that would be great. Username: andrerom Best regards, André R.
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-humorous name suggestion: "Cajun". It sounds roughly like the > English pronunciation of "caching" > > Sadly it's not as nicely self-documenting as "opcache". > opcache is fine, its better that it's self describing then exiting. Cause then you don't have to google it to figure out what it is every time, like T_PAAMAYIM_NEKUDOTAYIM :P So if you really have to make a name for it, keep it self describing, like: OpsiCache Other then already being a used name, ops(i) is the word you would say in some languages when you realize you have done a mistake :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 more global functions >> > > Just to throw that in: Even if you pack them into namespaces they will > still remain global functions. They simply don't live in the root-namespace > anymore. +1 So why not avoiding this by adding it as methods of the scalar variable instead, aka autoboxing. This would allow the new api to be closer to what people are used to from other languages, needs far less typing and IDE autocomplete of available functions pr type with "->". More recent example by Nikita Popov, see unit tests of the project for examples: https://github.com/nikic/scalar_objects/blob/master/tests/string.phpt#L17 > > >> - separation of concerns >> - backward compatibility > > - work can be done progressively >> - easy to add user-defined functions (using php namespaces) >> - we could provide a \str\utf8 namespace >> >> This is just an idea. I don't know what is your vision for a next PHP 6. >> >> KH >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > github.com/KingCrunch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 > programming tool/environment, complete with all bells and whistles. With > everyone wanting something different and having different ideas on who the > target users are, what PHP's responsibilities and concerns should be, etc., > it's going to be the classic struggle of trying to be everything for > everybody all at once. Won't solve the perceived lack of vision, but the conflict could potentially be solved by modeling php language standardization after how they do it at Ecma, w3c or iso. For instance: Let php-internals be as is, Internal stuff in PHP engine and announcements of rfc's for it, but move out the organization of standardizing the language. 1. The people involved in standardization should be representatives of the different implementations of PHP language. 2. Accepting changes to the language would requirer that at least one implementation have it working behind a compile/runtime flag* 3. Language Tests should be shared and be part of the standardization effort 4. The PHP language standardization body should always allow some variation on how much a implementation helps the user by default # Example: Argument and return type hinting** Specification on this can define two modes of operation: 1. Fatal error on wrong type 2. Strict error on type conversion, and Fatal error on type conversion with data loss HPHP could then use mode 1 by default, while PHP uses 2 by default (and 2 with strict errors disabled in production). This was not intended as a flame, best regards André R. eZ Systems * For anyone involved in web development you might know how messy css vendor prefixes made the web, forcing them to be behind compile/runtime flags would avoid this ** Just an example, ignore the details please -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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. It is something that
> applications will frequently want to handle gracefully in order to
> provide useful error messages. A new error level is needed, as is an API
> / function to obtain the failed parameter names, desired type and passed
> type.
>
I personally don't get this error handling and weak type hinting discussion,
looks like a mix-up of type hints and input validation.
To me, type hints are a contract between an API and the consumer of the API,
reason being that it makes things a lot easier on the inside of that API
call and errors caused by misuse are caught early.
For those that don't want this contract, don't use it.. By default PHP will
behave just like you want, namely: type less.
But to me, that is not a good way for API's that are used by several
thousand developers that probably don't check the php doc every time they
use a function, and do something human; mistakes.
When PHP 5 added support for this, that made my day, even if it wasn't
complete.
It is one of the things that made PHP's OOP support a lot more on level with
other languages / platforms, and I think it is a strength that it behaves
like other platforms for those that want to use it.
So sorry, but I think Lukas' & Zeev's proposal is the wrong approach, it
will make this useless for the very people that wanted it in the first
place.
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do this intentionally, but in a large application
you might not have full oversight and can unintentionally pass variables of
wrong type or in wrong order causing issues to surface much later as there
are no strict type checks that would detect the mistake immediately while
developing).
--
One solution (if weak type hinting is really needed) is to go back to Ilia's
proposal for virtual types and for example extend it with "wint", "wbool",
"wstring", "wfloat" and similar (it could just as well be "~int", "int_w" or
"int_cast" for instance) for cases where you want to accept type by value.
This casting should be done with current type juggling rules for
consistency.
But adding cast support like this would make the whole catchable cast
error's discussion re appear. And those probably involves a lot more
overhead then handling such cases yourself inside your API functions using
exceptions, so I don't personally see any gain by this.
So to avoid that, I would say Derick's proposal to allow "function foo(
(int) $bar) { } // auto-cast to int" is superior as it will avoid that
discussion/issue, keep it simple & not be misunderstood as a means of input
validation.
- AR
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 this case > as > > consumer can do something strange as fetchById( true, 'foo' ) (Obviously > I'm > > not saying anyone would do this intentionally, but in a large application > > you might not have full oversight and can unintentionally pass variables > of > > wrong type or in wrong order causing issues to surface much later as > there > > are no strict type checks that would detect the mistake immediately while > > developing). > > > please read RFC's you comment on (well the following was added to the RFC 2 > or maybe even 3 weeks ago): > in your above example there would be data loss in the type cast and > therefore there would not be silent auto casting. > http://wiki.php.net/rfc/typecheckingstrictandweak I was assuming Option 1 for the example and the fact that E_STRICT like any other error would just be logged somehow in most systems, hence not stop the call from executing which would be an even bigger issue if it is an store() function. > anyway .. can we conclude this discussion? probably best if someone who is > more or less impartial would handle the call fore vote and figure out some > sensible way to let people vote on the various solutions that are proposed. +1
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 > preferred alternatives ... eaccelerator is still working fine now that it > has been upgraded to handle 5.3 ... although it would be nice to see some > more up to date comparisons. Although I suspect in reality, the combination > with database and other caching activity means that a straight comparison > may be a little meaningless? Change the database and the figures are going > to be different anyway ... so a straight comparison on non-database code > would be a little more practical. > +1. Being disabled by default was agreed on for "old 6.x" so should be for 5.4 as well. However I think there probably is a lot of possibilities for PHP if it was better integrated in the future (lets say "new 6.x"). To offer better autoload performance if you stick to PSR-0 for class autoloading for instance. Hence a future php version that has better persistent knowledge of classes used on the system so every class load doesn't result in a full require call with all its overhead on every request. And/Or a shared api / backend for shared persistent cache for stat calls, real path and parsed php structures, and anything else one might want to let persist between requests in the future. A discussion for another thread some other time off course. > -- > 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// > Firebird - http://www.firebirdsql.org/index.php > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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 token name to T_DOUBLE_COLON > > > so I don't have to hear about it constantly? > > > > > > Those that disagree don't do enough PHP support to know how often it > > > is > > > asked. it's worth it. > > > > -1 > > > > > Instead of renaming the token, I prefer to associate a literal string to > each token, to have a legible error message, without the T_ being shown. > > For example, we could use in the Bison grammar file: > %token T_PAAMAYIM_NEKUDOTAYIM "::" > > So that the error message become: > > $ sapi/cli/php -r '::' > Parse error: syntax error, unexpected :: in Command line code on line 1 > > Instead of the known "unexpected T_PAAMAYIM_NEKUDOTAYIM" one. > +1 on implementing this so we don't have to wait for lemon. While knowing how to use a search engine is good, it's even better to not have to and save the time spent on it. > -- > Regards, > Felipe Pena >
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
> > > > aka class int {}
> > >
> > > Yeah, there is a slight hint of a BC break in case you have a class
> > > named "int" or "float" etc. But there is:
> > > http://uk.php.net/manual/en/userlandnaming.tips.php
> > >
> > > Perhaps we can reduce the current list of classes:
> > > int, integer, real, double, string, binary, scalar, array, object,
> > > bool, boolean
> > > to what the manual uses though (for prototypes):
> > > int, float, string, binary, scalar, array, object, bool
> > > (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
> >
> > Sorry, but this is actually a pretty grave BC break.
> >
> > Currently, you can do the following:
> >
> > namespace Foo\Validator;
> >
> > class Int {}
>
> During our namespace discussion, this is exactly what I warned about. In
> order to make use of namespaces, you need to have atleast two "elements"
> in your class names otherwise we can still never introduce a new class.
> But that was not listened too.
>
> > As Sebastian noted, it seems this should be addressed with the new
> > lexer; I'd argue that if the current type hinting must introduce new
> > keywords, it should wait until the new lexer is in place in order to
> > insulate end-users from such changes.
>
> The new lexer however, is a slower; so not a viable solution right now.
>
> > With a defined release process, *everyone* knows what must be done, by
> > when, making the process more transparent and *gasp* democratic.
>
> Well, I don't think we've ever been democratic. I probably think
> that that wouldn't even work. Also, I think an alpha has pretty much
> been announce nicely on time for people to know what's happening.
I think what Matthew suggest here is something in the line of democratically
defining a release process up front: features you would like to get in (a
roadmap that clearly states that the content can change up until a feature
freeze), a deadline for the feature freeze so that the process is
predictable and appoint a release manager to be in charge of the branch.
Something like:
- Branching next version from day one so you have one called next and one
called trunk for edge stuff, and appoint a release manager to approve
features as they are merged from development branch(es)
Alternatively (among several possible branch strategies) in DVCS you could
use topic branches for the edge implementations, this is cleaner (maybe),
but the point is to have a release branch that can be stabilized at anytime.
For a more in-depth branching possibility see:
http://nvie.com/posts/a-successful-git-branching-model/
- Define a feature freeze date, anything not ready feature or stability wise
is moved to Next Next roadmap (they are not in the Next release branch
anyway as it only has feature complete features at any point)
And branch off Next Next and appoint a release manager for that branch so
there is always an active release branch.
This will give a more predictable release schedule for everyone involved,
especially for php users as it will give them a real hint on when the
testing process of the next version will begin and some clue on when it
might get finalized. All without having to introduce full fledge scrum and /
or a strict release process.
- ar
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 Pena wrote:
>> > > > . classes named as any of the type hint scalar types
>> > > > do not work anymore
>> > > > aka class int {}
>> > >
>> > > Yeah, there is a slight hint of a BC break in case you have a class
>> > > named "int" or "float" etc. But there is:
>> > > http://uk.php.net/manual/en/userlandnaming.tips.php
>> > >
>> > > Perhaps we can reduce the current list of classes:
>> > > int, integer, real, double, string, binary, scalar, array, object,
>> > > bool, boolean
>> > > to what the manual uses though (for prototypes):
>> > > int, float, string, binary, scalar, array, object, bool
>> > > (Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php
>> )
>> >
>> > Sorry, but this is actually a pretty grave BC break.
>> >
>> > Currently, you can do the following:
>> >
>> > namespace Foo\Validator;
>> >
>> > class Int {}
>>
>> During our namespace discussion, this is exactly what I warned about. In
>> order to make use of namespaces, you need to have atleast two "elements"
>> in your class names otherwise we can still never introduce a new class.
>> But that was not listened too.
>>
>> > As Sebastian noted, it seems this should be addressed with the new
>> > lexer; I'd argue that if the current type hinting must introduce new
>> > keywords, it should wait until the new lexer is in place in order to
>> > insulate end-users from such changes.
>>
>> The new lexer however, is a slower; so not a viable solution right now.
>>
>> > With a defined release process, *everyone* knows what must be done, by
>> > when, making the process more transparent and *gasp* democratic.
>>
>> Well, I don't think we've ever been democratic. I probably think
>> that that wouldn't even work. Also, I think an alpha has pretty much
>> been announce nicely on time for people to know what's happening.
>
>
>
> I think what Matthew suggest here is something in the line of
> democratically defining a release process up front: features you would like
> to get in (a roadmap that clearly states that the content can change up
> until a feature freeze), a deadline for the feature freeze so that the
> process is predictable and appoint a release manager to be in charge of the
> branch.
>
> Something like:
> - Branching next version from day one so you have one called next and one
> called trunk for edge stuff, and appoint a release manager to approve
> features as they are merged from development branch(es)
> Alternatively (among several possible branch strategies) in DVCS you could
> use topic branches for the edge implementations, this is cleaner (maybe),
> but the point is to have a release branch that can be stabilized at anytime.
> For a more in-depth branching possibility see:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> - Define a feature freeze date, anything not ready feature or stability
> wise is moved to Next Next roadmap (they are not in the Next release branch
> anyway as it only has feature complete features at any point)
> And branch off Next Next and appoint a release manager for that branch so
> there is always an active release branch.
>
When feature freeze date for Next is reached.
>
> This will give a more predictable release schedule for everyone involved,
> especially for php users as it will give them a real hint on when the
> testing process of the next version will begin and some clue on when it
> might get finalized. All without having to introduce full fledge scrum and /
> or a strict release process.
>
>
> - ar
>
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" (T_VAR) and "function"
> >> (T_FUNCTION) respectively.
> >> However "private var $foo;" generates a fatal error but "private
> >> function foo(){}" not?
> >
> > The "var" keyword is an alias of the "public" keyword for BC with
> > PHP4. So it would be illogically to declare a property both private
> > and public at the same time ;-)
>
> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
> introducing the possible omission of T_FUNCTION?
Why?
This will break lots of code, does it improve anything while at it? Is 'var'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka "6.0" the 2nd , and not in
5.x.
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 fast as well [3]. [1] http://wiki.php.net/rfc/splclassloader [2] http://blog.runpac.com/post/splclassloader-php-extension-benchmarks [3] http://weierophinney.net/matthew/archives/245-Autoloading-Benchmarks.html Best ar On Wed, Jan 12, 2011 at 11:53 PM, Marc Easen wrote: > Hello again, > > Has anyone had a chance to look at my patch? > > Forgive me for being quite eager to get this into trunk, as it will improve > the performance of all PHP Frameworks which currently implement their own > autoloader method due to the oddities of the SPL autoloader. > > > > Kind Regards > Marc > > > On 26 Dec 2010, at 13:20, Marc Easen wrote: > > Hello everyone, > > Firstly I would like to introduce myself, my name is Marc Easen and I've > working with PHP for past 6 years or so. I'm really excited to see where PHP > is going with the addition of namespaces and now traits, and hopefully I'm > able to contribute back to PHP community. > > I've currently working on a high performance PHP Framework based on version > 5.3.3+ (5.3.99-dev for traits). Due to the high performance nature of this > framework I've been looking at ways of improving the loading of the classes. > It seems by default the spl_autoload() function lowercases the class name > before trying to locate the file, a couples of users have reported this > previously and have requested a fix (bug #49852 > http://bugs.php.net/bug.php?id=49852 & bug #53065 > http://bugs.php.net/bug.php?id=53065). spl_autoload() lower casing the > class names when it is trying to locate the file does not work on *nix based > system in a lot of PHP Frameworks - Zend Framework being on of them. > > Understanding the requirement to support backwards compatibility both > submitters suggested implementing a spl_autoload_case_sensitivity() > function. The patch I have attached adds such a function to the SPL > extension. The patch is against trunk (r306670), it also includes phpt tests > for this function. > > Please could someone review this patch and let me know what you think. > > Kind Regards, > > Marc > > > > >
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 think this is a more solid proposal than my original one, and I hope
> we can continue to discuss it and agree to the extent that it's worth
> starting an implementation.
>
> Please read it and comment whenever you can find some time, guys!
>
As for your first example:
trait T {
public function foo() {
echo "T";
}}class C {
use T;
public function foo() {
echo "C";
}}
I think it would sometimes be desirable to allow this, for instance when a
trait has been updated in a framework to adapt to what has become common
practice in classes that uses it in the wild.
( I assume you already get error if function signature is different like in
inheritance? )
So to allow both cases, what about letting people use the final keyword on
functions to signal functions that can not be re declared without alias. Or
better, add a new keyword since final should mean final.
My 2 Euro cents,
André
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 already accepted for PHP6 [2], but now it seems to be orphaned. > In > > my opinion it is a very nice enhancement, that helps to get rid of the > > Getter/Setter-mess. Are there any plans? > > This RFC by Dennis was never 100% finalized, however from what I > remember it was suggested too late in 5.3's development process to be > implemented, and so do I think we are in 5.4 already as the RFC would > need some extra care before sent to the list, perhaps even a patch for > parts of it. > Type hinting is for instance not covered (should imho at least be on pair with function signatures). > > The RFC itself evolved quite a bit doing its drafts on the wiki, I > remember having long emails with Dennis about the syntax, as it > evolved to allow many more things and additions to the object model, > like final properties, interfaces with properties, getters, setters, > But in the end I think it would rime greatly with traits and > other goodies in 5.4 if someone took the time and care for this RFC, > just worried its way too late already. > On 6.0 todo list: There are lots of things that would be nice additions to php on the 6.0 todo list*. If all these have been voted for in the past, I'll suggest that they could be worked on in upcoming 5.x versions as well leading up to an eventual 6.0 version. *eg: - Property overloading RFC aka abstract/virtual properties and get/set handlers (derick) (related?) - add support for type-hinted return values. *caugh* - add ability to allocate persistent zvals in PHP. - add support for files >2GB once native 64bit integers are implemented (pierre,wez) - APC - include APC in the core distributions (turned off by default) and switch to mmap as default shared memory storage. - ability to move autoloaded main classes in apc's class lookup preventing the overhead of doing the inheritance process all the time. (marcus) > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[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 Closure, and change the name of the actual class + implement the Closure interface.. Best Regards / Med vennlig hilsen André R.
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 ask on this > thread and I'll quickly answer here and also update the RFC > accordingly. > As sent to the PHP-SWG list, a small change / addition to PSR-0 would simplify the matching considerably. If this rule: * Each “_” character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The “_” character has no special meaning in the namespace. is changed to * Each “_” character in the CLASS NAME and NAMESPACE is converted to a DIRECTORY_SEPARATOR. Or a strict mode is added to enable that, then you'll reduce 6 string function to 2, and still have backward support for PEAR class naming(w/o namespace). > The url for the RFC is: https://wiki.php.net/rfc/splclassloader > > Cheers, > > On Mon, Oct 24, 2011 at 7:55 PM, David Coallier wrote: > >> > >> Could you open a FR at bugs.php.net and attach the patch to it please? > >> Could be easier to track (and the # to the RFC too :) > >> > > > > Yeah I'll do that once I have the tests adjusted and once I know the > > patch actually works as expected. > > > > -- > > David Coallier > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- > Guilherme Blanco > Mobile: +55 (11) 8118-4422 > MSN: guilhermebla...@hotmail.com > São Paulo - SP/Brazil > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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 a ASSERT_CLASS_EXISTS mode, i.e. after the require an
> "if(!class_exists($class))" => throw new LogicException("SplClassLoader
> expects class $class to be in $file, but after requiring the file this
> class
> is still not loaded."); API here aswell "new SplCloassLoader(...,
> SplClassLoader::ASSERT_CLASS_EXISTS)"
>
What if 5.4 enhanced class_exists() to send a second true argument (an
optional argument, where default should be false) to autoloaders, then users
wouldn't have to deal with silent vs noisy modes at all.
So signature of autoload functions becomes:
function load( string $className, bool $checkExistence = false );
In the case of splClassLoader, $checkExistence = false would for instance
mean you would get a *E_COMPILE_ERROR *(requrie) if the class does not exist
but does match the configured root name spaced to be handled, if the
argument is true, then a bool is returned.
>
> greetings,
> Benjamin
>
> 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 ask on this
> > thread and I'll quickly answer here and also update the RFC
> > accordingly.
> >
> > The url for the RFC is: https://wiki.php.net/rfc/splclassloader
> >
> > Cheers,
> >
> > On Mon, Oct 24, 2011 at 7:55 PM, David Coallier wrote:
> > >>
> > >> Could you open a FR at bugs.php.net and attach the patch to it
> please?
> > >> Could be easier to track (and the # to the RFC too :)
> > >>
> > >
> > > Yeah I'll do that once I have the tests adjusted and once I know the
> > > patch actually works as expected.
> > >
> > > --
> > > David Coallier
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> >
> >
> > --
> > Guilherme Blanco
> > Mobile: +55 (11) 8118-4422
> > MSN: guilhermebla...@hotmail.com
> > São Paulo - SP/Brazil
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
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 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 ask on this > >> thread and I'll quickly answer here and also update the RFC > >> accordingly. > >> > > > > > > As sent to the PHP-SWG list, a small change / addition to PSR-0 would > > simplify the matching considerably. > > > > If this rule: > > * Each “_” character in the CLASS NAME is converted to a > > DIRECTORY_SEPARATOR. The “_” character has no special meaning in the > > namespace. > > > > is changed to > > * Each “_” character in the CLASS NAME and NAMESPACE is converted to a > > DIRECTORY_SEPARATOR. > There is a internal autoloader in > Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup), > in it the T_NS_SEPARATOR will convert to be "_", then convert to be > DIRECTORY_SEPARATOR. > > thanks > As mentioned by others this will have to go into a new PSR standard as PSR-0 was accepted 2 years ago. And assuming that a C implementation will greatly out-weight the reduced amount of str functions in terms performance we should not block this process to get it into 5.4 by taking up off-topic subjects like mentioning things not part of PSR-0. But! The implementation proposal (rfc) should be adjusted to be forward compatible, including support for several namespaces pr instance (mention by several on PSR mailing list) imho. Possible example (additional arguments can be added later when more features are added, aka a PSR-1 mode): new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) ); Or something like this (if we want the options to be an array): new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' => '/path/to/doctrine' ) ) ); For documentation and argument validation, imo the former approach would be better. So what is the status here? thread has been silent for a while. > > > > Or a strict mode is added to enable that, then you'll reduce 6 string > > function to 2, and still have backward support for PEAR class naming(w/o > > namespace). > > > > > > > > > >> The url for the RFC is: https://wiki.php.net/rfc/splclassloader > >> > >> Cheers, > >> > >> On Mon, Oct 24, 2011 at 7:55 PM, David Coallier wrote: > >> >> > >> >> Could you open a FR at bugs.php.net and attach the patch to it > please? > >> >> Could be easier to track (and the # to the RFC too :) > >> >> > >> > > >> > Yeah I'll do that once I have the tests adjusted and once I know the > >> > patch actually works as expected. > >> > > >> > -- > >> > David Coallier > >> > > >> > -- > >> > PHP Internals - PHP Runtime Development Mailing List > >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> > > >> > > >> > >> > >> > >> -- > >> Guilherme Blanco > >> Mobile: +55 (11) 8118-4422 > >> MSN: guilhermebla...@hotmail.com > >> São Paulo - SP/Brazil > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ >
Re: [PHP-DEV] SplClassLoader
On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara wrote: > Can I make a point here. > > Why the heck are we caring about the performance of the autoloader at > all here? The filesystem operations necessary (at least the stat() > call) will greatly dominate any string function. And considering that > even the biggest framework only has perhaps a few hundred classes, > you're talking about incredibly small performance gains here. Even if > you save a microsecond in string operations (try it, even in PHP the > string operations can be done in around 10 or 20 microseconds), after > all classes are loaded you're only talking about a 1 or 2 milliseconds > of gain in the application. > > I'm not saying that we shouldn't try to save time where we can, but > given the controversial nature of this addition, I don't think that a > micro-optimization (which is what this really is) should be used as a > justification for why it should be included. It's not like we're > talking about implementing a computationally difficult task into C > (such as a cryptographic algorithm) where putting it into C would > create a huge performance gain. We're talking about implementing a > function which already is dominated by non-computational overhead into > C to save a few milliseconds. The number of instances that will > benefit from such an addition are incredibly small. Saving 2 > milliseconds on an application (that likely takes hundreds of > milliseconds to render) would require a huge number of requests to > amortize into an actual measurable benefit. And those that do benefit > would have access to their server farm to add the pecl extension > anyway. So there's really no practical performance gain to the > community as a whole, hence confirming that this is a > micro-optimization. > > Personally I feel that this does not belong in the core (especially > not yet as with the inconsistencies). > > But that's besides the point. I just want to emphasize the point that > performance should not be a criteria for justifying it going into the > core... You mixing up one of my personal objectives* with the poster's objective** (which I also share). * making the class map based vs convention based performance discussion 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 at 10:56 AM, André Rømcke wrote: > > 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 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 ask on this > >> >> thread and I'll quickly answer here and also update the RFC > >> >> accordingly. > >> >> > >> > > >> > > >> > As sent to the PHP-SWG list, a small change / addition to PSR-0 would > >> > simplify the matching considerably. > >> > > >> > If this rule: > >> > * Each “_” character in the CLASS NAME is converted to a > >> > DIRECTORY_SEPARATOR. The “_” character has no special meaning in the > >> > namespace. > >> > > >> > is changed to > >> > * Each “_” character in the CLASS NAME and NAMESPACE is converted to a > >> > DIRECTORY_SEPARATOR. > >> There is a internal autoloader in > >> Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup), > >> in it the T_NS_SEPARATOR will convert to be "_", then convert to be > >> DIRECTORY_SEPARATOR. > >> > >> thanks > >> > > > > > > As mentioned by others this will have to go into a new PSR standard as > > PSR-0 was accepted 2 years ago. > > > > And assuming that a C implementation will greatly out-weight the reduced > > amount of str functions in terms performance we should not block this > > process to get it into 5.4 by taking up off-topic subjects like > mentioning > > things not part of PSR-0. > > > > But! > > > > The implementation proposal (rfc) should be adjusted to be > > forward compatible, including support for several
Re: [PHP-DEV] SplClassLoader
.. > >> > >> Anthony > > Basically, theres approx a dozen of the most recognised PHP libraries > > that are advocating the use of a generalised class mapping standard. > > > > This is great, and allows switching between projects very seamless as > > there's no additional learning curve. > > while(consistency) learning_curve--; > > > > If library vendors are implementing their own custom autoloading > > structure/mechanism it's very counter-productive to the PHP > > eco-system. The point of PSR-0 is to create a standard to allow > > compatibility between vendor libs such as ZF/Symfony/PPI. > > > > 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 rather than relying on > > third-party code to provide that. Additionally the small performance > > boost but including SplClassLoader is not driven by the speed benefit > > but by the community/library benefit. > > > > 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 wrote: > >>> 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 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 ask on this > >>>> >> thread and I'll quickly answer here and also update the RFC > >>>> >> accordingly. > >>>> >> > >>>> > > >>>> > > >>>> > As sent to the PHP-SWG list, a small change / addition to PSR-0 > would > >>>> > simplify the matching considerably. > >>>> > > >>>> > If this rule: > >>>> > * Each “_” character in the CLASS NAME is converted to a > >>>> > DIRECTORY_SEPARATOR. The “_” character has no special meaning in the > >>>> > namespace. > >>>> > > >>>> > is changed to > >>>> > * Each “_” character in the CLASS NAME and NAMESPACE is converted > to a > >>>> > DIRECTORY_SEPARATOR. > >>>> There is a internal autoloader in > >>>> Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup > ), > >>>> in it the T_NS_SEPARATOR will convert to be "_", then convert to be > >>>> DIRECTORY_SEPARATOR. > >>>> > >>>> thanks > >>>> > >>> > >>> > >>> As mentioned by others this will have to go into a new PSR standard as > >>> PSR-0 was accepted 2 years ago. > >>> > >>> And assuming that a C implementation will greatly out-weight the > reduced > >>> amount of str functions in terms performance we should not block this > >>> process to get it into 5.4 by taking up off-topic subjects like > mentioning > >>> things not part of PSR-0. > >>> > >>> But! > >>> > >>> The implementation proposal (rfc) should be adjusted to be > >>> forward compatible, including support for several namespaces pr > instance > >>> (mention by several on PSR mailing list) imho. > >>> > >>> Possible example (additional arguments can be added later when more > >>> features are added, aka a PSR-1 mode): > >>> > >>> new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) > ); > >>> > >>> > >>> Or something like this (if we want the options to be an array): > >>> > >>> new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' => > >>> '/path/to/doctrine' ) ) ); > >>> > >>> > >>> For documentation and argument validation, imo the former approach > would be > >>> better. > >>> So what is the status here? thread has been silent for a while. > >>> > >>> > >>>> > > >>>> > Or a strict mode is added to enable that, then you'll reduce 6 > string > >>>> > function to 2, and still have backward support for PEAR class > naming(w/o > >>>> > namespace). > >>>> > > >>>> > > >>>> > > >>>> > > >>>> >> The url for the RFC is: https://wiki.php.net/rfc/splclassloader > >>>> >> > >>>> >> Cheers, > >>>> >> > >>>> >> On Mon, Oct 24, 2011 at 7:55 PM, David Coallier > wrote: > >>>> >> >> > >>>> >> >> Could you open a FR at bugs.php.net and attach the patch to it > >>>> please? > >>>> >> >> Could be easier to track (and the # to the RFC too :) > >>>> >> >> > >>>> >> > > >>>> >> > Yeah I'll do that once I have the tests adjusted and once I know > the > >>>> >> > patch actually works as expected. > >>>> >> > > >>>> >> > -- > >>>> >> > David Coallier > >>>> >> > > >>>> >> > -- > >>>> >> > PHP Internals - PHP Runtime Development Mailing List > >>>> >> > To unsubscribe, visit: http://www.php.net/unsub.php > >>>> >> > > >>>> >> > > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Guilherme Blanco > >>>> >> Mobile: +55 (11) 8118-4422 > >>>> >> MSN: guilhermebla...@hotmail.com > >>>> >> São Paulo - SP/Brazil > >>>> >> > >>>> >> -- > >>>> >> PHP Internals - PHP Runtime Development Mailing List > >>>> >> To unsubscribe, visit: http://www.php.net/unsub.php > >>>> >> > >>>> >> > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Laruence Xinchen Hui > >>>> http://www.laruence.com/ > >>>> > >>> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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 ->unregister(), and make the > spl_autoload_register to support SplClassLoader. > > I'm really +0 on this one. > But since the proposal covers an OO approach for autoload, it makes > sense the registering is pat of the available API, not in procedural > land. > +1 on remove, don't duplicate things already part of php. While on duplication, why complicate things by having custom $includePathLookup support? This is already handled by php isn't it? > > 2- Remove constructor prototype in interface > > After some thought it makes sense, but only if interface then defines > the setMode prototype. > The background for this is supported if the user decides to enhance > the base class to support caching, requiring the injection of the > Cache layer in constructor. If it's part of the interface, it cannot > be changed. > I took this example after looking at Symfony's > ApcUniversalClassLoader: > > https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php > > +1 on removing constructor from interface. But imo SplClassLoader should have a constructor where you can optionally provide a hash of namespace and path, so you can do: spl_autoload_register( new SplClassLoader( array( 'ns' => 'path/', 'ns2' => 'path2/' ) ) ); (assuming spl_autoload_register gets native support for SplAutoloader, otherwise it it will of course have to be provided as a callback)
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?
> >
> > Example: Return null at will
> >
> > public ArrayIterator getIterator()
> > {
> >// something happened, will return null
> >return null;
> > }
> >
> > Example: Return only if identified as such
> >
> > public ArrayIterator? getIterator()
> > {
> > return null;
> > }
>
> I hate the syntax in the second example (using ?).
>
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public Nullable Time { get; set; }
>
> IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch wrote:
> In the interest of providing options for an ability to mark a method as
> returning null, I have added a new patch here:
> http://www.willfitch.com/php/nullable.patch
>
> This includes a new token "T_NULLABLE". Here are a few examples:
>
> // This is allowed
> private nullable ArrayIterator getIterator()
> {
>return null;
> }
>
> // This throws an E_RECOVERABLE_ERROR
> private ArrayIterator getIterator()
> {
> return null;
> }
>
> The token/identifier can certainly 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 [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?
>> >
>> > Example: Return null at will
>> >
>> > public ArrayIterator getIterator()
>> > {
>> >// something happened, will return null
>> >return null;
>> > }
>> >
>> > Example: Return only if identified as such
>> >
>> > public ArrayIterator? getIterator()
>> > {
>> > return null;
>> > }
>>
>> I hate the syntax in the second example (using ?).
>>
>
>
> It looks strange, but easy to get used to. Two examples from C#:
>
> public decimal? Grade { get; set; }
>
> public Nullable Time { get; set; }
>
>
>
>
>>
>> IMO allowing null should be the default unless specifically disallowed.
>
>
> I disagree for the reasons mentioned by for instance Robert.
> Type hints should be strict/explicit or not done at all.
>
>
>
For the record; This was not ment as an argument against scalar, and
similar type hints ( object, callable.. ) .
It was an argument against hinting about something and getting
something completely different (null).
Happy xmas!
[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/releaseprocess ) It is not a big deal (we are used to it), but it does break a couple of things in for instance eZ Publish & Zeta Components which will by the nature of things not be fixed before the next release. Most customers will hopefully make sure the version of the software they are using is tested/certified for php 5.4 before upgrading, but from experience, some will not. Other then that, happy xmas!
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
> > makes very little sense in this case.
> >
> > While a fix is easy, (int) casting and works with all previous
> > versions, I would like to know how it breaks apps out there.
>
> new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e.
>
>
Yes, this is the one from Zeta Components MvcTools.
In eZ Publish it was db based session gc using REQUEST_TIME
and compatibility for potential extensions that might have used this
variable via eZ Publish api:
https://github.com/ezsystems/ezpublish/commit/3483c623769aa9ed3be7b6f33e3579cf8a8efd45
In both cases a (int) was added in front of the variable to make sure it
still behaves the same, so not a big deal.
But as also mentioned, changes like this requires patching to
be compatible with 5.4.
So unless this is done to be inline with some standard on such a server
variable, I would suggest placing microtime on a separate server variable
(since it is indeed useful to have it for time accumulators and performance
metrics).
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 provide necessary > extensions. While at it how does this compare to jit branch? > > Thanks. Dmitry. > > On May 5, 2017 10:26 PM, Matt Wilmas wrote: > Hi Dmitry, > > - Original Message - > From: "Dmitry Stogov" > Sent: Wednesday, May 03, 2017 > >> Hi, >> >> >> I propose a new VM instruction dispatch technique, that provides great >> speed up on small benchmarks (1.5 times on bench.php) > > Interesting. :-) How does this compare to pure GOTO dispatch...? > >> Please review https://github.com/php/php-src/pull/2507 >> >> Take into account, that HYBRID VM is not enabled by default and VM has to >> be regenerated by "php zend_vm_gen.php --with-vm-kind=HYBRID" >> >> >> It doesn't work with phpdbg, out of the box, and may make some troubles to >> xdebug and other system extensions. >> >> >> I'm going to commit this into master after review and then rise question >> about enabling it by default in PHP-7.2. >> >> >> Thanks. Dmitry. > > - Matt > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 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 provide necessary >>> extensions. >> While at it how does this compare to jit branch? > > obviously it's not "one or the other" > > https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit > https://github.com/zendtech/php-src/commit/d570de2cb6a88d9772f510d112a04ce4022110cd Already following that, but thanks for the sarcasmsplaining. Question was more in regards to if that will follow suite, but I assume not (yet), and this wouldn't be the right thread for it.
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 ; >> Stanislav Malyshev ; Marco Pivetta >> ; PHP internals >> Subject: Re: [PHP-DEV] [RFC] Typed Properties >> >> Just want to be annoying about this since the currently scheduled fork date >> for >> PHP-7.3 is 11 days off. >> 1/ Do we have *ANY* objections to additional alpha(s) to accommodate Typed >> Props? (I would propose two additional alphas) 2/ Do we actually need to >> hold a >> formal vote? (If so, that vote should start *now*) > > Sara, > > I do see a couple of issues here. > > First, it may be a personal thing, but I feel that the flexibility towards > adding this is very contrasty with the inflexibility shown as we headed > towards the PHP 7.0 feature freeze - inflexibility that resulted in a rushed > (and IMHO wrong) decision regarding how to implement the non-strict types. > For the record - as I said back then - I think that the right way is to be > flexible - the dates are just dates, and are - in all honesty - not that > important - it’s the severe inconsistency that bothers me. Regardless of typed properties this sounds like something that should be tackled as an independent topic. (It could in theory, if accepted, be a new type flag introduced in 7.4 and made default in 8.0 that affect all type usage consistently.) > > Secondly, and somewhat related - typed properties isn't a small feature. It > is, in fact, a pretty huge one. Making exceptions for a fairly minor feature > or some extra deprecation is one thing. Making an exception for something as > fundamental as that feels wrong. > > Even though Nikita's proposal and implementation look pretty solid, something > as fundamental as that should go through a substantial active discussion > period (which didn't really happen here as it wasn't clear whether this was > headed for an exceptional 7.3 addition or not) - and independently - should > perhaps go hand-in-hand with fixing the flaws of the non-strict types - > something we can do in PHP 8. If we do the latter, then perhaps, just > perhaps, we can introduce it hand-in-hand with typed variables - and if we > do, it will be sensible to do it at the same time and not in a gradual > rollout. Personally, I think even independently of typed variables, typed > properties feel like an 8.0 feature, not a 7.x feature. While I agree this is big, (from user land it’s fantastic), and should only go in if solid. It does contradict your argument the other day about being careful what to push into 8.0 scope as core resources are scarce. So if we look at it from that perspective, then spreading the risk is essentially safer.
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% > slowdown (on mediawiki). Nice overview. Is there any overview of how it will improve performance for code moving from magic getters / setters to this? Or is there interest in such a comparison? (Context: working on a larger open source project where that is used quite a bit for type and read-only safety checks.) Best, André
