Re: [PHP-DEV] [RFC] Default expression
On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall wrote:
>
>
> On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts.
> These might require testing for non-zero first as well.
>
>
> I have to be honest all of these both sound like really bad practices.
> Maybe I'm just not being imaginative enough... but if you don't control the
> upstream library why would you ever trust it like that? Writing a timeout
> default
> * 0.5 when default is 1000 is a really bad way to set your timeout to
> 500 -- because next time you done a composer update suddenly the
> upstream package set the timeout to 5000 and now instead of 500 your
> timeout has silently become 2500.
>
You'll likely identify the increased delay in such cases. Generally
speaking these sorts of default values don't change a ton, but it's not
unlikely that you may say "I'd like half that delay" or "twice that delay".
But a better example would be introducing a backoff, which might look like
this:
for ($i = 1; $i += 1 ; $i < 4) {
$result = call_some_client($url, default * $i);
if ($result->isSuccess()) {
break;
}
}
In other words, you know that you want it to use the default, and then
allow an increasing timeout duration between calls if it fails. For this, I
don't necessarily want or need to know what the default is, only that I
want to do _multiples_ of it in specific cases.
Is it a universally good idea? No. Does it have use cases? Yes.
- decorating a default instance (e.g. to lazily create a proxy without
> knowing the default implementation used for an argument hinted against an
> interface)
>
>
> This is exactly the usage I'm highlighted as problematic in my code
> example. You're introducing a new worry for the upstream API developer that
> doesn't need to exist, and violating a separation principle that has
> existed in PHP since default parameters were created 25+ years ago.
>
How exactly is this worrisome? Consider this:
class A {
public function __construct(private LogInterface $logger = new
DefaultLogger()) { }
}
class ProxiedLogger implements LogInterface { ... }
$a = new A(new ProxyLogger(default));
If class A is programming to the `LogInterface` contract, the fact that it
gets a proxied version of the default should not matter in the least. Being
able to proxy like this means that a _consumer_ of class A does not need to
know or care what the default implementation is; they can assume it follows
the same contract, and proxy to it regardless. The upstream developer
doesn't need to care, because they are programming to the interface, not
the implementation. This doesn't violate the separation of concerns
principle, nor covariance.
> IF it's possible to accomplish, I think it's better to identify the
> "leaving this open will create WTF situations" than to prematurely lock
> _everything_ down up front.
>
>
> If this feature is released with an overly broad scope in terms of
> expressions, etc. it's not like we can take it back at that point because
> now people are using it in unknown ways. It is not one I'm comfortable with
> a "let's move forward and see what happens" approach.
>
I didn't say that at all. I said we should identify the ones we absolutely
know will be problematic, and restrict those from the outset. From there,
we should identify the ones that _might_ be problematic, and determine on a
case by case basis if the risks outweigh the use cases before Bilge brings
it to a vote.
But if we lock it down too tightly from the outset, expanding it, while
being possible, will more than likely mean an RFC for every expansion,
because it's unlikely somebody will do anything comprehensive towards
opening it up in the future. I'd rather not leave some of these use cases
as a TBD for a later RFC, because that's very likely going to mean "never".
I DO think there are likely whole categories of expressions we can likely
say "no" to - anything where the default represents a union type (and
_mixed_ is a union type) should likely only allow default by itself or as a
bare value on the RHS of an expression.
The argument against the feature that it expands the public API is puzzling
to me, particularly when the only other solutions are (a) Reflection, or
(b) named arguments. Named arguments _are_ part of the public API, as the
names themselves can change. Default values can change, but, importantly, a
change in a default value does
Re: [PHP-DEV] [RFC] Default expression
On Mon, Aug 26, 2024, 12:02 PM Larry Garfield
wrote:
> On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> > wrote:
> >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> >> > You're absolutely right, I would be interested to see any viable
> patch
> >> > that effectively implements a set of restrictions on how `default`
> may
> >> > be used. Requesting it be done at the parser level was not meant as a
> >> > gotcha, that's just how I (with my lack of experience) would have
> >> > approached it, but certainly trapping cases in the compiler is
> equally,
> >> > if not more valid and/or practical.
> >>
> >> Another approach that occurred to me was in the executor: rather than
> evaluating to the default value immediately, "default" could resolve to a
> special value, essentially wrapping the reflection parameter info. Then
> when the function is actually called, it would be "unboxed" and the actual
> value fetched, but use in any other context would be a type error.
> >>
> >> That would allow arbitrarily complex expressions to resolve to
> "default", but not perform any operations on it - a bit like propagating
> sqrt(-1) through an engineering formula where you know it will be cancelled
> out eventually.
> >>
> >
> > I 100% agree with this.
> > "default" should not evaluate to a value before sending it as an
> > argument to the function or method.
> > I understand from what the RFC author wrote a while ago that doing so
> > (evaluating to the actual default value using reflection) was the
> > easier and perhaps only viable way at the moment, but if that's the
> > case, I don't think the value of this RFC justifies doing something
> > like that, which to me seems like a hack.
> >
> > For those already expressing interest in being able to modify a binary
> > flag default parameter using this "trick", I still don't think it
> > justifies this RFC. In my opinion, functions that accept multiple
> > arbitrary options by compressing them into a binary flag have a badly
> > designed interface to begin with.
> >
> > So, my 10c: Make "default" a pure keyword / immutable value if
> > possible, or reconsider whether this feature is really worth the fuss.
>
> The problem here is that `foo(default | ADDITIONAL_FLAG)` is so far the
> most compelling use case I've seen for this feature. It's really one of
> only two I see myself possibly using, frankly. So a limitation that would
> disallow that pattern would render the RFC almost useless.
>
> The other compelling case would be the rare occasions where today you'd do
> something like this:
>
> if ($user_provided_value) {
> foo($beep, $user_provided_value);
> } else {
> foo($beep);
> }
>
> Which this RFC would allow to be collapsed into
>
> foo($beep, $user_provided_value ?: default);
>
> So far those are the two use cases I can realistically see being helpful,
> and I acknowledge both are.
I can see a few others:
- string concatenation. I might want to prepend or append a string to a
default.
- fractional or multiplicative application, e.g. for durations/timeouts.
These might require testing for non-zero first as well.
- decorating a default instance (e.g. to lazily create a proxy without
knowing the default implementation used for an argument hinted against an
interface)
And these are just off the top of my head. I could likely identify more
with a short bit of time looking through some libraries I regularly use.
I recognize that "limiting the allowed expression structures arbitrarily is
> way harder than it sounds" is a valid argument as well. At the same time,
> John C has offered some valid examples of cases where it would open up
> additional footguns, and we want to minimize those in general. Those
> shouldn't be ignored, either.
>
IF it's possible to accomplish, I think it's better to identify the
"leaving this open will create WTF situations" than to prematurely lock
_everything_ down up front.
There's been a few good lists about the cool things this could enable,
demonstrating the value; maybe now we should focus on the "we absolutely
shouldn't enable" pieces to allow for broader consensus.
> At the moment I'm on the fence on this RFC. I could go either way right
> now, so I'm watching to see how it develops.
>
> --Larry Garfield
>
Re: [PHP-DEV] [RFC] Default expression
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall wrote:
>
>
> On Aug 24 2024, at 12:49 pm, Bilge wrote:
>
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
>
> Seems like you are missing an option for your theme example, which would
> be to simply extend the Config class?
>
> While I can see the value in the concept of default , I think it's a
> mistake to allow default to be used as a generic operand as shown in the
> RFC appendix. It seems to me that the whole point of something like
> default is to not have to worry about what the upstream API wanted for
> that value, but the second you start allowing operations where default
> is an operand you've reintroduced the problem you were trying to avoid if
> the upstream API were to change the type of what default ultimately
> resolves to. Worse actually because now I have no idea what default is
> when I read code without having to dig up the upstream API.
>
If the underlying API changes the argument type, consumers will have an
issue regardless. For those cases where the expression is simply `default`,
you'd actually be protected from the API change, which is a net benefit
already.
This also protects the user from changes in the argument names.
> Other thoughts here are what happens when default resolves to an object
> or enumeration or something complex? Your original example had CuteTheme ,
> so can you call a method of default ?? I could entirely see someone doing
> something like this for example:
>
> enum Foo:string {
> // cases
>
> public function buildSomeValidBasedOnCase(): int { // ... }
> }
>
> F(MyClass::makeBasedOnValue(default->buildSomeValidBasedOnCase()))
>
> IMO most operators listed in the appendix should be disallowed. I can see
> the value of default | JSON_PRETTY_PRINT, but I am pretty strongly
> opposed to the idea of introducing a "conditional based on the default
> value of an upstream API call" concept of default >=1 .
>
>
>
Re: [PHP-DEV] [RFC] Default expression
On Sat, Aug 24, 2024, 11:50 AM Bilge wrote: > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > think some of you might enjoy this one. Hit me with any feedback. > This is a feature I've wanted for a very long time! The RFC is very straight forward, and the appendix does a great job of enumerating the possible expressions. Nice work all around! > This one already comes complete with working implementation that I've > been cooking for a little while. Considering I don't know C or PHP > internals, one might think implementing this feature would be > prohibitively difficult, but considering the amount of help and guidance > I received from Ilija, Bob and others, it would be truer to say it would > have been more difficult to fail! Huge thanks to them. > > Cheers, > Bilge >
Re: [PHP-DEV] function autoloading v4 RFC
On Tue, Aug 20, 2024, 4:56 PM Rob Landers wrote:
>
>
> On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote:
>
> On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote:
>
>
>
> On 20 August 2024 00:21:22 BST, Rob Landers wrote:
> >
> >I assume you are worried about something like this passing test?
> >
> >--TEST--
> >show called only once
> >--FILE--
> > >
> >namespace test;
> >
> >spl_autoload_register(function($name) {
> >echo "name=$name\n";
> >}, true, false, SPL_AUTOLOAD_FUNCTION);
> >
> >echo strlen('foo');
> >echo strlen('bar');
> >echo strlen('baz');
> >?>
> >--EXPECT--
> >name=test\strlen
> >333
> >
> >In my RFC, I mention it is called exactly once.
>
>
> I haven't looked at the PR, only the RFC, and I did not see this very
> important detail explained anywhere. The only thing I can see is this
> rather ambiguous sentence:
>
> > The function autoloader will not be called again.
>
> That could mean not called again for the current call (compared with
> proposals that call it a second time with the unequalled name); it could
> mean not called again for the current line of code (based on the current
> caching behaviour); or never called again for that combination of namespace
> and name; or possibly, never called again for that combination of
> namespace, name, and callback function.
>
> That's not a small detail of the implementation, it's a really fundamental
> difference from previous proposals.
>
> So I would like to repeat my first response to your RFC: that it should
> sound more time explaining your approach to the multiple lookup problem.
>
> Regards,
> Rowan Tommins
> [IMSoP]
>
>
> Thanks Rowan,
>
> That's a fair critique.
>
> I expect some of the wording will be more clear once I write out the
> documentation -- even if it isn't used directly, I tend to write out
> documentation to force myself to reconcile the code with the plan, find
> logic bugs, perform larger scale tests, and create tests to verify
> assertions in the documentation. From there, I'll update the plan or code
> to get everything to match and spend some time on clarity. It's the hardest
> part, IMHO, as it requires diligently ensuring everything is correct. In
> other words, writing the documentation makes it feel like a "real thing"
> and it triggers what small amount of perfectionism I have.
>
> — Rob
>
>
> I have an experimental library that I use for testing these kinds of
> things. There are aspects of it that I could work with to make use of
> function autoloading. Thus, I did so and benchmarked the performance of
> unit tests. The unit testing library makes a ton of "unqualified function
> calls".
>
> I spent some time working on two autoloaders:
>
>1. A naive autoloader: parses out the file to load, checks if it
>exists, and then requires the file.
>2. An optimized autoloader: only cares about the namespace it has
>registered. All others are an instant return.
>
>
Not to sound flippant, but you do realize that composer does a lot of
optimizations just like this, right?
PSR-4 exists in large part due to a realization that better optimizations
were possible when you mapped namespaces to source code directories. And
Composer takes it a step further when you have it create an optimized
loader, because then it maps classes directly to the files that provide
them, preventing I/O up to the point that a require is performed.
My point is that this is why folks have been suggesting that this is a
solved problem. Globally qualify functions, and you get immediate
performance benefits due to removal of the need to look up via the
namespace first. Most CS tools will even add the imports or qualifiers for
you, and you can have your IDE or editor configured to do it as well.
I wouldn't spend your time on this facet.
>1.
>
> In the "vanilla" case, I was mostly concerned with variation. I wanted a
> statistically significant result, so once I got my system into a stable
> state and I was no longer seeing any variance, I started benchmarking.
>
> For the naive autoloader, I saw a performance degradation of about 6% and
> lots of variability. This is probably due to the "file_exists" check being
> done every time an unqualified name was called.
>
> However, for the optimized autoloader, I ended up with less variability
> (🤔) than the vanilla approach and absolutely no measurable performance
> degradation.
>
> Now, time to try this on a larger scale... WordPress. It's pretty much the
> only large codebase I know of that makes use of tons of functions.
>
> — Rob
>
Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield wrote: > On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote: > > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard > wrote: > >> Hello internals, > >> > >> I have opened the vote for the mega deprecation RFC: > >> https://wiki.php.net/rfc/deprecations_php_8_4 > >> > >> Reminder, each vote must be submitted individually. > >> > >> > >> Best regards, > >> > >> > >> Gina P. Banyard > > > > > > The section "Deprecate using a single underscore ''_'' as a class name" > > indicates that probably the primary reason to deprecate it is a > > potential future conflict in the pattern matching RFC, where it can be > > used as a wildcard. > > > > However, I see no mention of this character as a wildcard anywhere in > that RFC. > > > > Can somebody clarify? > > The pattern matching RFC previously listed _ as a wildcard character. > > In the discussion a month ago, someone pointed out that `mixed` already > serves that exact purpose, so having an extra wildcard was removed. > > However, a few people indicated a desire to have an explicit wildcard _ > anyway, even if it's redundant, as it's a more common and standard approach > in other languages. We've indicated that we are open to making that an > optional secondary vote in the pattern matching RFC if there's enough > interest (it would be trivial), though I haven't bothered to add it to the > RFC text yet. > > Having _ available could also be used in other "wildcard" or "ignore this" > cases, like exploding into a list assignment or similar, though I don't > believe that has been fully explored. > Can you provide examples of what that usage would look like? And the question I have really is, does this actually _require_ using "_", or could another token be used for such matches? -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. > > > Best regards, > > > Gina P. Banyard > The section "Deprecate using a single underscore ''_'' as a class name" indicates that probably the primary reason to deprecate it is a potential future conflict in the pattern matching RFC, where it can be used as a wildcard. However, I see no mention of this character as a wildcard anywhere in that RFC. Can somebody clarify? -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from
On Sat, Jul 20, 2024, 9:31 AM Tim Düsterhus wrote: > Hi > > On 7/19/24 00:51, Christoph M. Becker wrote: > > And frankly, how much code would be affected? I mean, does anybody > > actually put a comment between `yield` and `from`? Is there a case > > where this may make sense? "Because we can" isn't a strong argument, in > > my opinion. > > I don't really follow this line of argumentation: > > If folks do not use the syntax anyways, then we do not need to have this > discussion, because the tools can just ignore it existing. That also > means we do not need to revert the change in PHP. > > If folks use the syntax, then reverting the change is a breaking change > for them. > By this line of reasoning, any bug that makes it into the engine that somebody finds a use for shouldn't be fixed. I totally understand wanting to keep this in, but because it made it in without an RFC, it's (a) inconsistent with other areas of the language, and (b) does not have a full design which includes tokenizer support. Considering the brief time it's been in the engine, and the fact that it's not documented, I feel it should be reverted and only re-added if someone takes the time and effort to propose the change properly. > >
Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript)
vel autoloader at this time. I'd argue we shouldn't add any more to the engine; the stack approach of spl_autoload_register() ensures we can reduce engine complexity and maintenance by offloading it to something that can evolve at a faster pace than the language. - I'm following the packaging threads closely, and the one thing I've failed to see a solid argument for is _what problems_ the current approach of using namespaced code doesn't address. I can definitely see a need for marking things as package private (i.e., not part of the publicly consumable API), but that also feels like something we could address in other ways. I know Larry has asked this same question before, and it's really what I want to see answered, because packages might be the solution, but there may be other approaches we could take that also accomplish those goals. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute
On Mon, Jun 24, 2024, 7:35 PM Stephen Reay wrote: > > Sent from my iPhone > > On 24 Jun 2024, at 23:43, Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > > > > > On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> >> Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a >> écrit : >> >>> >>> >>> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >>> wrote: >>> >>>> The vote for the RFC #[\Deprecated] attribute is now open: >>>> >>>> https://wiki.php.net/rfc/deprecated_attribute >>>> >>>> Voting will close on Wednesday 5th June, 08:00 GMT. >>>> >>> >>> The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) >>> votes, 79%. >>> >>> >>> The secondary vote to include Deprecated::$since has also been accepted >>> with 22 (Yes) to 1 (No) votes, 96%. >>> >>> >>> Thank you to everyone for voting! >>> >>> >>> Tim will finalize the implementation PR now and work on its merge in the >>> upcoming days. >>> >> >> Hi Benjamin, >> >> The vote for the RFC #[\Deprecated] attribute is now open: >>>> >>>> https://wiki.php.net/rfc/deprecated_attribute >>>> >>>> Voting will close on Wednesday 5th June, 08:00 GMT. >>>> >>> >>> The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) >>> votes, 79%. >>> >>> >>> The secondary vote to include Deprecated::$since has also been accepted >>> with 22 (Yes) to 1 (No) votes, 96%. >>> >>> >>> Thank you to everyone for voting! >>> >>> >>> Tim will finalize the implementation PR now and work on its merge in the >>> upcoming days. >>> >> >> Since the vote passed, we're discussing how we might use the attribute in >> Symfony. >> 2 things on the topic: >> >> 1/ We're wondering about using it at the class level despite the missing >> Attribute::TARGET_CLASS. ReflectionAttribute does allow reading >> attributes without checking these flags and we might leverage this >> capability to make our DebugClassLoader able to inspect those at the class >> level. >> >> Would you consider adding Attribute::TARGET_CLASS in 8.4 already? It >> would just make sense to me. We don't need the engine to do anything about >> deprecated classes ever since all we need in userland is a class-loader >> that checks for the attribute. Keeping the engine simpler and empowering >> userland with maximum flexiblity FTW. I'm up for a quick RFC if the >> consensus is this needs one. >> >> 2/ About the "since" parameter, we're going to standardize around a >> package+version string, e.g. >> #[Deprecated(since: "symfony/yaml v7.2"] >> >> I'm sharing this hoping this can spread outside of Symfony's boundary >> because I think this would be a very useful practice that'd allow building >> nice reporting tools. >> >> > Personally, I'd prefer the "since" format to mimic the notation that > Composer uses on the CLI when specifying a package with a constraint: > "symfony/yaml:7.2.0". This can be parsed easily, and won't suffer from > having arbitrary spacing and version naming prefixes. > > (Still would prefer a "scheduledRemoval" field, as knowing when it was > deprecated is far less interesting than knowing when it will be removed. > Yes, I can assume the next major version, but what if it's major version + > 1? What if a project allows removals during minor releases? Knowing what > version it will be removed in makes it far easier to understand what will > happen when I upgrade next.) > > > If you're marking a piece of code in a project as deprecated, why does > the deprecation notice need to re-specify the package the code is in? > Wouldn't a regular version string be sufficient? > Because the consumer of the code might not know what package supplied it, particularly if multiple packages share a namespace. > >
Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute
On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas < nicolas.grekas+...@gmail.com> wrote: > > > Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer a > écrit : > >> >> >> On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer >> wrote: >> >>> The vote for the RFC #[\Deprecated] attribute is now open: >>> >>> https://wiki.php.net/rfc/deprecated_attribute >>> >>> Voting will close on Wednesday 5th June, 08:00 GMT. >>> >> >> The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) >> votes, 79%. >> >> >> The secondary vote to include Deprecated::$since has also been accepted >> with 22 (Yes) to 1 (No) votes, 96%. >> >> >> Thank you to everyone for voting! >> >> >> Tim will finalize the implementation PR now and work on its merge in the >> upcoming days. >> > > Hi Benjamin, > > The vote for the RFC #[\Deprecated] attribute is now open: >>> >>> https://wiki.php.net/rfc/deprecated_attribute >>> >>> Voting will close on Wednesday 5th June, 08:00 GMT. >>> >> >> The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) >> votes, 79%. >> >> >> The secondary vote to include Deprecated::$since has also been accepted >> with 22 (Yes) to 1 (No) votes, 96%. >> >> >> Thank you to everyone for voting! >> >> >> Tim will finalize the implementation PR now and work on its merge in the >> upcoming days. >> > > Since the vote passed, we're discussing how we might use the attribute in > Symfony. > 2 things on the topic: > > 1/ We're wondering about using it at the class level despite the missing > Attribute::TARGET_CLASS. ReflectionAttribute does allow reading > attributes without checking these flags and we might leverage this > capability to make our DebugClassLoader able to inspect those at the class > level. > > Would you consider adding Attribute::TARGET_CLASS in 8.4 already? It > would just make sense to me. We don't need the engine to do anything about > deprecated classes ever since all we need in userland is a class-loader > that checks for the attribute. Keeping the engine simpler and empowering > userland with maximum flexiblity FTW. I'm up for a quick RFC if the > consensus is this needs one. > > 2/ About the "since" parameter, we're going to standardize around a > package+version string, e.g. > #[Deprecated(since: "symfony/yaml v7.2"] > > I'm sharing this hoping this can spread outside of Symfony's boundary > because I think this would be a very useful practice that'd allow building > nice reporting tools. > > Personally, I'd prefer the "since" format to mimic the notation that Composer uses on the CLI when specifying a package with a constraint: "symfony/yaml:7.2.0". This can be parsed easily, and won't suffer from having arbitrary spacing and version naming prefixes. (Still would prefer a "scheduledRemoval" field, as knowing when it was deprecated is far less interesting than knowing when it will be removed. Yes, I can assume the next major version, but what if it's major version + 1? What if a project allows removals during minor releases? Knowing what version it will be removed in makes it far easier to understand what will happen when I upgrade next.) -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] [Vote] New ext-dom features in PHP 8.4
On Thu, Jun 20, 2024, 1:27 PM Niels Dossche wrote: > On 20/06/2024 16:28, Matthew Weier O'Phinney wrote: > > > > > > On Mon, Jun 10, 2024 at 1:15 PM Niels Dossche <mailto:dossche.ni...@gmail.com>> wrote: > > > > Hi internals > > > > I'm opening the vote of my RFC "New ext-dom features in PHP 8.4". > > RFC link: https://wiki.php.net/rfc/dom_additions_84 < > https://wiki.php.net/rfc/dom_additions_84> > > Voting runs until 24th of June 21:00 GMT+2. > > > > Kind regards > > Niels > > > > > > Question: why is `Dom\Document::$head` marked as readonly? > > The HTML spec defines the head property to be readonly: > https://html.spec.whatwg.org/#document > That's why $head is marked readonly. > > So I guess the question becomes "why does the HTML spec define it this > way?" > I couldn't find a conclusive answer to this, it looks like this has been > read-only since HTML's early days... > I thought about it but don't really see a technical reason why this is the > case. If I had to take a guess I'd say it's for simplicity sake. > > he/him > I can understand that from a browser perspective, but from PHP, where we might be manipulating HTML to send back to the client, having it readonly would be a pretty big hindrance. >
Re: [PHP-DEV] [RFC] [Vote] New ext-dom features in PHP 8.4
On Mon, Jun 10, 2024 at 1:15 PM Niels Dossche wrote: > Hi internals > > I'm opening the vote of my RFC "New ext-dom features in PHP 8.4". > RFC link: https://wiki.php.net/rfc/dom_additions_84 > Voting runs until 24th of June 21:00 GMT+2. > > Kind regards > Niels > Question: why is `Dom\Document::$head` marked as readonly? -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
On Mon, Jun 3, 2024 at 9:46 AM Ilija Tovilo wrote: > Hi Matthew > > On Mon, Jun 3, 2024 at 3:15 PM Matthew Weier O'Phinney > wrote: > > > > On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer > wrote: > >> > >> The vote for the RFC #[\Deprecated] attribute is now open: > >> > >> https://wiki.php.net/rfc/deprecated_attribute > >> > >> Voting will close on Wednesday 5th June, 08:00 GMT. > > > > I have voted no for a few reasons: > > > > - Ideally, I'd like to be able to mark _anything_ as deprecated. In > particular, not being able to mark a _class/interface/enum/etc_ as > deprecated makes this far less useful. > > While it's true that extending #[Deprecated] to classes would be > useful, deprecation already exists as a language concept, and it can > be extended to class-like structures without a BC break. > Right, but I'd rather have the ability to have it _now_. It's far less often the case that I'm deprecating a single method or constant, and more often the case that I'm deprecating a class or interface. Not having support for those immediately makes the feature "meh" for me. > > > - The "since" parameter is basically worthless to me. It's very easy to > find out the last version that wasn't deprecated. What would be far more > useful to a consumer is an argument indicating when something will be > removed (e.g. $toRemoveInVersion, $versionForRemoval, etc.). This helps me > as a user plan for the future. > > Did you vote yes in the secondary vote by accident? I voted no on the > $since parameter for the same reason: > > * "How long have I not fixed this?" is not a particularly useful > question to ask. "When do I have to fix this?" is more relevant. > * The format of $since is intentionally left unstandardized, and it's > unclear (to me?) what it refers to. For example, some packages are > split into multiple, smaller ones (e.g. Doctrine) with diverging > version numbers. The sub-package version number may not be useful to > the end-user, who never requires it directly. Similarly, referencing > the main package version may be confusing, especially if the ranges of > recent main and sub-package versions overlap. > I voted yes on it because it's not _worthless_, and if the RFC passes, I'd rather have it than not have it. But I agree that the lack of a standard format for it, and the lack of a parallel "will remove by" argument make it far less useful. > > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer wrote: > The vote for the RFC #[\Deprecated] attribute is now open: > > https://wiki.php.net/rfc/deprecated_attribute > > Voting will close on Wednesday 5th June, 08:00 GMT. > I have voted no for a few reasons: - Ideally, I'd like to be able to mark _anything_ as deprecated. In particular, not being able to mark a _class/interface/enum/etc_ as deprecated makes this far less useful. - The "since" parameter is basically worthless to me. It's very easy to find out the last version that wasn't deprecated. What would be far more useful to a consumer is an argument indicating when something will be removed (e.g. $toRemoveInVersion, $versionForRemoval, etc.). This helps me as a user plan for the future. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] [Discussion] Add openStream() to XML{Reader,Writer}
On Tue, May 21, 2024 at 12:58 PM Claude Pache
wrote:
>
>
> > Le 18 mai 2024 à 01:13, Niels Dossche a écrit
> :
> >
> > On 22/04/2024 20:41, Niels Dossche wrote:
> >> Hi internals
> >>
> >> I'm opening the discussion for my RFC "Add openStream() to
> XML{Reader,Writer}".
> >> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams
> >>
> >> Kind regards
> >> Niels
> >
> > Hi internals
> >
> > The main complaint that kept coming up in internal communication was the
> choice of instance methods instead of static methods.
> > This has been brought up in this thread too.
>
> Hi,
>
> Now you have a complaint because of the choice of static methods instead
> of instance methods... :-)
>
> You are introducing an inconstancy for subclasses, because:
>
> * As noted in an earlier message, the existing open-like methods
> (XMLReader::XML() and XMLReader::open()) don’t work statically on
> subclasses (they create an instance of the base class, not of the
> subclass). You must use them as instance methods.
>
> * On the other hand, the method you are going to introduce won’t work as
> instance method. You must use it statically.
>
> Please, if you want to make the new method static only, fix first the
> existing ones, so that they also work statically (on subclasses).
>
> (But again, I prefer that all those methods work on instances, as it was
> the case before PHP 8. They shouldn’t have been switched to
> static-but-broken-for-subclasses without discussion.)
>
Fixing the existing ones would be a potential BC break, depending on
whether or not instance usage is completely eliminated.
The reason why many of us recommended static methods here is that they
would act as named constructors, and reduce the potential for cases where a
new stream is read from or written to mid-flight. Essentially, the usage
becomes:
$reader = XMLReader::fromStream($streamHandle);
// read the stream
and
$writer = XMLWriter::toStream($streamHandle);
// write to the stream
My understanding is that the implementations will allow for subclassing.
Having these as instance methods means that subclasses would need to
potentially add handling to ensure the instance is not in an invalid state
(e.g., by switching streams mid-flight), which would add far more edge
cases to handle.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
e no functional changes from doing so, but it’s > lots of renaming things both in the PR and the RFC. We are willing to do so > if the consensus is that it would be beneficial, but want to ask before > putting in the effort. > I personally would go with just "accessors". -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024 at 12:54 PM Larry Garfield wrote: > I am in support of this change. My only concern is timeline. This RFC > would deprecate it in 8.4, and presumably support would be removed in 9.0. > While we haven't discussed a timeline for 9.0, historically the pattern is > every 5 years, which would put 9.0 after 8.4, which means only one year of > deprecation notices for this change. > This is... not true. There is literally no established pattern for when major releases take place, either by length of time, or number of minor releases. PHP 3 had no minor releases. PHP 4 had 4 minor releases before PHP 5 dropped, and then a minor release happened AFTER PHP 5 was already in the wild (4.4). PHP 5 had 7 minor releases, with MULTIPLE YEARS between some of the minor releases before the current process was adopted towards the end of its lifecycle. We are moving TOWARDS a fairly standard process, but there's no definite plans for PHP 9 to follow after 8.4 as of yet, and the process does not require it. > > Given the massive amount of code that built up between 5.1 and 7.1, and > 7.1 and today, I worry that a year won't be enough time for legacy code to > clean up and it would be another "OMG you broke everything you evil > Internals !" like the "undefined is now warning" changes > in 8.0. (In both cases, well-written code any time from the past decade > has no issue but well-written code is seemingly the minority.) > But I DO agree with the above. So this might be a time for us to start discussing if/when we want a PHP 9 to occur. > > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] Reproducible Builds
On Tue, Nov 28, 2023, 5:28 PM Derick Rethans wrote: > On 28 November 2023 17:28:18 GMT, Sebastian Bergmann > wrote: > > >While we could probably replace __DATE__ and __TIME__ with > SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date > and time when the executable was built in the executable is actually > useful. How attached are we to having the date and time of the build in the > output of phpinfo(), "php -i", etc.? > > It is really useful for the development versions of PHP. Knowing whether > your are running a PHP-dev from last week or last month is important. Would Marco's suggestion of using a git hash solve that? You'd then get both a reproducible build AND know when/what it was generated from. > > > >
Re: [PHP-DEV] RFC Proposal: Readonly Structs in PHP
On Fri, Sep 8, 2023, 9:15 AM Lanre Waju wrote:
> Allowing Methods in Structs:
> Initially, I suggested that readonly structs have no methods besides the
> constructor. However, upon further consideration, I believe it may be
> beneficial to allow methods in structs. Even PHP enums allow methods, and
> considering this, I am open to discussing and potentially having a vote on
> allowing methods within structs as part of the RFC discussion.
>
At that point, a struct would be no different from a readonly class with
public properties, meaning we'd have two ways to accomplish the same thing.
Considering that a readonly class can already implement interfaces such as
JsonSerializable, Iterator, and ArrayAccess, they already solve the bulk of
the issues that have been raised in this thread.
The main thing of interest that I could see from your proposal was the
ability to nest a struct in another struct or a class definition, as that
could provide some interesting type safety without the need to declare new
classes. This could be even more interesting if it allowed _any_ struct
that fulfilled the same definitions:
class Post
{
public function __construct(
public readonly struct $author {
string $name;
UriInterface $uri;
UriInterface $avatarUri;
},
public readonly string $title,
public readonly string $content,
public readonly DateTimeInterface $publicationDate,
) {
}
// ...
}
struct User
{
string $name;
UriInterface $uri;
UriInterface $avatarUri;
string $email;
}
$post = new Post(new User(...), ...);
The idea here is that User fulfills the $author struct definition in the
Post class; it just has _additional_ properties. If the proposal would
allow that, this could be pretty powerful.
I would personally stay away from solving the conversion to and from arrays
and allowing methods. If users need those, they can either use
de/serialization libraries or readonly classes, respectively. Not including
them in the initial proposal keeps it more targeted, and demonstrates a
language feature that does not currently exist.
Re: [PHP-DEV] Windows PECL build machine died
On Sun, Apr 23, 2023, 3:33 PM Casper Langemeijer wrote: > Nothing seems to happen on this front, and our Windows users like to move > to PHP 8.2 too. > > The windows.php.net site states: "This is because the Windows PECL build > machine died, and the team is still working on the long term plan of > building DLLs for PECL extensions with a new CI process." > > We are 1 year since the machine died. 6 month since the statement on the > website. From the point of view of our users nothing has changed, and are > questioning if the windows project is still alive. > > I'd like to ask: Is re-inventing the building process really a smart thing > to do if it means we'll be out-of-service for more than a year? > > "We're doing our best to finish that as soon as possible, and keep you up > to date." > > I'm not questioning intentions, but I hate to think this is 'our best'. We > should at least have and share a more concrete plan, possibly share a rough > timeframe and share if we hit a blocking problem. If help is needed, we > should ask. > Just as an FYI, for anybody in this situation, we (Zend) are doing Windows builds of PHP; these have an E2E testing pipeline they pass before release. Current community-supported versions can be downloaded for free, and we provide LTS versions commercially. We support around 60 PECL extensions as well. Install instructions here: https://help.zend.com/zendphp/current/content/installation/windows_installation.htm Supported extensions list: https://help.zend.com/zendphp/current/content/installation/php_pecl%20extensions.htm >
Re: [PHP-DEV] [VOTE] include cleanup
On Thu, Feb 9, 2023 at 1:33 PM Max Kellermann wrote: > On 2023/02/09 19:04, Tim Düsterhus wrote: > > However based on the discussion of the RFC I believe that voters may have > > assumed that a "No" means "A cleanup is not allowed", because several > > participants expressed an active aversion to a cleanup during the > > discussion. As for myself I've certainly had that understanding when > casting > > my vote. > > Voting "NO" means no change - and currently, cleanup is not allowed, > which you can see from the fact that all of my code cleanups were > either rejected or reverted. > That's a poor interpretation of what happened. As Tim alluded, the current status quo is that cleanup is allowed on a case-by-case basis. The particular cases resulting from your PRs were rejected, but this doesn't mean all cases will be. I'm not directly involved in maintenance, but my take on the scenario was that these were rejected and reverted because they caused breakage, whether that was in compiling a spare PHP build, or in extensions that were assuming that using certain headers would slurp in everything they needed. This breakage was unacceptable without an RFC. I saw chatter from a number of folks after the changes were merged about builds no longer compiling; considering the stability of the php-src tree, inability to build will always be a source of alarm. What needs clarification in the RFC you've presented is that a "No" vote means "no change to current processes". Personally, I'd halt the current vote, make the change, and re-start the vote at this point to ensure everyone voting is clear on that point. > > Disallowing a clean-up would require 33% of votes, whereas allowing > > clean-up would require 66% of votes. The status quo "decide on a > > case by case basis" would no longer be legal even without a clear > > agreement. > > It is indeed unfortunate that a supermajority is required for all > primary votes, because in this case, requiring only a simple majority > would be favorable IMO. > A supermajority is required on any change that would lead to backwards incompatibility for either end-users or extension writers. Your proposal is something that would do the latter. Sure a simple majority is ALWAYS more favorable, but the hurdle exists to ensure that everyone pay attention to the BC implications when they vote. > It is not clear whether the current rule is "decide on a case by case > basis"; it has been argued that my code cleanup shall be > rejected/reverted because that would make merging branches harder. > > - If that alone is reason enough to reject/revert a code cleanup > change, then this applies to all kinds of code cleanup, and no code > cleanup is currently allowed. -> "case by case" doesn't count. > > - If that alone is NOT reason enough to reject/revert a code cleanup, > then more reasons need to be brought forward to hold my code > cleanups off. > As I pointed out earlier, the changes previously merged led to breakages when compiling the project. How is that not enough? And dumping a huge bunch of PRs with such changes without first discussing it with maintainers means a lot of effort reviewing — why are your proposed changes more important than any of the other work the various maintainers are doing? This is why they asked for an RFC; something of this magnitude needs discussion, because it impacts everybody already touching the project, the people most familiar with it. The other point that has been brought up multiple times is that it introduces breaking changes for extension maintainers. Should these extensions be relying on one or more "god" headers instead of the specific headers for the symbols they use? Probably not. Will forcing the issue without giving them a chance to review and understand the changes, and have a roadmap for when and how those changes occur be a net positive? No; it will cause a lot of busy work for a lot of people, almost all of whom are volunteers and most of whom would rather be building out user-requested features or fixing user-reported bugs. I'm unsure why that's unclear or not enough for you. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Fri, Aug 5, 2022, 12:09 PM Larry Garfield wrote: > Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > Asymmetric Visibility. > > https://wiki.php.net/rfc/asymmetric-visibility > > Details are in the RFC, but it's largely a copy of Swift's support for the > same. > I have two comments: - For reflection purposes, having two separate methods feels like it will be cumbersome; you'd need to check both to determine if you'd need to make the reflection property accessible before changing the value. An isPublicSet() would alleviate that, or potentially a getSetFlags() method against which you could apply a bit mask. You'd need to add a constant for public set I both cases. - The number of items that appear to the left of a property is growing, making understanding a declaration increasingly difficult, and your discussion of future scope indicates that this is likely to get worse. I'm wondering if this sort of behavior could be indicated via attributes instead? Something like `#[PropertySetBehavior(PROPERTY_SET_PRIVATE)]`. Attributes have the benefit of being separate from the property declaration, arguably more readable (one per line), and composable. This might play into some of the future scope items as well. Overall, though, love the design simplicity! > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4
On Thu, Nov 25, 2021, 12:17 PM Máté Kocsis wrote: > Sorry Folks, but I have to provide some update about the results: > > Unfortunately, due to a silly bug in my calculator code, the % differences > in the benchmark results were slightly off from their real values, so I > have just retroactively adjusted them. > In fact, the Symfony demo app on PHP 8.1 is ~23% faster than on PHP 7.4, > while Laravel runs ~21.5% faster on PHP 8.1 than on PHP 7.4. In my opinion, > this performance increase > is still very remarkable, so I'm not disappointed at all that the > improvement is slightly less dramatic than I previously suggested. Honestly, anything over 10% improvement when it comes to performance, particularly in a programming language, is significant. 20% can have a huge impact on production loads! In any > case, sorry for the misleading news! > > I wish a happy PHP 8.1 release party to everyone: > Máté >
Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues
On Thu, Nov 18, 2021, 7:32 AM Nikita Popov wrote: > On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT > wrote: > > > Le mer. 17 nov. 2021 à 13:30, Christoph M. Becker a > > écrit : > > > Right. An alternative might be to let users report security issues to > > > the security mailing list, where, if the issue turns out not to be a > > > security issue, the reporter could still be asked to submit a GH issue > > > about the bug. In that case it might be useful to add more devs to the > > > security mailing list. > > > > I was thinking about the same. Can't we work with security issues with > > mailing list *only*? > > It doesn't feel optimal to keep bugs.php.net active for just security > > ones. > > I miss seeing the motivation for it. > > > > The problem with the security mailing list is that it's ephemeral -- > someone new can't look at past discussions before they were subscribed. > Additionally, it's not possible to make the issue and the whole > conversation around it public after the issue has been fixed. > With Laminas, we use an email alias to allow researchers to report to us. We then post the full report as a security issue on GitHub - it's a feature they rolled out late 2019/early 2020 that restricts visibility to maintainers initially, but allows inviting others to collaborate (we invite the reporter immediately, for instance). It also creates a private branch for collaboration. When the patch has been merged, you can mark the issue public. If the plan is to move to GH anyways, this could solve security reporting. > Regards, > Nikita >
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On Fri, Nov 12, 2021, 3:41 PM Larry Garfield wrote: > On Fri, Nov 12, 2021, at 12:59 PM, Matthew Weier O'Phinney wrote: > > I recognize it's a bit late to be commenting, now that voting has > > started... but this feels like a solution for which we already have > > workable solutions, and which will instead lead to a lot of > > misunderstanding and breakage in the user ecosystem. > > > > Our IDEs, coding standards, and static analysis tools can already flag > > these things for us, helping us catch them early. Hell, unit testing will > > find these for us, when a test fails due to a value not being set in a > > property that we expected. > > > > Making this fundamental change to the language means, however, that a lot > > of things that we were previously able to do that "just worked" now > raise a > > deprecation notice, and, later, a compilation error... unless we make a > > change to our already working, fully functional code. > > > > I think the Locked Classes approach made far more sense here, because it > > didn't require changes to _working_ code. By making the behavior opt-in, > > developers get to choose if that's what they want for their classes, > > instead of having a backwards breaking change thrust on them. > > > > (Perhaps an even better solution would be a declaration, like we have for > > strict_types, which we could do per file.) > > > > Or maybe I'm missing something else: was there something at the engine > > level that was driving this, a significant performance gain we get from > > changing the behavior? Because if there was, there was no discussion of > it. > > In fact, the only discussion of "why" in the RFC is "In modern code, this > > is rarely done intentionally". Why is that justification for changing the > > behavior? Can you quantify how much code would be affected by this > change? > > and how much would benefit? > > > > Yes, I know that code I write would benefit from it, and personally I'd > > love to have a way to opt-in to something more strict - but I think a > > switch like this is going to make upgrading to version 9 difficult if not > > impossible for a huge number of PHP users. > > > > Sweeping changes like this need data behind them. If there's such data > for > > this RFC, it's not present in the proposal, and as such, I cannot > > understand what drives it. > > The original version of the RFC would have (as of v9) allowed for the > removal of some fugly code in property handling, resulting in engine > improvements and some minor performance benefits. That was because it > pushed the opt-in mechanism to "only if you extend stdclass", and stdclass > would effectively have a trait with stock __get/__set implementations to > handle dynamic property behavior. (It wasn't quite that, but effectively > that's what it would do.) So that was the original impetus. > None of that information was in the RFC. That sort of thing really needs to be included, as it helps a ton in justifying changes of this nature. As I noted, on reading it, the only rationale made is a quick mention that they lead to programming errors, and even then, there's no detail really if _how_. > The current version doesn't actually remove the behavior yet, so it > wouldn't allow for that optimization. That does, I agree, weaken its > argument, but as the RFC notes makes it easier in the future to figure out > how widespread dynamic properties actually are in code today. Right now... > we simply don't know. It's possible the impact here will be almost nil, or > it could break anything written before 2010. (I'd guess it's closer to the > former than the latter, but no one knows for certain.) Just grepping for > the attribute in the future would give us a better picture of how common it > is. > That's the thing: it's guesswork. About a fundamental way the object model works. While most library code may not make use of it, I can think of a number of ways I've seen it used or used the feature myself without even trying too hard: - In unit tests, to create quick spies to pass into closures. - In API wrappers, to represent payloads of specific types. (This is particularly interesting, as it allows for these wrappers to be forward compatible with additions to the API payload). - As internal DTO messages, particularly when prototyping. I get the benefits of a typed object without needing to fully define its properties. And that's just off the top of my head. > To those that are arguing that the timeline is too aggressive, I would > turn the ques
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
I recognize it's a bit late to be commenting, now that voting has started... but this feels like a solution for which we already have workable solutions, and which will instead lead to a lot of misunderstanding and breakage in the user ecosystem. Our IDEs, coding standards, and static analysis tools can already flag these things for us, helping us catch them early. Hell, unit testing will find these for us, when a test fails due to a value not being set in a property that we expected. Making this fundamental change to the language means, however, that a lot of things that we were previously able to do that "just worked" now raise a deprecation notice, and, later, a compilation error... unless we make a change to our already working, fully functional code. I think the Locked Classes approach made far more sense here, because it didn't require changes to _working_ code. By making the behavior opt-in, developers get to choose if that's what they want for their classes, instead of having a backwards breaking change thrust on them. (Perhaps an even better solution would be a declaration, like we have for strict_types, which we could do per file.) Or maybe I'm missing something else: was there something at the engine level that was driving this, a significant performance gain we get from changing the behavior? Because if there was, there was no discussion of it. In fact, the only discussion of "why" in the RFC is "In modern code, this is rarely done intentionally". Why is that justification for changing the behavior? Can you quantify how much code would be affected by this change? and how much would benefit? Yes, I know that code I write would benefit from it, and personally I'd love to have a way to opt-in to something more strict - but I think a switch like this is going to make upgrading to version 9 difficult if not impossible for a huge number of PHP users. Sweeping changes like this need data behind them. If there's such data for this RFC, it's not present in the proposal, and as such, I cannot understand what drives it. On Fri, Nov 12, 2021 at 7:08 AM Nikita Popov wrote: > Hi internals, > > I've opened the vote on > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close > 2021-11-26. > > Regards, > Nikita > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] BC breaking changes in PHP 8.1
On Wed, Sep 22, 2021 at 9:39 AM Calvin Buckley wrote: > On Sep 22, 2021, at 11:24 AM, Matthew Weier O'Phinney < > mweierophin...@gmail.com> wrote: > > As somebody who's been contributing to and maintaining OSS libraries > > forever (since 2002), the pace of change of PHP is, frankly, ridiculous. > I > > can keep up with patches. I can keep up with new features. But BC breaks > > EVERY YEAR just creates churn. I've spent most of the past 18 months > doing > > nothing but ensuring libraries work on new PHP versions. I then get users > > angry that they aren't getting new features; if I don't update to the > > latest PHP version, I get other users angry they can't use the library on > > the newer PHP version. And with new PHP versions every year... I > > essentially have to update every 2-3 years regardless, and will lose > users > > if I don't do it every year. > > > > Figure out what the BC breaks are going to be, and do them all at once. > > It's far easier for the ecosystem to adapt to a big drop of BC breaks > every > > 3-5 years than it is every year. > > There’s merit to spacing it out - I doubt anyone wants another PHP 7 flag > day again. > > (Ask the Python people how they feel about moving all the breaking changes > to a single release…) > I can tell you now a lot of us OSS maintainers would prefer it to yearly updates. It might be a good idea not to assume, and instead actually do some scientific polling of users and ecosystem library/framework maintainers. Based on my conversations with other maintainers in the ecosystem, my experience is not isolated by any means. On top of that, I get to analyze the annual Zend user surveys, and the number one reason for people being on older PHP versions (and > 50% of respondents are, EVERY YEAR) is the cost of upgrading. Clearly, there's a perception that something is broken with the current approach, and internals is ignoring it. BTW, another good possibility, recommended by somebody responding to a twitter thread I started around this issue: work with RectorPHP to provide a ruleset for each minor release, to ease upgrades. It's far easier than having to read through an UPGRADING guide and having to figure it out for yourself. I'd argue these should be in place as soon as a beta is ready. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] BC breaking changes in PHP 8.1
On Wed, Sep 22, 2021 at 9:01 AM G. P. B. wrote:
> On Wed, 22 Sept 2021 at 14:30, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>> Yesterday, I opened an issue regarding a change in the pgsql extension (
>> https://bugs.php.net/bug.php?id=81464).
>>
>> PHP 8.0 introduced the concept of "resource objects". Where previously we
>> would have resources, and use `get_resource_type()` when we needed to
>> differentiate various resources, resource objects give us immutable
>> objects
>> instead that allow us to type hint. Personally, I think this is wonderful!
>>
>> The rollout for 8.0 was incomplete, however, and only touched on something
>> like 4-6 different resource types. Still, a good start.
>>
>> With PHP 8.1, we're seeing the addition of more of these, and it was
>> encountering one of those changes that prompted the bug I previously
>> linked
>> to.
>>
>> Here's the issue: while overall, I like the move to resource objects,
>> introducing them in a MINOR release is hugely problematic.
>>
>> Previously, you would do constructs such as the following:
>>
>> if (! is_resource($resource) || get_resource_type($resource) !==
>> $someSpecificType) {
>> // skip a test or raise an exception
>> }
>>
>> Resource objects, however:
>>
>> - Return `false` for `is_resource()` checks.
>> - Raise a warning for `get_resource_type()` checks, and/or report the
>> resource object class name — which differs from the previous resource
>> names
>> in all cases.
>>
>> This means conditionals like the above BREAK. As a concrete example, I did
>> PHP 8.1 updates for laminas-db last week, and assumed our postgres
>> integration tests were running when we finally had all tests passing
>> successfully. However, what was really happening was that our test suite
>> was testing with `is_resource()` and skipping tests if resources were not
>> present. We shipped with broken pgsql support as a result, and it wasn't
>> until test suites in other components started failing that we were able to
>> identify the issue.
>>
>> Further, the "fix" so that the code would work on both 8.1 AND versions
>> prior to 8.1 meant complicating the conditional, adding a `! $resource
>> instanceof \PgSql\Connection` into the mix. The code gets unwieldy very
>> quickly, and having to do this to support a new minor version was
>> irritating.
>>
>> When I opened the aforementioned bug report, it was immediately closed as
>> "not an issue" with the explanation that it was "documented in UPGRADING".
>>
>> This is not an acceptable explanation.
>>
>> - There was no RFC related to 8.1 indicating these changes were happening.
>> (In fact, there was no RFC for resource objects in the first place — which
>> is concerning considering the BC implications!)
>> - In semantic versioning, existing APIs MUST NOT change in a new minor
>> version, only in new major versions.
>>
>> Reading the UPGRADING guide, there's a HUGE section of backwards
>> incompatible changes for 8.1 — THIRTY-FOUR of them. Nested in these are
>> notes of around a half-dozen extensions that once produced resources now
>> producing resource objects.
>>
>> The pace of change in PHP is already breathtaking when you consider large
>> projects (both OSS and in userland); keeping up with new features is in
>> and
>> of itself quite a challenge. Introducing BC breaks in minor versions makes
>> things harder for everyone, as now you have to figure out not only if
>> there's new features you want to adopt, but whether or not there are
>> changes that will actively break your existing code. I strongly feel that
>> anything in the backwards incompatible section of the UPGRADING guide
>> should be deferred to 9.0, when people actually expect things to change.
>>
>
> Resource to object conversions have precedent for not being in a major
> version:
> GMP in PHP 5.6
> Hash in PHP 7.2
>
> The fix to how to check these conditions is the same as last year and it
> is to check against false, not is_resource nor an instance of the class.
> It is true that if you ensure that the resource type is correct it gets
> slightly unwieldy but:
>
> if ($resource !== false && ((is_resource($resource) &&
> get_resource_type($resource) === $someSpecificType) || $resource instanceof
> ClassName) ) {
> // skip a test or raise an exception
> }
>
> Should be identical to the changes made to suppor
[PHP-DEV] BC breaking changes in PHP 8.1
Yesterday, I opened an issue regarding a change in the pgsql extension (
https://bugs.php.net/bug.php?id=81464).
PHP 8.0 introduced the concept of "resource objects". Where previously we
would have resources, and use `get_resource_type()` when we needed to
differentiate various resources, resource objects give us immutable objects
instead that allow us to type hint. Personally, I think this is wonderful!
The rollout for 8.0 was incomplete, however, and only touched on something
like 4-6 different resource types. Still, a good start.
With PHP 8.1, we're seeing the addition of more of these, and it was
encountering one of those changes that prompted the bug I previously linked
to.
Here's the issue: while overall, I like the move to resource objects,
introducing them in a MINOR release is hugely problematic.
Previously, you would do constructs such as the following:
if (! is_resource($resource) || get_resource_type($resource) !==
$someSpecificType) {
// skip a test or raise an exception
}
Resource objects, however:
- Return `false` for `is_resource()` checks.
- Raise a warning for `get_resource_type()` checks, and/or report the
resource object class name — which differs from the previous resource names
in all cases.
This means conditionals like the above BREAK. As a concrete example, I did
PHP 8.1 updates for laminas-db last week, and assumed our postgres
integration tests were running when we finally had all tests passing
successfully. However, what was really happening was that our test suite
was testing with `is_resource()` and skipping tests if resources were not
present. We shipped with broken pgsql support as a result, and it wasn't
until test suites in other components started failing that we were able to
identify the issue.
Further, the "fix" so that the code would work on both 8.1 AND versions
prior to 8.1 meant complicating the conditional, adding a `! $resource
instanceof \PgSql\Connection` into the mix. The code gets unwieldy very
quickly, and having to do this to support a new minor version was
irritating.
When I opened the aforementioned bug report, it was immediately closed as
"not an issue" with the explanation that it was "documented in UPGRADING".
This is not an acceptable explanation.
- There was no RFC related to 8.1 indicating these changes were happening.
(In fact, there was no RFC for resource objects in the first place — which
is concerning considering the BC implications!)
- In semantic versioning, existing APIs MUST NOT change in a new minor
version, only in new major versions.
Reading the UPGRADING guide, there's a HUGE section of backwards
incompatible changes for 8.1 — THIRTY-FOUR of them. Nested in these are
notes of around a half-dozen extensions that once produced resources now
producing resource objects.
The pace of change in PHP is already breathtaking when you consider large
projects (both OSS and in userland); keeping up with new features is in and
of itself quite a challenge. Introducing BC breaks in minor versions makes
things harder for everyone, as now you have to figure out not only if
there's new features you want to adopt, but whether or not there are
changes that will actively break your existing code. I strongly feel that
anything in the backwards incompatible section of the UPGRADING guide
should be deferred to 9.0, when people actually expect things to change.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
[PHP-DEV] Follow-up to STH user experience, this time with actual testing
sion. Additionally, it poses potential problems in terms of different testing results based on which mode you run in, leading to ambiguity for users. The only way to address the latter as a library author is to specify which mode your code is known to run in. Ironically, I'm seeing STHcoerce as more strict than STHv5 in terms of type handling, due to the fact that every call, userland or internal, is affected. The fact that it's always on makes it simpler for me to test against it now, and makes it easier to make my existing code both forward-compatible and more correct — even if I do not add type hints until I update my minimum supported version to PHP 7. I am slightly worried about the amount of work needed to make code run from v5 to v7 if STHcoerce is adopted. That said, the issues I found in PHPUnit were corrected in minutes (though a more thorough patch that allows early return from methods if doc comments are not strings would be better), and my own library's tests ran without problems once the PHPUnit issues were corrected (both code with and without typehints). Strict_types is definitely interesting, but I found that strict_types mode was more or less how I wanted code to operate, and to opt-in to that means changes to every file in my library — which is a much larger migration problem. In the end: kudos to everyone who is working on these patches and RFCs. I'm excited about scalar type hints in PHP 7! -- Matthew Weier O'Phinney Principal Engineer Project Lead, Zend Framework and Apigility matt...@zend.com http://framework.zend.com http://apigility.org PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User perspective on STH
On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara wrote:
> And what about other languages that have exactly this behavior? Such
> as Go/Hack/Haskell/etc. Do you see casts everywhere? No. You see them
> where it needs to be explicit. Otherwise, people just write using the
> correct types.
>
> And it also hand-waves over the fact that the same problem exists with
> coercive types. You're going to get the error anyway if you try to
> pass "apple" to an int parameter. So if someone was going to cast with
> strict, they will cast with coercive.
True. But you're also hand-waving over a point I brought up: many,
many input sources for PHP return strings: HTTP calls, database calls,
etc. With coercive mode, I can pass these values on to other function
calls without a problem; with strict mode, I cannot; I MUST cast
first.
>> If I don't enable strict mode on my code, and somebody else turns on strict
>> when
>> calling my code, there's the possibility of new errors if I do not perform
>> validation or casting on such values. This means that the de facto standard
>> will
>> likely be to code to strict (I can already envision the flood of PRs against
>> OSS
>> projects for these issues).
>
> Incorrect. The only person that can turn on strict mode is you, the
> author. Now someone can install your library, and edit it to turn on
> strict mode (add the declares at the top of the file). But that's very
> different from what strict proposes.
Okay, I'm confused then.
Let's consider this scenario:
I have a library. It does _not_ declare strict. It _does_ make calls
to either a web service or a database. Let's get even more specific:
the code does _not_ define any _scalar_ type hints, but accepts a
callable.
function execute(callable $callback)
{
// fetch some data from a web service or database,
// gather item1 and item 2 from it,
// and pass the data on to the callback, which was passed to us.
// Assume that we know that item1 is an int-like value, and
item2 is a string-like value.
$callback($item1, $item2);
}
You, as a consumer, declare your script in strict mode, and make a
call to my own code.
declare(strict_types=1);
// somehow import the above function
$callback = function (int $item1, string $item2) {
// do something with the items...
};
execute($callback);
How does that operate?
https://wiki.php.net/rfc/scalar_type_hints_v5 indicates that the
caller determines strict mode, but I'm unclear what the scope of that
is: does it bubble down the entire stack? or does strict only apply to
the specific calls made (i.e., before it reaches the function/method
declared in the other file)? What happens when $callback is executed,
and $item1 is '10'? Is it interpreted strictly, or weakly? Where is
the boundary for where strict happens, exactly?
If strict only applies to the execute() invocation, and doesn't apply
to $callback or the calls made to the web service or database, then I
can retract my statements; however, if the strict applies all the way
down the stack from the caller, I can see definite issues. That's what
I'm worried about.
> However, with 2/3 of the options presented in the coercive RFC, you'll
> have an INI setting that changes the behavior of your code for you
> (the other 1/3 is potentially a significant BC break). How is that
> better than a per-file switch? Something you as a library developer
> have no control over...
Personally, I'd prefer no INI switch, but I also recognize the BC
problems with that RFC. I want to note now, I'm not saying I support
either RFC specifically; my concern is with the dual-mode aspect of
the STH v0.5 (and predecessors).
>> This is what I want from STH, no more no less: sane casting rules, and the
>> ability to code to scalar types safely. While I can see some of the benefits
>> of
>> strict mode, I'm concerned about the schism it may create in the PHP library
>> ecosystem, and that many of the benefits of the coercive portion of that RFC
>> will be lost when working with data from unknown data sources.
>
> Considering the strict mode is file-local, it's not all or nothing.
> It's up to the author writing code to determine how to handle the
> calls (s)he will make.
And, as noted, that's the part I need clarification on: is it really
local only to calls made directly in that file, or does strict follow
all the way down the chain?
Finally, there's the other aspect of type casting coercion from the
competing RFC, https://wiki.php.net/rfc/coercive_sth. The tables in
there make a lot of sense to me, as do the eventual ramifications on
language consistency. If dual-mode is really restricted only to th
[PHP-DEV] User perspective on STH
ing less code to accomplish the same thing; it just gives me a tool to check
the correctness of my code. (Yes, this _is_ important. But we also have a ton of
tooling around those concerns already, even if they aren't proper static
analyzers.)
>From a developer experience factor, I find myself scratching my head: what are
we gaining with STH if we have a strict mode? I'm still writing exactly the same
code I am today to validate and/or cast my scalars before passing them to
functions and methods if I want to be strict.
The new coercive RFC offers much more promise to me as a consumer/user of the
language. The primary benefit I see is that it provides a path forward towards
better casting logic in the language, which will ensure that — in the future —
this:
$value = (int) $value;
will operate properly, and raise errors when data loss may occur. It means that
immediately, if I start using STH, I can be assured that _if_ my code runs, I
have values of the correct type, as they've been coerced safely. The lack of a
strict mode means I can drop that defensive validation/casting code safely.
My point is: I'm sick of writing code like this:
/**
* @param int $code
* @param string $reason
*/
public function setStatus($code, $reason = null)
{
$code = filter_var(
$value,
FILTER_VALIDATE_INT,
FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX
);
if (false === $code) {
throw new InvalidArgumentException(
'Code must be an integer'
);
}
if (null !== $reason && ! is_string_$reason) {
throw new InvalidArgumentException(
'Reason must be null or a string'
);
}
$this->code = $code;
$this->reason = $reason;
);
I want to be able to write this:
public function setStatus(int $code, string $reason = null)
{
$this->code = $code;
$this->reason = $reason;
);
and _not_ push the burden on consumers to validate/cast their values.
This is what I want from STH, no more no less: sane casting rules, and the
ability to code to scalar types safely. While I can see some of the benefits of
strict mode, I'm concerned about the schism it may create in the PHP library
ecosystem, and that many of the benefits of the coercive portion of that RFC
will be lost when working with data from unknown data sources.
If you've read thus far, thank you for your consideration. I'll stop bugging you
now.
--
Matthew Weier O'Phinney
Principal Engineer
Project Lead, Zend Framework and Apigility
matt...@zend.com
http://framework.zend.com
http://apigility.org
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
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 2012-07-16, Andrew Faulds wrote:
> An ugly, confusion-causing syntax.
I'm sorry, but how does this add _anything_ to the discussion?
Qualify your statement, please. What do you find "ugly" about the
syntax, and why? Where do you see confusion arising from the syntax -
what problems do you foresee arising?
Making judgmental statements without any context like the one you made
above does nobody any good, and if you can't find the time to qualify
them properly, it'd be better for everybody if you simply didn't post.
> On 16 July 2012 14:11, Nikita Popov wrote:
>> On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard wrote:
>>> Hi,
>>>
>>> Here is an RFC proposal about a syntax extension for PHP. The purpose is to
>>> manage precisely the visbiliy of attributes, by separating reading and
>>> writing access.
>>>
>>> First of all, I know there is already an RFC about attributes ("Property
>>> get/set syntax" [1]). Its goal is mainly different, but I'll discuss it
>>> lower.
>>
>> I'm not sure I really understand what this adds over the existing
>> getter/setter proposal. read-only and write-only should cover the most
>> common cases. If you do need visibility control, it is possible too:
>>
>> public $property {
>> get { ... }
>> protected set { ... }
>> }
>>
>> So what does this proposal add to it?
>>
>> Nikita
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
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 2012-07-16, Amaury Bouchard wrote:
> --f46d0446312cc5e06104c4f42161
> Content-Type: text/plain; charset=ISO-8859-1
>
> My point is not to add two ways to do the same thing.
> What I'm humbly suggesting to do is to keep the core idea of the
> existing RFC (make things easier when you have to write
> getters/setters), and think about another syntax for managing reading
> and writing visibilities.
My first impression, being familiar with the other proposal, was that
this looked like duplication. However, on looking at the examples, I
have to admit that I really like the approach -- in many cases, it
obviates the need for a getter entirely. It would help dry up a lot of
code, reduce the number of method calls overall, and still enforce
internal logic when setting the value in the first place.
I like it; it feels elegant.
> 2012/7/16 Andrew Faulds
>
>> How much syntactic sugar do we really need? Why add two ways to do
>> something?
>>
>> On 16 July 2012 16:24, Amaury Bouchard wrote:
>> > 2012/7/16 Nikita Popov
>> >
>> >> I'm not sure I really understand what this adds over the existing
>> >> getter/setter proposal. read-only and write-only should cover the most
>> >> common cases. If you do need visibility control, it is possible too:
>> >>
>> >> public $property {
>> >> get { ... }
>> >> protected set { ... }
>> >> }
>> >>
>> >> So what does this proposal add to it?
>> >>
>> >>
>> > 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.
>>
>>
>>
>> --
>> Andrew Faulds (AJF)
>> http://ajf.me/
>>
>
> --f46d0446312cc5e06104c4f42161--
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
shortcut ternary. Thus, not as
>useful as is_null.
>6. (indexing w/o notices) ?
>7. (variable access) Probably do more harm than good. It's easy to
>ensure a variable is set.
>8. (assign-if-not-set) For arrays, there's the alternative:
>
>$arr += Array('key' => 'value');
>
>This can also be used for a "never-unset" style to set defaults for an
>array, which goes with the "! is_null($a) ? $a : dflt" pattern.
>
> Various syntax proposals:
>
>1. "$a ?? $b : dflt" as a ternary, with shortcutting behavior.
>2. "$a ?? dflt" as a shortcut ternary
>3. "$a ?! dflt" as a shortcut ternary based on !empty (could be added
>along with "??"; objection is that it could ambiguate PHP's syntax,
>conflicting with the not operator)
>4. "$a $: dflt" as a shortcut ternary
>5. "$arr?['key']" to suppress undefined index notices
>6. "$arr@['key']" to suppress undefined index notices
>7. "$?var" to suppress undefined variable notices
>8. "$a ??= dflt" as an assign-if-not-set operator (goes along with "??")
>9. "$a !?= dflt" as an assign-if-not-set operator ("!" suggests not-set)
>10. "$a $:= dflt" as an assign-if-not-set operator (goes along with "$:")
>
>
> ?? / isset vs ?? / is_null
>
> Of the various proposals, "??" (with semantics of "isset($a) ? $a : dflt")
> already has a precedence: in C# as the null-coalescing operator. While PHP
> doesn't have non-nullable types (hence "??" isn't a necessity), using ?? is
> perhaps the least surprising option, and (including "??=") would cover
> use-cases 1 and 4. On the other hand, PHP's "??" wouldn't be the same as
> C#, since C# requires that variables be declared. Arguably, having "??"
> equivalent to "!is_null($a) ? $a : dflt" is closer to C# semantics. Also,
> use-cases 2 and 3 would be left out, whereas operator proposals 4 (?? /
> is_null), 6 (?[]) and 8 (??= / is_null) together cover use-cases 1, 3 and
> 4. Back on the first hand, use-cases 2 and 3 are less common and this is
> (after all) merely syntactic sugar, which should be targeting the common
> cases.
>
> ??: vs ??
>
> The ternary "??:" (whether based on isset or is_null) can also cover
> use-case 5, but isn't so good for case 4 ("??:=" would be ugly). One one
> hand, the short-cut "??:" may be surprising to developers familiar with
> C#'s "??:". On the other, PHP ain't C#, and documentation can cover "??:".
> Besides, "??" isn't the only null-coalescing operator out there, so why
> should C# be given special consideration? Less rhetorically, would
> supporting both "??" and "??:", with "$a ??: dflt" equivalent to "$a ?? dflt",
> be undesirable?
>
> Personally, I support syntaxes 8. ??= with either 1. ??: / isset or
> (1. ??:/ is_null and 5.
> ?[]).
>
> --0016e6d64661f7e32504c521836f--
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Make try/catch brackets optinal
On 2012-07-19, "Ivan Enderlin @ Hoa" wrote:
> As you certainly know, brackets defining blocks in PHP are optional if
> blocks contain a single instruction. Thus:
>
> if($condition) {
> echo 'foobar';
> }
>
> is strictly equivalent to:
>
> if($condition)
> echo 'foobar';
>
> But this syntactic sugar is not applied uniformly to all PHP language
> constructions. I have the try/catch couple in mind.
> First, I would like to know why it is not possible to write:
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
> var_dump($e->getMessage());
>
> as a strict equivalence of:
>
> try {
> throw new Exception('foobar');
> }
> catch(Exception $e) {
> var_dump($e->getMessage());
> }
>
> Second, if it is possible, could we plan to have this “feature”
> (uniformity actually) in PHP6 (or maybe before)?
I'd hesitate to call this a feature. If anything, for PHP6, I'd
recommend the opposite: getting rid of brace-less blocks, period.
I've read through the thread, and those proposing it talk about code
readability, and use the argument "I've never had a problem before." To
me, this means you've either (a) not been developing very long, and/or
(b) not been working in long-lived projects, and/or (c) do not work with
other people. Omitting braces makes understanding the intent of the
code harder (did the author intend to only execute one statement, or did
they forget the braces?), makes maintenance harder (a developer needing
to add extra statements now also has to add the braces), and leads to
hard-to-detect bugs (see previous two points).
I've run into problems with brace-less blocks many, many times over
the years. Clearly, enough other people have as well that any serious
coding standard includes a clause requiring that all blocks use
braces. I see no reason to add another context in which braces could
be omitted.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-07-13, "Eugene Leonovich" wrote:
> I'm a bit confused by the "class" keyword in the syntax ClassName::class.
> We already have the magic constant __CLASS__ which does exactly the same
> class name resolving, if you refer it within the class.
>
> So why to introduce a new keyword instead of using __CLASS__, like
> ClassName::__CLASS__?
"class" is already a keyword, making it a simpler, easier to remember, and
easier to type choice.
> "Ralph Schindler" wrote in message
> news:4f89d4f1.8070...@ralphschindler.com...
>> Hi all,
>>
>> There are many different use cases were in code we expect classes names as
>> arguments to functions as fully qualified names. We do this in ZF a lot
>> with our Service Location and DI components, but also with our code
>> reflection API, etc. A more interesting use case I would like to call out
>> is with PHPUnit, for example in a test, you might find this:
>>
>> $mock = $this->getMock('A\Namespaced\ClassName');
>>
>> This becomes cumbersome when you are dealing with lots of strings about
>> lots of class names. This is also an area where, currently, namespace
>> declaration and use statements offer no real support.
>>
>> The patch located here:
>>
>> https://github.com/ralphschindler/php-src/commit/02210d51851a96d723fbedcfc64cde9f9ae2b22a
>>
>> ... implements the ability for a developer to leverage the file's
>> namespace declaration and use statements to be able to produce a scalar
>> (string) of the class name that can be then used, for example, as an
>> argument to a function elsewhere.
>>
>> This overloads the "class" keyword, and by virtue of the existing usage of
>> "class" this feature is completely backwards compatible. All existing
>> tests pass. For example, the above PHPUnit snipped would become:
>>
>> use A\Namespaced\ClassName;
>> $mock = $this->getMock(ClassName::class);
>>
>> Another example with reflection:
>>
>> use SomeOther\FullyNamespaced\ClassElsewhere as CE;
>> $r = new ReflectionClass(CE::class);
>>
>> More examples from the test file:
>>
>> namespace Foo\Bar {
>> class Baz {}
>> var_dump(Moo::CLASS); // "Foo\Bar\Moo"
>> }
>>
>> namespace {
>> use Bee\Bop as Moo,
>> Foo\Bar\Baz;
>>
>> var_dump(Baz::class); // "Foo\Bar\Baz"
>> var_dump(Boo::class); // "Boo"
>> var_dump(Moo::CLASS); // "Bee\Bop"
>> var_dump(\Moo::Class); // "Moo"
>>
>> $class = Baz::class; // assign class as scalar to var
>> $x = new $class;
>> var_dump($x); object(Foo\Bar\Baz)#1 (0) {}
>> }
>>
>>
>> What do you guys think?
>>
>> -ralph
>
>
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On 2012-07-13, David Muir wrote:
> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
> > On 2012-07-12, Sara Golemon wrote:
> > > --e89a8f235453d7a80104c4975c55
> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara
> > > wrote:
> > > > One thing to keep in mind when doing this is to think about consistency.
> > > > I think that's a huge point not to be taken lightly. For that reason, I
> > > > think that this API should not be used for any of the array_* functions.
> > > > Meaning that array_sum(), etc should all take arrays only.
> > > >
> > > > Then, other non-array functions (such as str_replace, etc) can be
> > > > modified
> > > > to use this new method.
> > > >
> > > > Just my $0.02 anyway...
> > > >
> > > Sounds like everyone agrees the API is useful, just question marks over
> > > which existing methods should profit by it.
> > >
> > > To add my $0.02, it'd be nice to work in a zend_parse_parameters() type
> > > for
> > > this. Keep extension code clean and ensures any temporary iterators get
> > > destructed.
> > Another note: if this comes to fruition, since arrays and traversable
> > objects
> > would in many cases be interchangeable, it would be nice to have a
> > type-hint for
> > "array-like" behavior:
> >
> > function doSomething (ArrayLike $options) { ... }
> >
> > A better name could likely be used, but you get the idea.
>
> What about extending the array typehint include ArrayAccess, and extend
> the Traversable typehint to include arrays?
This would work for Traversable, as that interface does not define any methods,
and the only use case would be for iteration. This would answer most use
cases/issues I've had (need either an array or Traversable in order to iterate).
For arrays, however, it's a bit harder, as the reason for typehinting on array
may not be solely access of members, but _also_ iteration. As such, extending
the array typehint to include ArrayAccess could lead to issues when the object
implementing ArrayAccess does not also implement Traversable. I don't think this
would work at all semantically.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Iterable Type Hint
On 2012-07-12, Rasmus Lerdorf wrote: > On 07/12/2012 09:30 AM, Stas Malyshev wrote: > > > Would it be worth while adding a new type hint that checks for this > > > condition? I'd propose Iterable: > > > > I see more and more multiplication of weird ad-hoc type checks. First we > > had "callable", now "traversable", then we invent more and more weird > > functional types with complex logic. I don't like this development at > > all. It's ad-hoc introducing of half-baked, unstandartized, undesigned > > strict typing. Strict typing is not a good idea for PHP, and weird > > strict typing based on complex conditions hidden from the user is even > > worse IMO. > > For non-interchangeable types it is already strict by definition. I > don't see a problem with type hints that make life easier on both the > caller (by generating better error messages) and the callee (by having > to write less boilerplate type verification code). > > You may have a point on the ad-hoc nature of it and that we need to do > it once and for all in a more organized fashion, but the basic premise > looks ok to me. I wouldn't call it ad hoc, actually, but more a recognition of what practices and patterns are now occurring. A few years ago, I'd have type-hinted on array and been done with it. But more and more often, I'm interested in either an array or something Traversable, and I end up with boilerplate just like Anthony had in his original post on this thread. And I see it _everywhere_. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Iterable Type Hint
On 2012-07-12, Stas Malyshev wrote: > > For non-interchangeable types it is already strict by definition. I > > don't see a problem with type hints that make life easier on both the > > caller (by generating better error messages) and the callee (by having > > to write less boilerplate type verification code). > > It doesn't make the life of the caller easier. On the contrary, it makes > each call into a minefield - will it blow up with a system-level error > when you call it? I think you're reading way more into this, or didn't read the same sample I did from Anthony. foreach() allows an array or a Traversable object. The proposal is to create a typehint that spans the set of (array + Traversable) so that folks don't have to do a check in each and every method where they want to accept both so they can iterate. I've written the same or similar checks to what Anthony posted hundreds of times, and seen it many, many more than that. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On 2012-07-12, Sara Golemon wrote:
> --e89a8f235453d7a80104c4975c55
> On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara wrote:
> > One thing to keep in mind when doing this is to think about consistency.
> > >
> >
> > I think that's a huge point not to be taken lightly. For that reason, I
> > think that this API should not be used for any of the array_* functions.
> > Meaning that array_sum(), etc should all take arrays only.
> >
> > Then, other non-array functions (such as str_replace, etc) can be modified
> > to use this new method.
> >
> > Just my $0.02 anyway...
> >
> Sounds like everyone agrees the API is useful, just question marks over
> which existing methods should profit by it.
>
> To add my $0.02, it'd be nice to work in a zend_parse_parameters() type for
> this. Keep extension code clean and ensures any temporary iterators get
> destructed.
Another note: if this comes to fruition, since arrays and traversable objects
would in many cases be interchangeable, it would be nice to have a type-hint for
"array-like" behavior:
function doSomething (ArrayLike $options) { ... }
A better name could likely be used, but you get the idea.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
On 2012-06-23, Stas Malyshev wrote: > > I'm open to changing or aliasing the name to array_pluck(), if others > > are in agreement. > > I wouldn't know what "pluck" means here. "Column" is a clear word with > established meaning. Let's not get too whimsical here. Nothing whimsical about it at all, Stas. The definition is: Take hold of (something) and quickly remove it from its place; pick and synonyms include "pull" and "gather". As Ralph noted, "column" is overloaded, as it has connotations dealing with databases as well as tables, and arrays often represent neither. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 2012-04-20, Kris Craig wrote:
> On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan
> wrote:
> > > But in order to be case insensitive, PHP needs to know that
> > > strtolower("A") == 'a'. So if you use Cyrilic for userland
> > > functions/classes, php needs a cyrillic aware strtolower function.
> > > Then the problem is that core classes/functions need to use a
> > > plain ASCII strtolower for case insensitivity. So you cannot both
> > > write code in cyrillic and interface with plain ASCII internals.
> > > One possible, but less than optimal solution is to first try a
> > > locale aware strtolower, then try a plain ascii strtolower when
> > > looking up symbols.
> >
> > I can see the confusion about PHP's case-sensitivity and how it mixes
> > and matches between case-insensitive functions/classes/(arguably even
> > constants), and case-sensitive variable names, for example.
> >
> > Its naming rules are a little bit inconsistent in that regard. I just
> > don't see a point in making it completely locale aware. The fact that
> > you can do soefunc() and SOMEFUNC() and still invoke the same function
> > is a benefit.
>
> Could you elaborate? Aside from making PHP forgiving of typos and overall
> laziness on the part of the coder, and of course BC notwithstanding, I'm
> not sure I understand what benefit there is to preserving this inconsistent
> behavior.
To make extensible and flexible systems, it's not uncommon to
dynamically determine class and function or method names. This task
is far simpler and less expensive if you don't need to worry about the
casing of these names.
As an example, I often see code like the following:
public function setOptions(array $options)
{
foreach ($options as $key => $value) {
$method = 'set' . $key;
if (!method_exists($this, $method)) {
continue;
}
$this->$method($value);
}
}
This is trivial to implement and understand, and requires no need to
transform the value of $key to an appropriately cased value in order to
ensure the method name exists.
Making method names case sensitive would break a ton of code, and
require a ton of computational overhead as well as validation to make
code like the above work.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Complete case-sensitivity in PHP
On 2012-04-20, "C.Koy" wrote: > This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) > which is a decade old. > > As the recent comments on that page indicate, there's not a > deterministic way to resolve this issue, apart from eliminating > tolower() calls for function/class names during lookup. Hence totally > case-sensitive PHP. > > Before opposing with "No, this will break a lot of existing code!", > note that I'm not suggesting a static permanent change in the engine; > rather a runtime option that will need to be enabled (cli option, INI > setting), without which PHP will work as before. > > Since I'm not well versed in the workings of Zend engine, I solicit > the wisdom/experience of people in this list: Is this doable in a > practical way, without making grand changes in Zend? It's not just about changes to the engine. If you introduce a runtime option that switches behavior, you then get a portability problem -- code runs fine in one context, but not the other. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
On 2012-04-20, Christoph Hochstrasser wrote: > Hi, > > Are the dashes acceptable or undesirable? > > I think without dashes it is more in line with other keywords, like > "instanceof" or "insteadof". > > Because keywords are not case sensitive, one who likes them to be more > readable could write them camelCased, for example "readOnly", or > "writeOnly". If they are to be keywords, I'd argue we should use the dash variant -- the reason being that with the dash, there can be no conflict with existing constant, variable, or function names. I know I've had a fair number of each named both "readonly" and "writeonly". -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On 2012-04-19, Yasuo Ohgaki wrote:
> Just a though for named parameter, since it seems
> its becoming a relevant topic now.
>
> 2012/4/18 Daniel Macedo :
> > I agree with this! But for short array syntax we kept the => as in
> > $array = ["foo" => "bar"];
> > Not sure if this was a limitation, lack of that suggestion or a
> > decision; but the shortest syntax it's still not... (as Yoda would
> > say!)
> >
> > $array = ["foo": "bar"]; doesn't look weird to me, plenty readable,
> > and that's the shortest!
>
> Object can be used as named parameter in JavaScript.
>
> // Define function to take one "argument", which is in fact an object:
> function fnParseInt( oArg ){
>return parseInt( oArg.number, oArg.radix );
> }
> // Which you then call like this (pass in an object literal):
> fnParseInt( { number : 'afy', radix : 36 } );
>
> If there is a JSON like syntax for PHP objects, named parameter
> can be implemented just like this. It would not work for function
> that accepts object as first parameter, but who cares?
This is the workaround many of us are already using, though typically
passing an array, not an object. With 5.4, the notation is almost
usable, as you can simply do the square brackets:
fnParseInt([ "number" => "afy", "radix" => 36 ]);
> Pros.
> - simple
> - everyone are used to JSON and JavaScript now a days
> - supporting JSON syntax is convenient for other purpose
> - internal functions may support this.
> (Single object parameter for this)
> - coexists func($a$b)
>
> Cons
> - loose type hints
> - loose default values for params
While the solution is indeed simple, the cons loom very large -- you
end up needing to perform a lot of logic internally in the function in
order to support default values as well as enforce types. That kind of
boilerplate gets very old after a while.
Named parameters would be ideal, but being able to skip parameters will
definitely work in the interim.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] skipping optional parameters
On 2012-04-19, Patrick ALLAERT wrote:
> 2012/4/18 Matthew Weier O'Phinney :
> > My one comment, which others have raised, is readability of multiple
> > commas -- TBH, at first glance it has the appearance of a mistake. I
> > think those suggesting a keyword such as "default" make a good point in
> > this regard -- it makes it 100% clear that you want the default value
> > for the argument in that position. This also presents an improvement
> > over current usage, as you're not hard-coding values in your function
> > calls themselves -- particularly as the defaults could change in future
> > refactors.
>
> I think we should only support optional parameters using the "default"
> keyword as it would probably make things more consistent and less
> error prone:
>
> function foo( $bar = "bar", $foo = "foo", $baz = "baz" ) { ... }
>
> foo(,,, "myBaz"); // Thinking changing the value of $baz, but there's
> one too much "," and PHP won't complain because of too many arguments
> used!
>
> Additionally, we might also want to think about
> call_user_func()/call_user_func_array().
>
> If for the former it could work with:
>
> call_user_func( "foo", , , "myBaz" );
>
> What about the latter?
>
> call_user_func_array( "foo", [2 => "myBaz"] ); // ? Evaluating the
> element at index 0 would cause a notice, but would result in a NULL,
> so I would say that NULL is to be used as first parameter.
I actually would argue you shouldn't skip parameters when using
call_user_func(); even with call_user_func_array(), I'd argue that named
parameters is the only way I'd want to allow skipping parameters.
The reason I argue this is because when dynamically calling a function,
you typically don't actually know exactly what the function/method is --
and thus making any assumptions about the signature other than required
parameters is simply begging for problems.
> Last but not least: if skipping optional parameters is implemented,
> should we consider the support of default values on the leftmost side
> of functions?
>
> function foo( $bar = "bar", $baz ) { ... }
>
> It could make sense that $bar followed by $baz is semantically better
> than the opposite for technical reason, and this could be called
> using:
>
> foo( default, "baz")
> or:
> foo(, "baz")
I'd argue no -- as required arguments should always have precedence over
optional ones in the signature when it comes to position.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] skipping optional parameters
On 2012-04-17, Stas Malyshev wrote:
> One of the annoying things I've encountered in working with PHP was
> dealing with functions having long optional parameter lists, especially
> if you need to change only the last one - you have to copy all the
> defaults. Full named params implementation would solve it, probably, but
> before we have that here's an easier solution for part of the problem:
>
> https://wiki.php.net/rfc/skipparams
>
> Basically, it allows you to do this:
>
> create_query("deleted=0", "name",,, /*report_errors*/ true);
I actually had a need for either this or named parameters this past
week, and as such would love to see one or the other in place. While I'd
personally prefer named arguments, this approach would work in most
places I've needed them.
My one comment, which others have raised, is readability of multiple
commas -- TBH, at first glance it has the appearance of a mistake. I
think those suggesting a keyword such as "default" make a good point in
this regard -- it makes it 100% clear that you want the default value
for the argument in that position. This also presents an improvement
over current usage, as you're not hard-coding values in your function
calls themselves -- particularly as the defaults could change in future
refactors.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Stas Malyshev wrote: > > May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but > > closer to what already exists for this semantic (class name as string), > > don't you think ? > > I like this. __CLASS__ is already being used as class name, and little > chance of colliding with some code since you're not supposed to be using > __ prefix in your names. "class" won't collide anyways, as it's already a keyword, and you can't use it in your constant or function names. __CLASS__ has bad connotations for me, as it resolves to the declaring class normally, not the class invoked. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Ralph Schindler wrote:
> Hi Nikita,
>
> > A quick note on the patch: As the class name is compile-time
> > resolvable it should in my eyes also be available as a
> > `static_scalar`, so that it can be used in initialization lists:
> >
> > public function doFoo($withClass = ABC::class) {
> > new $withClass; // or whatever
> > }
> >
> > To be available as both a `static_scalar` and a general `scalar` one
> > should put the rule in the `common_scalar` section.
> >
> > What do you think?
>
> I've added this to the patch and Zend/tests:
>
>*
> https://github.com/ralphschindler/php-src/compare/master...feature/class-name-scalar
>
> I've also added an RFC page, any thoughts on improving the RFC?
>
>* https://wiki.php.net/rfc/class_name_scalars
In the examples, you mix case:
Boo::class
Moo::Class
\Moo::CLASS
Make sure you note that this is intentional, and that the keyword is
case insensitive -- i.e., changing the case does not alter the use cases
presented.
Also, I'd note why you're selecting "class" as the keyword (basically,
because it _is_ a keyword, and thus will never conflict with any class
constants or method names).
Otherwise, very straight-forward.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig wrote:
> --f46d04447f47ae95ec04bd949e5f
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw
> wrote:
>
> > > >
> > > > On top of this, there's an argument that you're not addressing: most
> > > > template engines in PHP either directly consume PHP template files...
> > > > or "compile" templates into... PHP template files. As such, sooner or
> > > > later, you'll have a class that includes a PHP template file, and
> > > > that's where things break for me in this proposal.
> > > >
> > >
> > > They don't break because nobody in their right mind would ever try to
> > > include a .phpp file in a framework like that. If its stack is so
> > entangled,
> > > the very notion of a pure PHP stack is just incompatible. So your best
> > bet
> > > on a framework like that would be to stick with .php.
> >
> > Um, so if you aren't using any form of template engine whatsoever, what
> > are you proposing? You're saying we should all go back to the good ol' C
> > days of trying to put together valid markup using string concatenation? (Or
> > worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
> > blowing up London to stop a jaywalker.
> >
>
> That's a logical fallacy; i.e. your contention relies on the premise that,
> if this doesn't work with every single framework known to exist, then it
> doesn't work with any template engine whatsoever. That's just patently
> ridiculous and could not be further from the truth.
Then point to ONE widely used, OSS templating engine or MVC framework
that will be able to operate as pure PHP. (My mustache library does not
count.)
I'll give you time to look for one.
Hint: I don't think you'll find any.
Most PHP template engines compile templates to HTML with embedded PHP.
This does NOT mean that including such a PHP file immediately spits out
output -- on the contrary: every PHP templating engine I've seen by
default will use output buffering to allow capturing the output to a
variable, which you _later_ spit out.
This is one reason I'm very uncertain about your assertion that
including an embedded PHP file taints the class including it, as well as
any up the stack. The code itself is never really operating in "mixed"
or "embed" mode -- only the template file itself is. If you insist on
the tainting aspect, I honestly do not see this proposal gaining ground;
few if any exising frameworks or template engines will gain anything by
it, much less be able to take advantage of it, and the work necessary to
make it possible makes it undesirable, except as an achievement ("look!
I did it!").
Finally, you're constantly dismissing the arguments that specifying a
specific suffix is a bad idea -- but without making a reasonable
argument as to why suffixes are okay. I personally write a lot of CLI
scripts in PHP -- and typically do not give them extensions. Under your
proposal, even those these do not operate in embed mode, because they do
not have the "blessed" extension, they cannot omit the http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow "use( $longname as $alias)" syntax for closures declaration
On 2012-04-13, Nicolas Grekas wrote:
> > Yes, the original used "$this->getFooBar()" -- but it could have been
> > "$someOtherObject->getFooBar()"
>
> Yep, you and Anthony are right, my comment was stupid...
>
> Then I have an other objection :)
>
> I'm not comfortable with mixing declarative lines with expressions:
> function (..) use (..) is always purely declarative, whatever the (..)
> but
> function (..) use ((expression) as $foo) isn't any more.
>
> I would feel the same e.g. with a syntax like:
> function ($a = $foo->bar()) {} (a closure with default argument calculated
> once but give as expression.)
>
> If you like "use ((expr) as $foo)", do you like the above?
> This is an open question, a yes would be coherent,
> but otherwise, why allow one and not the other?
No -- because you can't do it when declaring a normal function
(non-closure/lambda/anonymous). If we could do that syntax with regular
function/method declarations:
// lazy-create $foo if not passed
public function doSomething(FooBar $foo = new FooBar())
it _might_ make sense, but as it stands, it's inconsistent with how we
allow function declarations.
I'm on the fence about "use ((expression) as $foo)" -- I fully like the
idea of aliasing closure variables, but still thinking on the expression
syntax. It would be _inconsistent_ with how it works with namespaces
(which uses literals only), and _semi-consistent_ with traits (which
have the "insteadof" syntax). I can definitely think of some nice use
cases surrounding them, though.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
On 2012-04-13, Tom Boutell wrote: > Wouldn't this be a significant performance hit when multiplied by > every class file in a project? Typically, you'd cache the end-result of pre-processing, so that subsequent requests can use the processed results. In other words, you incur the expense once per file. > On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney > wrote: > > On 2012-04-13, David Muir wrote: > > > On 13/04/12 14:55, Stas Malyshev wrote: > > > > > If this is a pecl module library developers cannot use it and trust > > > > > that on php 5.n, it just works. That would fork the language in an > > > > > undesirable way. It should be a core feature, no ini flag, no > > > > > sometimes-there module. > > > > PHP 5.n is at least a year away, wide adoption of it - more like 5 years > > > > away. So if you want to write code that would run anywhere (as opposed > > > > on systems you control) you'd have to wait minimum 5 years. Wouldn't it > > > > better to have it earlier? > > > > OTOH, requiring extensions is a common thing for applications, and any > > > > pecl extension is one command away for most setups, or one download away > > > > for others. And can be made work even in 5.2 if desired. > > > > > > Can't it also be handled using streams to inject a leading > > file prior to inclusion? A PECL extension would then just make it run a > > > bit faster. > > > > I made this very suggestion earlier this week (we do this in ZF1 to > > emulate short tag support for those who use them). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow "use( $longname as $alias)" syntax for closures declaration
On 2012-04-13, Nicolas Grekas wrote:
> --f46d04016a77a386cf04bd8a62df
> Content-Type: text/plain; charset=ISO-8859-1
>
> > $closure = function () use ($this->getFooBar() as $foo) {
> > $foo->stuff();
> > }
>
> But this can already be written as :
>
> $closure = function () {
> $foo = $this->getFooBar();
> $foo->stuff();
> }
>
> Here, $foo also only exists inside the closure.
You're missing the point.
Yes, the original used "$this->getFooBar()" -- but it could have been
"$someOtherObject->getFooBar()" -- in which case you either have to bind
$someOtherObject, or grab the return of getFooBar().
Also, getFooBar() would be called _once_ in the original example,
instead of once each time the closure is invoked (your example).
> > Also, remember that the closure is in fact another function, a function
> > that performs its own actions independent of the parent.
>
> Actions may be independent, but as a closure is declared inside its parent,
> both codes have very strong relationship. For the reader, overriding this
> relationship with new closure-local var names can weaken its understanding
> of the code don't you think?
The closure is a function itself; readability within it is just as
important as readability of the parent. I'd personally rather not have a
lot of boilerplate code marshalling variables to start off my closure --
I'd rather they were simply declared and ready for use.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig wrote:
> On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur wrote:
> > //a controller, maybe a class, maybe just a set of functions, but in a
> > .phpp file
> > function getLoginPage()
> > {
> > //set up some data
> > //some people like to use plain .php for templates
> > include 'templates/loginPage.php';
> > //other people like to use a View library
> > $view->render('loginPage.tpl');
> > }
> >
> > In the case of using a view object, your controller can be a .phpp file.
> > In the case of the include, it cannot. Now consider the case of the
> > implementation of the render() method:
> >
> > function render($template)
> > {
> > $compiledTemplate = $this->compile($template);
> > include $compiledTemplate;
> > }
> >
> > Now your render method cannot be in a .phpp file.
>
> Again, the controller should NOT be a .phpp file. Likewise, your model
> should NOT be hooking directly to the view. The controller hooks to the
> model. The controller then sanitizes that and returns it to the view.
> Alternatively, if you're not conforming to a pure MVC standard,
Sorry, this is where you lose me. There's no "pure" MVC standard,
particularly when it comes to MVC implementation on the web. There are
many, many, many interpretations of how MVC works, and some generally
accepted understanding around separation of concerns, but if you look at
the ecosystem of MVC frameworks in PHP alone, you'll see that none of
the frameworks do things the same way.
On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and that's
where things break for me in this proposal.
I think the "pure PHP" vs "embedded PHP" has to be determined in a
file-by-file basis, if at all -- NOT based on whether or not a file is
consuming a file that has embedded PHP. Once you go down that rabbit
hole, as soon as you have one file with embedded PHP (and most likely,
you will), you'll have to assume the entire project is. At that point,
there's zero benefit at all to making a distinction.
The proposals to use a flag with include, or to provide a separate
"script()" function for switching between pure PHP/embedded PHP make
sense to me. These make it easy for a framework/project to provide
autoloaders that choose the appropriate flag/function necessary to load
the class, and to select the appropriate flag/function when including
embedded artifacts. They also make auditing code easy -- you can grep
for one or the other.
File extensions, on the other hand, are a non-starter, as is any
approach that would insist that any consumer of a script that uses
embedding be marked as embedded as well.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
On 2012-04-13, David Muir wrote: > On 13/04/12 14:55, Stas Malyshev wrote: > > > If this is a pecl module library developers cannot use it and trust > > > that on php 5.n, it just works. That would fork the language in an > > > undesirable way. It should be a core feature, no ini flag, no > > > sometimes-there module. > > PHP 5.n is at least a year away, wide adoption of it - more like 5 years > > away. So if you want to write code that would run anywhere (as opposed > > on systems you control) you'd have to wait minimum 5 years. Wouldn't it > > better to have it earlier? > > OTOH, requiring extensions is a common thing for applications, and any > > pecl extension is one command away for most setups, or one download away > > for others. And can be made work even in 5.2 if desired. > > Can't it also be handled using streams to inject a leading file prior to inclusion? A PECL extension would then just make it run a > bit faster. I made this very suggestion earlier this week (we do this in ZF1 to emulate short tag support for those who use them). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Allow "use( $longname as $alias)" syntax for closures declaration
On 2012-04-12, Laruence wrote:
> I have made a RFC to allow user use T_AS in the closure declaration, like:
>
> function () use($long as $l, &$long as $r) {
> }
>
> here is the RFC: https://wiki.php.net/rfc/useas
>
> any ideas? thanks
I really like this, as it brings a symmetry to how "use" is used when
importing classes/namespaces; I've often attempted to use "as" within my
closure use statements, only to get burned.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object oriented page templates in PHP
On 2012-04-09, Tom Boutell wrote: > There's a reason I didn't try to kick this out as a fully formed RFC (: > > The choice of @ is a nonstarter, yes. I forgot that start code for PHP already so it is already valid PHP to write http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Adopt GitFlow process
On 2012-03-25, Alexey Shein wrote: > There was a discussion recently on IRC that our current git working > process is not perfect (especially about keeping one branch-only > bugfixes) so that's a > suggestion to use (and modify to better suit our needs) nvie's gitflow > process and git-flow tool he developed to ease the process. > If you're not yet familiar what is that, please read > his wonderful article > http://nvie.com/posts/a-successful-git-branching-model/ > another wonderful article about the gitflow tool > http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ One thing I'll point out is that git-flow is a set of extensions and aliases for the git CLI. The problem with this is if you are not using the git CLI tooling (e.g, if you're using an IDE), or if you're on a system where installing the tooling may not work (Windows). As such, developers on those systems end up having to do a lot of manual work that git-flow normally automates -- and ends up in those same developers taking shortcuts. In short: while I like the idea of git flow, I think it's more sane for OSS projects to adopt processes that do not depend on it. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Github Pull Request
On 2012-03-20, Kris Craig wrote: > --f46d043892b5d6413304bbb15eed > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Mar 20, 2012 at 10:34 AM, David Soria Parra wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 03/20/2012 06:29 PM, Kris Craig wrote: > > > Quick clarification: On the other hand, by "pull request" are you > > > simply referring to somebody else requesting that you "pull" their > > > submission and merge/push it? If so, I get it, but I really think > > > we should come up with another term to describe it because it > > > really does sound kinda backwards IMHO. I just woke up less than > > > an hour ago though so maybe I'm just groggy lol > > > > Drink a coffee wake up, think first and write the mail then and help > > reducing mailinglist noise by trying to figure it out yourself. > > > > We are referring to pull requests in the sense of pulling stuff from > > another repository into ours. We talk about pull requests made on > > github for the php/php-src repository. We use pull request the same > > way everyone else uses. Someone requests via github or a pull request > > mail (linux style) to pull his changes and merge them into our repository. > > Yeah I get that. It just feels imprecise to me. Wouldn't "external merge > request" be more descriptive? Generally, a pull request refers to a pull > from a remote repository. While that's an initial component of this, the > fact that it ends with a push request just makes the terminology needlessly > confusing IMHO. But if nobody else is bothered by it then I guess I'll > just have to suck it up lol. This is how the general population of git users understands it; I don't see any reason to introduce additional terminology. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On 2012-03-12, Arvids Godjuks wrote:
> --f46d0442880e02b97f04bb0b432b
> Content-Type: text/plain; charset=UTF-8
>
> I think that the "null issue" is not an issue. Strictly speaking if you
> want null or an int - leave out the type hint and use generic argument that
> will accept anything.
> I think it's over-engineering to try and push a special treatment for the
> null. If function/method argument accepts anything but a single type -
> it's type-less and does not need a type hint.
However, that conflicts with how typehints work currently in PHP:
public function setContainer(Container $container = null)
{
$this->container = $container;
}
This is perfectly valid currently, and allows "unsetting" a value
easily. I'd expect scalar hints to work exactly the same way -- in other
words, null, or a value that satisfies the hint.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
On 2012-03-06, Anthony Ferrara wrote: > My concern is the total lack of talk on-list about it. It's obviously > not perfect, but there has been little to no talk on-list about it. > That is an indication to me that it's not ready or that it won't get > in if put to a vote... > > Thoughts? I really like the proposal you set forth. I have zero clue what impact it would have on performance, however, so I'm deferring that discussion to those who do. As a user and framework developer, I'd love to see it in place -- casting support at the function/method parameter level would greatly simplify a lot of code I write. > On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick > wrote: >> Hi, >> >> It got quite around that because we have some RFCs to this where the >> functionality seems to be defined as the people thought it should be. >> Otherwise they can raise their hands and write a mail that they want to >> update the RFC - but as there's no one doing that, I think we're quite >> close to what we wanted. >> >> Take a look at it and feel free to add your ideas in this thread. >> https://wiki.php.net/rfc/parameter_type_casting_hints >> https://wiki.php.net/rfc/object_cast_to_types >> >> Bye >> Simon >> >> 2012/3/6 Kris Craig >> >>> Wow no offense, but your timing is terrible, Raymond! We've been going >>> back and forth on this for the past couple weeks now, though the discussion >>> has quieted for the moment. >>> >>> I would suggest you go through some of the recent posts on Internals. >>> Right now there basically is no solid consensus on this issue, though some >>> of us have been working to change that. But as it stands now, I'm not >>> aware of any plans to introduce expanded typing of any kind in the >>> foreseeable future. And even if we did, I highly doubt it would happen >>> before PHP 6. >>> >>> --Kris >>> >>> >>> On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving wrote: >>> >>> > Hello, >>> > >>> > I came across some info on the web that states that scalar type hinting >>> was >>> > added to the PHP trunk but it did not make it's way into 5.4 because of >>> > objections from the community. Will it ever make it's way into 5.5? >>> > >>> > I know PHP is considered to be a weak typed language but it should also >>> be >>> > about freedom. Freedom for a PHP developer to choose to use scalar type >>> > hinting whenever he/she sees the need. >>> > >>> > >>> > Best regards, >>> > __ >>> > Raymond >>> > >>> -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-05, Pierre Joye wrote: > On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney > wrote: > > > +1. > > Votes are for later. This was an indication of being in favor of the proposal, no more, no less. > > Since so many distros and ISPs tend to adopt late, this would keep them, > > and their users, covered for a reasonable time period, allowing for a > > cleaner migration path. > > There is a clear migration path defined now for all releases beginning > from 5.4. The discussion here is about 5.3 only. > > Please read all posts or replies, it helps to get the whole idea and > avoid repetitive arguing :) I did, actually. I still agree with Sebastian's proposal. While the PHP group may want to push for faster adoption, the pattern I've observed over and over is that ISPs and distributions -- particularly those with LTS offerings -- tend to adopt a minor version only when the new minor version supplanting it has been released. Does it make sense? No. Is it what happens? Yes. As such, I think it makes a lot of sense to base the lifetime of 5.3 based on when 5.4 is released. For the record, it's the path we're taking with ZF as well -- lifetime for the last minor release of ZF v1 will be determined by when ZF2-stable is released. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Sebastian Bergmann wrote: > On 03/02/2012 07:34 AM, Pierre Joye wrote: > > https://wiki.php.net/rfc/php53eol > > I discussed with Arne Blankerts and Stefan Priebsch over breakfast today > and Stefan had an interesting idea: why not announce (now) that PHP 5.3 > will go into EOL a year after PHP 5.5 comes out? > > * Now until PHP 5.5 comes out: bug and security fixes for PHP 5.3 > * From the release of PHP 5.5: security fixes for PHP 5.3 for a year > > Ideally, PHP 5.5 would be out in a year from now, so it would come down > to one year of bug and security fixes and one year of security fixes > only. Makes sense to me. +1. Since so many distros and ISPs tend to adopt late, this would keep them, and their users, covered for a reasonable time period, allowing for a cleaner migration path. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Pierre Joye wrote: > It should have been done before 5.4.0 was out, but better late than never. > > I put together four options here: > > https://wiki.php.net/rfc/php53eol > > I'm in favor of option #1, as it gives enough time to our users to > migrate by reducing the maintenance period to only one year. > > Suggestions or comments welcome, Considering that 5.3 adoption is still eclipsed by 5.2 adoption, to be honest, it feels like doing 1 year bugfix + 1 year security fix is the minimum necessary. By the time we get good adoption of 5.3, it will already be EOL'd. :-/ -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
On 2012-03-02, Anthony Ferrara wrote:
> Well, there are a few questions about the implementation:
>
> 1. *Which* type casting rules should it follow?
>
> a. Regular cast rules (like $foo = (int) $foo), where it converts
> always without error?
> b. Internal function cast rules, where it warnings on error and
> prevents execution of the function.
> c. Current type hinting rules, where if it can't convert cleanly it
> E_RECOVERABLE_ERRORS
>
> Personally, I like C the best. Where if it is passed an invalid
> value, it attempts to cleanly convert, but errors out if it can't...
> But I can see other arguments being made...
(c) seems the most sane option ot me as well.
> 2. Should (array) be supported? Perhaps. So at that point, foo(array
> $bar) would do a "strict" check, and foo((array) $bar) would attempt
> to cast. But my question would be: what would attempt to cast mean?
> Should it error out if you pass foo(1)? That's what the internal
> function cast rules do. And to me that's more obvious than silently
> converting it to foo(array(1))...
Turn this around and look at it from the current state of PHP:
function foo($bar)
{
$bar = (array) $bar;
}
If you pass a value of 1 for $bar, $bar is then converted to array(1).
That's what I'd expect the following to do as well:
function foo((array) $bar)
{
}
It's casting, and clearly different than:
function foo(array $bar)
{
}
which is doing a typehint check.
> 3. Should references be supported? My feeling is yes, they should.
> So if you do foo((array) &$bar), it would cast the original value (if
> possible) as well.
I personally would expect casting and references to be mutually
exclusive -- if you're casting, you're changing the value type, and I
wouldn't expect a destructive operation like this from passing a value
to a function/method call.
> 5. What about BC breaks? Well, this entire patch (up to this point)
> wouldn't require one. it's only adding the casting functionality
> (which is not implemented today), so no problem. Existing code would
> still function fine.
This is something that should be highlighted. I've seen a lot of folks
claiming type hinting is viral, and the arguments make no sense to me.
What your patch is offering is _opt_in_ type casting of function/method
arguments. You don't _have_ to write your functions or methods using
them, and for those who do, it should have no side effects on code
calling it.
I would _LOVE_ to see this as part of PHP.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: HEADS UP: 5.4 branch is open again
On 2012-03-02, David Soria Parra wrote: > just a heads up. The PHP_5_4 branch is open for commits again. Related: With 5.4.0 out... how soon will the cutover to git occur? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On 2012-02-27, "Richard Lynch" wrote:
> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
> > > I have to say that no matter how much a luv my OOP, turning every
> > > built-in type into an Object is just a Bad Idea...
> > >
> > > It's a form of bloat on RAM and CPU with minimal added value, imho.
>
> > Re-read what I had written. I never said to turn every built-in type
> > into an object. In fact, what I was talking about was keeping and
> > preserving the base types as-is. All that I was proposing was adding
> > the ability to cast from and to the primitives. That way you could
> > silently convert back and forth as needed (transparently when
> > possible).
> >
>
> I apologize that my brevity has been misconstrued.
>
> You are certainly free, even with the tools available in PHP, to
> "wrap" an object around integers, strings, and so on.
>
> There may even be occasions where I think that would be a Good Idea (tm).
>
> What I object to is building such a facility into core PHP, because:
>
> 1) You can already do it in userland, and I believe that's where it
> belongs.
Actually, you can't. The point of Anthony's proposal is that while we
_can_ wrap scalar types in objects, that fails for the instances where
you need to perform operations with them. This is why he's proposing the
ability to cast to and from these "scalar objects", and have calls in
the engine that would do the casting on-demand.
> 2) It unnecessarily [see 1] complicates core PHP, whose major
> strengths that drive its success includes its simplicity.
The flip-side of the argument is that if many developers are doing code
like this over and over again:
public function setNumber($number)
{
if (!is_scalar($number)) {
throw new InvalidArgumentException('Need a number!');
}
$this->number = (int) $number;
}
... then it may be time for the language to make this easier.
(And just because _you_ or a subset of developers on internals don't
write code this way does not mean a _majority_ of developers do not.)
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 and is_callable()
I reported a bug some weeks ago regarding how is_callable() works in PHP
5.4:
https://bugs.php.net/bug.php?id=51527
Here's the situation:
class Foo
{
public function bar()
{
return __METHOD__;
}
}
If I create a callback with either of these values:
* $callback = 'Foo::bar';
* $callback = array('Foo', 'Bar');
is_callable() now returns true. In PHP 5.2 and 5.3, it returned false,
which is what I'd expect.
The argument made in the comments to that issue are, "well, technically
you can call it; it just raises an E_STRICT." That's true. Unless the
method actually utilizes $this, in which case you get a fatal: "Using
$this when not in object context." And I can think of precisely zero
situations where I'd want to call a non-static method statically and
expect it to work.
The point is: if I call is_callable() and it returns true, I should have
a reasonable expectation that calling the callback will now work. In
5.3, I could make that assumption. In 5.4, that breaks, and I now have
to go to some lengths to validate my callbacks. Sure, I could rely on
PHP's error handling, but I'd much rather raise an exception or branch
my logic so I can handle it gracefully within the application.
I propose that when a string callback referencing a static method call
OR an array callback referencing a static method call refers to a method
that is not marked static, is_callable() should return false.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Status update: Git Migration
On 2011-12-29, David Soria Parra wrote: > here is a short update on the current status of the > git migration. Thanks for all the ground work you're doing making this happen! > - php-src will be migrated after PHP 5.4 final >Stas wants to have PHP 5.4 final out before we migrate >the repository to not have problems with the release. >Expect the php-src migration in 14-21 days after 5.4 final. > > - http://git.php.net is up and running >We setup the server. Thanks to gwynne, derick, conf, mgdm, druid >helping me with that. > > - old git mirrors are down >the old server was shut down. mirrors have not been setup so far. > > - systems/ and web/ are going to be migrated in the next days >systems is already migrated and commits to the systems/ directory >in SVN is disabled. We are slowly migrating the cronjobs on the boxes. >web will follow right after systems is done. > > - playground >Feel free to play around with the playground.git repository at >http://git.php.net. Please note that the push url is different >from the unathorized pull url. THis will be fixed soon (hopefully). >Everyone with an SVN account should be able to push to that >repository. > > - feedback > feedback, bugs, etc always welcome. just send me a mail or poke >me in IRC. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 2011-12-22, Rasmus Lerdorf wrote:
> On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
> > Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
> > > This is not a step forward. If the author of age_check() really
> > > doesn't want to accept type-juggled arguments, then it is easy
> > > enough to do a strict type check in the function itself. This puts
> > > the effort in the correct place and doesn't encourage this type of
> > > coding.
> >
> > Putting such code into the "correct" place does not change the
> > problem that you and Stas describe
> >
> > function age_check($age)
> > {
> > if (!is_int($age)) {
> > throw new InvalidArgumentException;
> > }
> > }
> >
> > With the above code, the caller needs to cast and the writer of the
> > age_check() function has to copy/paste/adapt these checks to all
> > the correct places ...
> >
> > I am not advocating type hints for scalars, I am just saying that
> > this argument is not really a good one against it.
>
> But people don't really write code like this in PHP.
Um, I do. Often.
The first half of the security mantra is "filter input." This also
applies to APIs -- you need to ensure you have input you can actually
work with. While I might not use the is_int() that Sebastian provided
above, I might do the following:
if (!is_numeric($age)) {
throw new InvalidArgumentException('Did not receive number');
}
if ((int) $age != $age) {
throw new InvalidArgumentException('Did not receive integer');
}
$age = (int) $age;
Why? Again, because I need to trust I have a value that I can work with.
Throwing an exception as soon as I know I can't work with the value is
easier to debug than having another function or operation raise an error
later -- these are often much harder to debug, as the source of the
input may be several steps removed by that point.
This is especially important for library and framework authors, as we
need to make the code robust for numerous use cases, most of which will
be beyond our immediate control. This makes debugging easier for end
users, and also makes documentation simpler.
> Which is also why it makes very little sense to add strong typing of
> scalars. Why would anyone want to add a feature that lets them do
> something they would never do?
Despite the example I have above which I personally don't want strong
scalar type hinting. I _do_ favor the idea of casting hints, though --
simply because they would simplify my work tremendously, while still
giving me the benefits I have if I test my input manually.
> The above code is much more likely to do an is_numeric() check and/or a
> hard typecast to an int. But throwing an exception when it receives "21"
> instead of 21 just isn't something people tend to do.
I honestly don't think that was the point of Sebastian's example -- the
point was that instead of this:
function age_check(int $age)
{
// use the $age value with the knowledge that it's sane
}
we're forced to instead do manual checks within the function body
itself, which is repetitive, introduces new vectors for errors, and
potentially degrades performance. Additionally, it introduces a cost in
development -- additional tests and code need to be written.
> The only way I see something like this ever happening in PHP is if we
> came up with an intelligent approach that actually was type *hinting*
> and not strong typing. As in:
>
> function ((int)$age) {
> return ($age > 21) ?: false;
> }
>
> that would gracefully handle interchangeable types. But it gets tricky
> once we start thinking about non-numeric strings being passed in there.
Agreed on all accounts here. However, if it can be done, I think it
would be a huge boon to developers.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-12-02, "Dmitri Snytkine" wrote:
> IT would probably be even more convenient to just say
> if( (new Validator())->isValid($value) ){
>
> }
>
> No reason to just temporaraly assign $validator.
Except that you can't get the validation error messages if validation
fails. That was the point of assigning -- error messages are stateful
properties of the validator.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-12-02, Rasmus Lerdorf wrote:
> On 12/02/2011 08:50 AM, Matthew Weier O'Phinney wrote:
> > if (!(($validator = new SomeValidator())->isValid($value))) {
> > // Validation failed, get messages...
> > $view->assign('errors' => $validator->getMessages());
> > return $view->render('error');
> > }
> > // validation passed, do something...
> >
> > Yes, this could be written as follows:
> >
> > $validator = new SomeValidator();
> > if (!$validator->isValid($value)) {
> > // ...
> > }
> > // ...
> >
> > However, I can see some folks not really wanting that variable
> > declaration if they won't be using it outside the conditional.
>
> But $validator is still going to be defined regardless of the return
> value of isValid() so it is going to be set outside the conditional.
True. My point was that _semantically_ it looks like it's contained by
the conditional. _Technically_, it's not.
My main point is that this looks like a pattern folks will try
immediately, and wonder why it doesn't work. Whether or not it _should_
work, I'm ambivalent about. I'm more likely to declare and then invoke.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-12-01, Anthony Ferrara wrote:
> On Thu, Dec 1, 2011 at 12:34 PM, Ralph Schindler
> wrote:
> > needs to somehow guarantee that all methods of the type $foo will return
> > $this. (BTW, this is not an argument for my feature as much as its an
> > argument as much as its one for "if we're going to do something, why not do
> > it correctly in the first place".) The correct path here, IMO, would be to
> > simply carry the expression result (since we're using '(' expr ')' out and
> > allow dereferencing on whatever comes out of it.
> >
>
> I would argue though that your syntax is completely possible today:
>
> $foo = new Foo;
> $foo->bar();
>
> What's the reason to put that in a single line? Aside from terseness,
> is there any other benefit? With the new dereference, one benefit is
> that no variable is populated when none is needed. But in your case,
> you need both variables...
Here's another example.
We have validator classes. Typically, you call isValid() to see if a
value validates. If it does, you have no more use for the validator. If
it _doesn't_, however, you'll want to get the error messages. I could
see the following as being a nice, succinct way to use validators:
if (!(($validator = new SomeValidator())->isValid($value))) {
// Validation failed, get messages...
$view->assign('errors' => $validator->getMessages());
return $view->render('error');
}
// validation passed, do something...
Yes, this could be written as follows:
$validator = new SomeValidator();
if (!$validator->isValid($value)) {
// ...
}
// ...
However, I can see some folks not really wanting that variable
declaration if they won't be using it outside the conditional.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-11-30, Sebastian Bergmann wrote: > Am 30.11.2011 19:09, schrieb Ralph Schindler: >> $value = ($obj = new Foo)->produceAValue(); > > -1 Just curious: why? (Not that I'm 100% sure I agree with it myself, but curious why you would vote against it...) -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-11-30, Will Fitch wrote:
> If that's the case, then why not just add whatever $options is as a
> parameter to your constructor. I'm not totally against this concept,
> but this use is moot.
No, it's not.
Consider the case of using a variable for the class name -- i.e.,
dynamic classloading. It's typically bad OOP to have interfaces define
the constructor, so you'll identify a method used for configuration.
That ends up looking like this:
$classname = discover_class_name();
($foo = new $classname())->configure($options);
This would work, as you expect the class to conform to an interface that
defines configure().
> On Nov 30, 2011, at 2:51 PM, Ralph Schindler wrote:
>
>> Ironically, quite the opposite is something I find useful:
>>
>> ($foo = new MyComponent($bar))->configure($options);
>>
>> In a single line, instantiate and configure (via an API call) an object.
>> The return of configure() is not important to me, but the brevity of that
>> workflow, and the result of "new" is.
>>
>> -ralph
>>
>>
>> On 11/30/11 1:13 PM, Nikita Popov wrote:
>>> To me the main problem here is that $bar = ($foo = new Foo)->bar()
>>> simply doesn't make much sense. It is equivalent to:
>>> $foo = new Foo;
>>> $bar = $foo->bar();
>>> Which is much cleaner and easier to understand.
>>>
>>> The plain (new Foo)->bar() syntax *is* useful for cases like (new
>>> ReflectionClass($class))->implementsInterface('Foo'), where you need
>>> only one single bit of information from a class.
>>>
>>> Nikita
>>>
>>> On Wed, Nov 30, 2011 at 8:02 PM, Ralph Schindler
>>> wrote:
>>>> Nikita,
>>>>
>>>> You're completely right about the expanded expressions, but I'm not sure
>>>> its
>>>> an edge-case per-se.
>>>>
>>>> The problem with the current syntax is that the resultant of the 'new'
>>>> operation is lost UNLESS your chained method returns $this - which IMO
>>>> makes
>>>> it about as 1/2 as useful as it really could be.
>>>>
>>>> In the case of "new" though, the resultant is always an object, it seems
>>>> like it should be permissible to change the parser to allow for variable
>>>> assignment of the target object.
>>>>
>>>> I think for people just trying out this new behavior (by seeing it in the
>>>> release notes as (new Foo)->bar()), the next logical thing is to try this
>>>> syntax:
>>>>
>>>> ($foo = new Foo)->bar()
>>>>
>>>> // OR in bison
>>>> '(' variable '=' new_expr ')'
>>>>
>>>> I did it, and I see other people doing it too. So I guess the question
>>>> is...
>>>> "how edge case is this edge case?" :)
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Thoughts On Implementing Decorator Sugar to core
On 2011-11-23, Anthony Ferrara wrote:
> I've had an idea that's been burning in my head for a while. Rather
> than write an RFC or do any significant work on it, I thought I would
> bounce this off of you all first.
>
> Basically, I see a problem with implementing decorators in PHP.
Oof, yes. :)
> So, I've been trying to think of a few methods to add syntactic sugar
> to PHP to make this a lot easier. So here's my thoughts
>
> Option 1
>
> Add a magic interface `\PHP\Decorator` which would declare a
> `getDecoratedObject()` method. It would after construction call that
> method to figure out what interfaces the decorated object uses. Then,
> it would magically implement them (as above) on the class if they
> weren't already implemented (overridden). That way the decorated
> object could be resolved at runtime.
This seems reasonable, but there are some pretty big drawbacks as well:
* Type-hinting -- typically, a decorator should be able to be used
wherever the object it decorates is used. As such, if you simply
implement PHP\Decorator, type-hinting breaks.
* It looks like it would require a particular constructor pattern,
which could be problematic. (You don't actually specify if the
constructor is the only means for injection, so I can give you the
benefit of the doubt here.)
The primary problem is the first listed, though, and it's pretty big --
I'd expect it would have large ramifications on Reflection, as well as
on various editors and IDEs to provide hinting.
> Option 2
>
> Implement a magic interface `\PHP\Decorator` which would then allow
> all declared interfaces to be satisfied by `__call`. This should
> require the least change to the core, since the only real change
> that's needed is in the core where it checks that the declared
> interface is satisfied.
The problem with this is similar to that of Option 1 -- by using
__call(), you lose Reflection and hinting capabilities.
> Option 3
>
> Add syntax to the member declaration that lets you declare which
> methods should be proxied to a member object. So something like this:
>
> class MyDecorator implements IteratorAggregate, Countable {
> protected $object decorates {
> public function getIterator();
> public function count();
> }
>
> public function __construct($object) {
> $this->object = $object;
> }
>
> public function addedFunctionality() {
> // blah
> }
> }
>
> Then, at compile time the core could do a replace on the class to add
> the proxy methods. This has a major advantage in that you could use
> multiple classes to selectively satisfy an interface. So you could
> actually use it to compose an object at compile time that proxies to
> multiple objects.
I _really_ like this option, to be honest. My only nitpick is that, like
Option 1, we need to flesh out how the object to be decorated is
injected into the decorator. Otherwise, this answers the problems I
raised in Option 1 and Option 2.
> Personally, I like the explicitness of Option 3, but I could get
> behind Option 2 as well. Option 1 feels a bit too magic for my
> tastes.
>
> Another thought, should a decorator be able to pass the type hint that
> the decorated object can pass? For example, should `new
> MyDecorator(new PDO)` be able to pass `__construct(PDO $pdo);`?
in good OOP, you should be typehinting on
interfaces, not concrete implementations; following that logic, it's no
necessary. However, this breaks when decorating internal classes, where
there typically aren't interfaces. So my vote is that the hint be passed
on to the decorator. I have no idea how that would be handled, though.
> If so, how would that be handled? Would the `Decorates` line
> automagically insert the decorator in the class hiearchy for type
> checking only? Or is that a bad idea in general (I have a feeling it
> is)...
>
> What are your thoughts?
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
On 2011-11-17, Stas Malyshev wrote: > > I recall from earlier discussions that Stas was in favor of > > reverting this change -- what's the status at this time? This > > single change > > I was not and still am not - I think if something warrants notice this > is exactly the case. Conversion of array to string "Array" IMHO makes no > sense and not useful in any case, so if you code does that it's most > probably a bug. I understand that some tests were written without > accounting for this, but frankly in this case I think the right way > would be to fix the tests. This is not the feature your code should rely > on (and I think it should have never existed in PHP in the first place) > and if we shall guarantee compatibility with every bug and bad decision > we took in the past we won't be able to advance anywhere. I think in > this case the inconvenience from fixing the tests is outweighed by the > advantage of promoting better code and exposing hard-to-find bugs. I can live with this. > > * ob_get_status(true) does not always return an array > > According to docs, ob_get_status(true) should return array, so it looks > like a bug. Please submit a bug report. Done: https://bugs.php.net/bug.php?id=60321 > > * ob_get_clean() now raises a notice if no buffer to delete > > This is where I say the notice is totally unneeded. Please submit a bug > for it, it should be silent and return false, just as the docs say. Done: https://bugs.php.net/bug.php?id=60322 > > * Redefining a constructor with different arguments now results in > > E_FATAL Prior to 5.4.0RC1, if a concrete class added arguments > > to a constructor defined in an abstract class, no warning was > > raised. This behavior now results in an E_FATAL. I'm ambivalent > > about this change, however -- the code that raised this for us > > should be changed anyways. > > > > However, I'll argue, as others have on the list, that > > constructors should have the flexibility of redefinition without > > raising notices or compilation errors. > > Here I agree with you, but looks like the majority disagrees. Though I'm > not sure, frankly, what the point of defining ctor in the abstract class > is, especially if argument list doesn't stay constant. Maybe clarifying > this would change the opinion here. Ralph has done this in a separate thread now. > > * Introduction of the new keyword "callable" means that this can no > > longer be used for classnames, function names, or method names. > > > > We had one case where a "callable()" method was defined, and this now > > breaks; fortunately, it's only in tests, so we can easily fix it with > > no BC issues on our part. I'll note that I've also used the > > class|interface name "Callable" in the past on other projects. > > > > I'm okay with this change, but it needs to be clearly spelled out in > > the migration docs. > > I will update UPGRADING, thanks. The existence of the callable hint is > documented, but not the fact that it's reserved now. Excellent, thanks. > Thanks for the testing! Thanks for the release! :) -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
Greetings! My team and I (which means Ralph Schindler and Enrico Zimuel) took some time this week to: * Build PHP 5.4.0RC1 and run make tests (and send feedback) * Run Zend Framework 1.11 unit tests against PHP 5.4.0RC1 * Run Zend Framework 2.0 (dev) unit tests against PHP 5.4.0RC1 We found the following issues when running the tests, and I've ordered them starting with those that affect us most. Overall, however, 5.4.0RC1 largely worked out of the box. * Array to string conversion notices break tests In 5.2 and 5.3, array to string conversions raise no notices, and as such allow the tests to continue to run. Now, however, a notice is raised, and PHPUnit then raises an error. While I understand we should likely test values before using them in string contexts, this feels like an arbitrary change at this time. I recall from earlier discussions that Stas was in favor of reverting this change -- what's the status at this time? This single change will likely require a fair bit of time for us to fix across our ZF versions if not reverted, and I suspect it will hit a lot of other projects. * ob_get_status(true) does not always return an array One of our cache adapters uses ob_get_status(true) to determine things like nesting levels. However, despite the fact that we're passing the boolean true value to force return of an array, we get a non-array when the output buffer is empty now -- and this is true only of 5.4.0RC1. With the $full_status argument, I'd argue this should _always_ return an array, even if that array is empty -- which is precisely how it's documented. I see no reason for the change in 5.4. * ob_get_clean() now raises a notice if no buffer to delete Prior to 5.4.0RC1, if there were no buffers left to delete, ob_get_clean() was silent. It now raises a notice -- which, when using PHPUnit, means an error is now raised, making the test fail. I do not see any benefit to raising the notice; if there's nothing left to clean, return an empty string or false (which was the former behavior, and is documented). * Redefining a constructor with different arguments now results in E_FATAL Prior to 5.4.0RC1, if a concrete class added arguments to a constructor defined in an abstract class, no warning was raised. This behavior now results in an E_FATAL. I'm ambivalent about this change, however -- the code that raised this for us should be changed anyways. However, I'll argue, as others have on the list, that constructors should have the flexibility of redefinition without raising notices or compilation errors. * Introduction of the new keyword "callable" means that this can no longer be used for classnames, function names, or method names. We had one case where a "callable()" method was defined, and this now breaks; fortunately, it's only in tests, so we can easily fix it with no BC issues on our part. I'll note that I've also used the class|interface name "Callable" in the past on other projects. I'm okay with this change, but it needs to be clearly spelled out in the migration docs. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
On 2011-10-28, Nicolas Grekas wrote: > About PSR-0 and applying the same reasoning, I don't understand why > the underscore in the namespace part is not replaced by a directory > separator: because of it's class to path transformation, PSR-0 forbids > having two different classes named A\B_C and A\B\C (they map to the > same file). That is a good think, same reasoning for 1. above. But > because of the "underscore in namespace exception", PSR-0 encourages a > situation where class A_B\C can coexists with an other class A\B\C. > Why forbid A\B_C and A\B\C, then allow A_B\C and A\B\C? That is > inconsistent with argument 1. above, which we have used to justify > PSR-0 equivalence for A\B_C and A\B\C... That is inconsistent to me. There were several reasons for this. First, to allow code following the current PEAR standards to work, we obviously need to treat the "_" separator in class names as a directory separator. Since the standard has its origins in the PEAR naming conventions, this was a requirement. Second, going back to the point made earlier in the thread about case sensitivity, several projects indicated they planned to have lowercase namespaces. As such, to allow for word separation, they wanted to use the underscore character -- since namespaces must be in the character set [a-zA-Z0-9_], this was the only available option. To allow namespaces to use the underscore character, the standard then needed to ignore underscores in substitutions on the namespace segment only. So, to sum up: * Allows BC with existing standards * Allows greater naming flexibility in namespaces Hope that answers your question. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
On 2011-10-26, Pierre Joye wrote: > On Thu, Oct 27, 2011 at 1:07 AM, wrote: > > 2011/10/26 Matthew Weier O'Phinney : > > > My main point, however, is that the standard was ratified quite some > > > time ago already -- we just now have parties interested in creating a > > > C-level implementation compatible with the standard to (a) make usage > > > simpler, and (b) better optimize performance. We should not be debating > > > the standard here, just the implementation. > > > > > > > I'd like to object there. Now that we are discussing it on an open > > mailing list again, both seem actually quite relevant. > > Well, my personal opinion here is that you should discuss that in an > open list somewhere and put the RFC together, with examples, docs and > updated patch. The internals list is not really well suited to > discuss that, while I won't mind to have such discussions here, it may > make more sense to have a dedicated list. As it won't be the last > discussion you will have :) The list exists already (http://groups.google.com/group/php-standards), and implementation, RFC, examples, docs, etc. were already debated over 2 years ago, followed by implementations in several dozen projects. What is happening at this point is completion of a C-level SPL class providing a reference implementation that can be re-used directly from the language itself. Even the original code for this was done around 2 years ago; the difference at this point is there is sufficient momentum behind the standard to warrant a push to include it in the language. This minimizes dependencies for projects following the standard, and reduces duplication of effort. The standard is detailed here: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md I think the only relevant questions at this point are: * Does the implementation follow the specification? * Are there any technical objections that do not counter the specification and which would bar inclusion in the language? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On 2011-10-26, André Rømcke wrote: > --bcaec5216025460b0e04b031fc2a > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > 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). Actually, it still works, with no modifications. PEAR 1 classes exist in the global namespace, and as such, the "_" in the classname rule triggers. As such, a PSR-0 compatible autoloader will load PEAR 1 classes as well as those written using namespaces in PHP 5.3. The difference right now is that PSR-0 now differentiates namespace conventions from class name conventions. My main point, however, is that the standard was ratified quite some time ago already -- we just now have parties interested in creating a C-level implementation compatible with the standard to (a) make usage simpler, and (b) better optimize performance. We should not be debating the standard here, just the implementation. >> 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=C3=A3o Paulo - SP/Brazil >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > --bcaec5216025460b0e04b031fc2a-- -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug with static property access
On 2011-10-03, Chris Stockton wrote:
> Hello,
>
> I noticed the following odd behavior earlier today, there is
> definitely a bug here in my opinion, the bug is either the error
> message or the behavior. I think the behavior is possibly expected.
> I'll let some others comment.
>
> The reason I think the error is odd is because it is very misleading
> in a much larger code base (what I was debugging) you go to the line
> it is complaining about and are perplexed because you are not
> attempting to access the mentioned constant. I'm sure the engine does
> some kind of lazy/runtime determination that causes this, that area
> may need a look at?
>
> Example:
> abstract class ClassA {
> static protected $_cache = Array();
>
> public $version = self::VERSION;
>
> final static public function MethodOne() {
> return __METHOD__;
> }
>
> final static public function MethodTwo() {
> self::$_cache;
> return __METHOD__;
> }
> }
>
> abstract class ClassB extends ClassA {
> const VERSION = 1;
> }
>
> var_dump(ClassB::MethodOne());
> var_dump(ClassB::MethodTwo());
>
> ?>
>
> // prints
> string(17) "ClassA::MethodOne"
> Fatal error: Undefined class constant 'self::VERSION' in
>/testbug.php on line 14
That makes complete sense to me -- ClassA is referring to self, which
resolves to ClassA... which does not define a "VERSION" constant. Change
to this:
public $version = static::VERSION;
and it should be fine.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
On 2011-09-23, Rasmus Lerdorf wrote: > On 09/23/2011 12:13 PM, Patrick ALLAERT wrote: > > 2011/9/23 Rasmus Lerdorf > > > 2. Maybe we should think bigger and put more focus on having large PHP > > > frameworks and apps test every RC. Currently we notify them of RCs > > > and just hope someone will test and report back, but that obviously > > > isn't working. We need a Daniel Brown-like approach to this. Someone > > > who is really annoyingly persistent and will hunt down people to > > > test RCs and keep a sign-off checklist of projects that have given > > > a thumbs-up on an RC. > > > > Solution 2: +1 > > > > Having a Jenkins instance which would run major framework testsuites > > against the different versions of PHP? > > That would be cool, but a lot of work to maintain since every > framework/app has different ways of testing and we'll want to test > different versions. It seems like the best bet is to get the people who > know the code best to maintain the tests. If we could get all of them to > set up *and maintain* their stuff on the Jenkins instance it would be > ideal, but that's probably dreaming in technicolor. I've made the decision that my team will test against RCs as soon as they are out (and we're going to be trying to do each beta as well). If we run into issues, we'll of course report back here. That said, I think it would be good to have a notification system whereby framework leads are all pinged on new betas and RCs, and a wiki page where they can indicate that they've run tests (and whether or not they had issues). That way, you could have a targetted nag list -- "Hey, I don't see an update from you -- RUN THE TESTS!", and a deadline whereby if they haven't run them, they accept the consequences. :) I could also see this being an interesting peer-pressure move -- "First to test!", "We tested last week; how come _you_ haven't?", etc. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: is_a() - again - a better fix
On 2011-09-20, Alan Knowles wrote: > Let's try and close this one. > > https://bugs.php.net/bug.php?id=55475 > > I've just added a patch that adds is_class_of(), which is identical to > is_subclass_of, and has the new feature of supporting strings and using > the autoloader. is_class_of() has a very different semantic meaning (in natural language) than is_subclass_of() -- I know I wouldn't expect the behavior it exhibits by looking at the name. > It then reverts is_a() back to the previous behavior, and clarifies the > documentation. Reverting at this point adds a BC break on top of a BC break. Yes, the original perhaps should not have happened (and likely wouldn't have, if people had actually been testing the RCs...), but I'll argue again: the new behavior is more correct. Reverting at this point is simply going to cause more headaches: "package X works for PHP versions X.Y - 5.3.6, and from 5.3.9 to 5.3.last" -- what a nightmare! > This solves the BC issues, and also solves potential security issues > with existing code accidentally passing $url's to the autoloader, and > gives anyone who needs this new behavior a solution. I'd argue that this fix also highlights the need for autoloaders to test their arguments to see if they are getting something that looks like a class name. > Let's at least try and respect the new release RFC, and our users who > appreciate PHP's efforts over the years to try and maintain BC. (it's > one of it's few advantages these days...) To respect the release RFC, we shouldn't introduce a new BC break (breaking behavior with something already released). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Are all HTTP headers registered in SERVER?
On 2011-09-08, Karoly Negyesi wrote: > It seems to be the case but this is not documented anywhere on > php.net. Instead > http://php.net/manual/en/function.apache-request-headers.php say "You > can also get at the value of the common CGI variables by reading them > from the environment". > > This comment http://www.php.net/manual/en/reserved.variables.server.php#87195 > from 2008 concurs. Zend and Symphony both seems to be happy to read > even X- custom headers from SERVER without bothering with > apace_request_headers() or anything like that. The reason is that this is the only truly portable way to get the headers, and it's easier to write a single implementation rather than multiple ones. That said, I'd really love to have a method in PHP for retrieving request headers, either singly or as a list. Having to parse through $_SERVER has always felt hackish. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta & tests
On 2011-08-31, Rasmus Lerdorf wrote: > I am down to 34 test failures compiling against mysqlnd instead of libmysql > > http://codepad.org/ZV8imUuc > > I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my > environment though. It was defaulting to /tmp/mysql.sock I've noticed this on Ubuntu for the last year or two; the extension does not appear to honor the default_socket config directive. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.8 Released!
On 2011-08-25, "a...@akbkhome.com" wrote: > I'm not sure it's possible to get agreement on if this is a bug or > not, you might see a bug, I just see this as a pointless change for > consistency that pretty much nobody will ever need or use. Please don't generalize based on your own opinions and use cases. I am a long time PEAR user (and contributor), and I actually agree with the change. The reporter of the issue that started this all is a colleague of mine, Ralph Schindler, and we discussed it in June along with David Zuilke, who had run into similar issues we had (as well as discussed it with others in other projects). It's not an isolated request; there are many who find the current behavior of is_a() (pre-5.3.7) incoherent for modern PHP usage. Basically, in our case, we were building a DI container. To keep the DI container light-weight, you create definitions that utilize string class names. In order to determine what injections need to be made, you need to introspect the class a little -- and this is where is_a() vs is_subclass_of() vs instanceof comes into play. The latter two _require_ an object instance -- which we may not yet be ready to provide (we may be trying to determine what to inject into the constructor). is_a() does _not_ require an object instance... but prior to 5.3.7 was unable to test against inherited behavior. As such, the only fallback is the much more expensive Reflection API. Having is_a() work properly with string class names and checking the inheritance hierarchy is a huge improvement, keeps it semantically consistent with the rest of the language, and provides capabilities is_subclass_of() cannot (as it cannot check against strings). > I think I'll leave it as > a) no bug was ever reported on the previous behaviour. False -- others in this thread have pointed it out, and I alluded to the report Ralph issued earlier. > b) intended "design" of is_subclass_of was originally to return false > on non-object - andrei (1999) > http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245&r2=17272 > ><http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245&r2=17272> > > c) is_a() was introduced by sebastian (2002) and kept this intended > behaviour > http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102&r2=69234 > ><http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102&r2=69234> > > d) when andrey (2004) proposed the change to accepts strings on > is_subclass_of, he deliberately maintained the existing behaviour for > is_a() > http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604&r2=171349 > ><http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604&r2=171349> > > e) is_a() has a valid use case , and is currently reasonably commonly used. > > d) the new behaviour is an uncommon use case, and can be done very > easily in other ways. > > > BTW. we could really do with a searchable archive of php.dev + > internals... - It's pretty difficult to find out if this was ever > discussed before.. > > Regards > Alan > > > > > On Thursday, August 25, 2011 09:10 AM, Stas Malyshev wrote: >> Hi! >> >> On 8/24/11 4:38 PM, Alan Knowles wrote: >>> Some real history for the young ones ;) >> >> I wonder who you are meaning... :) >> >>> So the previous behavior was very likely the 'designed' behavior. Not an >>> accidental side effect, or bug. >> >> Bugs can be very well intentional, but if they use the language wrong >> way they are bugs. >> >>> It's use case is reasonably common when doing tests on mixed returns >>> (method returns PEAR:error, object or normal value.) >> >> That's when you use instanceof. >> >>> So we had a situation where a reasonable number of people (eg. anyone >>> who had used PEAR), had seen and expected the previous behavior. >> >> Seeing wrong code somewhere doesn't mean it's not wrong. There's a >> reason we have the manual. >> >>> Please do not fix something that is not broken, and breaks real working >>> code, just for the hell of it, even in 5.4. >> >> is_a() was broken - it was returning different results from >> essentially the same function is_subclass_of() for no reason at all >> (no, somebody writing buggy code in PEAR using undocumented parameter >> types is not a reason). The reason why we kept is_a() and not killed >> it in favor of instanceof was to have it work with string arguments, >> since instanceo
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
On 2011-08-17, Michael Morris wrote:
> --001636833a84f3029304aab9fd15
> Content-Type: text/plain; charset=ISO-8859-1
>
> This member of the peanut gallery would like to point out the following
> danger. Consider the following function collection for namespace A.
>
> namespace A;
> function strpos() {}
> function myfunc() {}
>
> Now if I understand the RFC correctly there's an unintuitive problem as
> follows - if myfunc is called first, strpos gets redefined for that
> namespace and functions as the author might expect for the namespace. If
> strpos gets called first then it will behave as it does in the global
> namespace, which may or may not be desirable. In any event, from where I
> stand here in userland, this is potentially confusing. I'm an amateur of
> the 1st degree, but my gut tells me that the behavior state of any given
> function should NOT be determined by whether or not a different function was
> invoked before it.
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.
Example:
namespace A;
class ReflectionClass
{ /* ... */ }
class MyClass
{ /* ... */ }
What if you have an autoloader that, on encountering A\MyClass then
loads that file? You've now redefined ReflectionClass for the A
namespace.
The main difference, of course, is that if ReflectionClass is not
explicitly imported, PHP will barf and tell you it doesn't know about
A\ReflectionClass.
While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when all
functions for a given namespace will be in a single file. It's really a
matter of the project educating its users -- I don't think it should be
a blocker for implementing it at the language level, though.
> On Mon, Aug 15, 2011 at 5:49 PM, Chris Stockton
>wrote:
>
>> Hello Stas,
>>
>> On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev
>> wrote:
>> > Hi!
>> > It's not a shortcoming, it was designed that way, and for very serious
>> > reasons. If you want to know the reasons, there were discussed
>> extensively
>> > when namespaces were discussed. Please re-read that discussion. And all
>> > things you propose now were already discussed back then too. If you hope
>> > people would write \strlen instead of strlen, this discussion is
>> pointless
>> > because it won't happen.
>> > --
>>
>> I see your viewpoint from a architectural/design perspective and they
>> are valid, but I think the impact and design could be lightened with
>> some simple rules of precedence.
>>
>> I think it would be fair to say, autoloader will not be called on a
>> function like strpos, or any builtin compiled extension. Only once
>> those are cycled through will autoloader for functions be called. At
>> this point the performance penalty doesn't exist, because at this
>> point the program execution would have halted with a fatal error
>> anyways.
>>
>> -Chris
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> --001636833a84f3029304aab9fd15--
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 2011-08-12, Lester Caine wrote: > Johannes Schlüter wrote: > > > > Actually the real question here is WHY create a fork on github > > > > at all? The copy you are working on LOCALLY is the fork that you > > > > are developing on? Much of the stuff on github and the other > > > > DVCS server sites is redundant? You only need to publish your > > > > local changes to other developers who are working with you not > > > > to the whole world? > > since i can publish an experimental feature, get it > > reviewed/tested/improved before pushing it to the main tree. > > > > Mind that "other developers who are working with you" is potentially > > everybody on this list;-) > > But that is the point ... if everybody has their own published > 'experimental feature' repos, syncing those bits we are playing with > looks like a nightmare? Surly the point of DVCS is we share via some > central pot, and these experimental branches exist there? Having to > keep track of who's bits you are playing with is the messy bit :( And > it's that which has caused problems with other projects, where > 'extensions' have grown in secondary repos ... and become the official > extension. That is what I think people are just trying to flag up. Actually, it's not a nightmare; it's incredibly easy, and actually helps keep features and bugfixes more sandboxed, and thus more easily reviewed and merged. As an example, let's say I as a developer want to develop feature Y for the language. I create a new branch locally, and start developing. As I near a point where it seems ready, I rebase from the canonical repository, and check to see if any conflicts occur between my code and what's come in on the main repo. If all looks good, I ask for review, and, after a few rounds of back and forth and some coding, again rebase, and then ask for somebody to merge. The nice part about this is it puts the onus on the individual developers to ensure they have clean patches -- if a merge request doesn't apply cleanly, you throw it back and ask them to submit again when it does. Now, let's say while I'm working on feature Y, I also tackle issues X, Z, and A. I do each of these in their own hotfix branches. The nice part is that there's easy, simple segregation between each fix, and I can move back and forth between the branches quickly and with no bleed-over. When it comes to the central repo, you have somebody or a team of people basically reviewing, merging, and pushing in pull requests. A release master is "king" or "queen" of a particular release branch, and is the one who decides if/when a feature is merged to that branch. The main thing is making it clear who is responsible for merging into a "master" branch, and who is responsible for merging into a release branch -- in other words, it comes down to processes. And, frankly, the processes are not terribly unlike the status quo -- the real question is what version control system is the best fit for that process. DVCS tools are (generally) optimized for quick branching, ease of merging, and minimizing commit size -- all of which could potentially benefit PHP development. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 2011-08-12, Lester Caine wrote: > Ferenc Kovacs wrote: > > > But you can't call it PHP anymore due to the license, where as with a > > > > DCVS with people having forks on publically accessible repositories, > > > > everybody is basically violating the license. > > > > > > you can rename your fork on github: > > https://github.com/Tyrael/forphx > > usually people don't do this, as they don't want to maintain a > > competing project, they only fork it for having their own repo to > > develop into until they are done and then send a pull request. > > Actually the real question here is WHY create a fork on github at all? > The copy you are working on LOCALLY is the fork that you are > developing on? Much of the stuff on github and the other DVCS server > sites is redundant? You only need to publish your local changes to > other developers who are working with you not to the whole world? And how do you publish those changes? How do you get review? Yes, you can send patches, but it's often easier to point a person to a repository and branch, and let the reviewer -- or reviewers -- decide how to review -- a diff between the canonical repo and the change branch, using a web-based review system such as GitHub offers, etc. The web-based tools GitHub and BitBucket should not be discounted -- having the ability to have comment-threads per line of code is very useful for keeping the review targetted as well as easily identifying code that may need tuning. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
On 2011-08-14, Derick Rethans wrote: > On Sat, 6 Aug 2011, Ferenc Kovacs wrote: > > I would like to introduce this RFC which would provide function > > autoloading through the spl_autoload facility without userland BC > > breakage. > > > > https://wiki.php.net/rfc/autofunc > > I understand the proposal, but I don't see any compelling reasons in the > RFC of why we actually need autoloading for functions? For classes it > makes sense because there is almost always a class to file mapping. For > functions (and constants) that is not the case, so I am wondering how > useful this function autoloading actually is. Namespaces support the following code types: * Constants * Functions * Classes and Interfaces Currently, autoloading in PHP allows us to dynamically identify and load only classes and interfaces. However, not all code is written using OOP. If a developer doesn't want to dive into include/require(_once) hell in order to use their namespaced functions and/or constants, they have no real options. As an example, let's say I've created a procedural CMS or blog of some sort. In there, I have a file like this: http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: An implementation of a short syntax for closures
> $modify = : $x : $my_constant => $x + $my_constant;
>
> Too much! This line simply confuses me!
>
>
>
> OTHER EXAMPLES
>
> So, personally I don't think shortening needs to go as far as 3 or 4.
> But, I am a fan of 1 and 2.
>
> To demonstrate more how this might look, I'm using the code examples
> Lazare used in his original post:
>
> // Mapping:
> $a->select( function($x){ return $x->getName(); } );
>
> // Filtering:
> $a->where( function($x)use($y){ return $x==$y; } );
>
> // Currying:
> $add = function($x){ return function($y)use($x){ return $x+$y; }; };
>
>
>
> With my examples of shortening, these become:
>
> // Mapping:
> $a->select( :($x)=> $x->getName() );
>
> // Filtering:
> $a->where( :($x)use($y)=> $x==$y );
>
> // Currying:
> $add = :($x)=> :($y)use($x)=>$x+$y ;
>
>
> Hmm... I don't like my currying example, it's starting to boggle my
> mind. How about:
>
> $add = :($x)=>( :($y)use($x)=>$x+$y );
>
> Much better.
>
>
>
> Regardless of all of this, I actually don't find myself using too many
> inline functions. (Not to the extent I was writing 'array' all over my
> code anyway) - So I can't argue srongly about function shortening making
> it's way in to PHP.
>
> Perhaps once we're all using inline functions on every other line of our
> code there'll be a bigger demand for it!
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Error message formatting for development
On 2011-07-26, Derick Rethans wrote: > I just added an RFC for restoring error message formatting so that > developers can easier develop their applications: > > https://wiki.php.net/rfc/error-formatting-for-developers This makes complete sense to me. One question, however: can I assume that the html_errors setting has no effect in the CLI SAPI? That would be my only concern during development, as I'm typically running unit tests and whatnot from the CLI. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 2011-07-12, Johannes Schlüter wrote:
> On Sun, 2011-07-10 at 19:41 +0200, Nikita Popov wrote:
> > E.g. Writing
> >
> > class Evaluator {
> > public function eval() {
> >
> > }
> > }
> >
> > Does in no way create an ambiguity with the eval language construct
> > PHP implements.
>
> For a method this is correct. But for a normal function this is
> different:
>
> function eval() {
> }
> eval(); // will call the language construct
> ?>
But what about this?
namespace Foo
{
function eval($name)
{
echo $name;
}
eval('matthew');
}
The manual doesn't really differentiate between language constructs and
functions, and as such, I can see somebody reading the namespace section
of the manual and feeling this should be valid -- but currently, it
results in a parse error.
It seems to me we need a context-sensitive lexer.
> And i consider it "strange" to allow different names for functions and
> methods. And yes I'm aware that
> $eval = 'eval'; $eval();
> would call the function.
>
> I fear consistency issues.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecating ext/mysql
On 2011-07-11, Paul Dragoonis wrote: > On Mon, Jul 11, 2011 at 4:41 PM, Christopher Jones > wrote: > > On 7/10/11 10:03 AM, Philip Olson wrote: > > > What this means to ext/mysql: > > > > > > - Softly deprecate ext/mysql with education (docs) starting today > > > - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 > > > - Add pdo_mysql examples within the ext/mysql docs that mimic the current > > > examples, but occasionally introduce features like prepared statements > > > - Focus energy on cleaning up the pdo_mysql and mysqli documentation > > > - Create a general "The MySQL situation" document that explains the > > > situation > > > > +1, though check with the MySQL folk about whether they want mysqli or > > pdo_mysql to > > be the recommended path. > > > > Chris > > Yes, +1 from me too. I do indeed think we need to make this a smooth > transition over time. Possibly triggering an E_DEPRECATED for all > ext/mysql usage. Just like the introduction of E_DEPRECATED for 5.3 > functions, we could apply the same approach here. After 5.4 is > released we can put big "Deprecated Warning" notifications on all > php.net/mysql_* functions too. I think we all want this, but to be > realistic from a production point of view, many sites will still be > using ext/mysql. And, to my reading, this is exactly the path that was recommended. The point is to start a "soft" deprecation now via the manual, indicating that users should migrate to other solutions, while simultaneously detailing how to do equivalent operations via ext/mysqli or pdo_mysql. Actual deprecation would happen later. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
On 2011-07-10, Stas Malyshev wrote:
> On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
> > Developer may have taken care of defining them in a specific
> > namespace, would it be possible to not break their application while
> > making them reserved keywords in the global namespace only?
>
> I don't think there's such thing in PHP as namespaced keywords. Keywords
> are processed by the language parser, which knows next to nothing of
> namespaces.
> We could, maybe, prohibit creation of classes with names identical to
> type names, which is different from making it reserved word, and on that
> stage we know the full class name.
I think that's a bad idea. The point of namespaces is to allow us to
override classes (and functions, and constants) within that namespace.
If I can't do this:
namespace Foo
{
class String
{
}
}
then I'd consider the implementation too restrictive.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: deprecating ext/mysql
On 2011-07-10, Philip Olson wrote: > Greetings PHP geeks, > > Don't panic! This is not a proposal to add errors or remove this > popular extension. Not yet anyway, because it's too popular to do that > now. > > The documentation team is discussing the database security situation, > and educating users to move away from the commonly used ext/mysql > extension is part of this. > > This proposal only deals with education, and requests permission to > officially convince people to stop using this old extension. This > means: > > - Add notes that refer to it as deprecated > - Recommend and link alternatives > - Include examples of alternatives > > There are two alternative extensions: pdo_mysql and mysqli, with PDO > being the PHP way and main focus of future endeavors. Right? Please > don't digress into the PDO v2 fiasco here. > > What this means to ext/mysql: > > - Softly deprecate ext/mysql with education (docs) starting today > - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 > - Add pdo_mysql examples within the ext/mysql docs that mimic the >current examples, but occasionally introduce features like prepared >statements > - Focus energy on cleaning up the pdo_mysql and mysqli documentation > - Create a general "The MySQL situation" document that explains the >situation > > The PHP community has been recommending alternatives for several years > now, so hopefully this won't be a new concept or shock to most users. Big +1 from me. We actually chose not to do a Mysql adapter in Zend_Db primarily due to the security issues, but also due to the much more advanced feature sets available in the mysqli and pdo/mysql adapters. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 2011-06-07, dukeofgaming wrote: > --0016e68ee3e4bc4b0e04a525bac6 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > +1 for "callable", it is really more consistent. I was actually agreeing With David and Stas that "callback" was more consistent, and casting my vote for that. > On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney < > weierophin...@php.net> wrote: > > > On 2011-06-07, David Z=FClke wrote: > > > On 07.06.2011, at 22:31, Stas Malyshev wrote: > > > > > callback is callable, the opposite could not be true. a string > > > > > --or a closure-- is callable, but the string is not a callback > > > > > > > According to our docs, which were out there for years, it is. One of > > > the main and widespread complaints about PHP is the lack of any system > > > in naming, design and documentation, it is sad to see how many people > > > want to make it worse instead of making it better > > > > > > +1. I'm thinking it should be "callback", or the docs should be > > > adjusted. "callable" arguably does make more sense, but either way, it > > > needs to be consistent, that's what matters most. > > > > Agreed, here. "callback" is the usage throughout the documentation to > > refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
