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
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 question around: What timeline would be acceptable? "Well > behaved" code hasn't used d
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 support PHP 5.6, 7.2, and 8.0
&g
[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
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
[PHP-DEV] User perspective on STH
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] User perspective on STH
On Mon, Feb 23, 2015 at 10:21 AM, Anthony Ferrara ircmax...@gmail.com wrote:
snip
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.
snip
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.
snip
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).
snip
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 the
direct calls made in the given file, and does not travel all the way
down the callstack, the ideal STH proposal, to me, would be combining
the aspects of the second proposal with regards to type coercion with
the dual-mode.
--
Matthew Weier O'Phinney
Principal Engineer
Project Lead, Zend
[PHP-DEV] Re: Make try/catch brackets optinal
On 2012-07-19, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net 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
Re: [PHP-DEV] Implicit isset in ternary operator
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
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
On 2012-07-16, Amaury Bouchard ama...@amaury.net 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 ajf...@googlemail.com
How much syntactic sugar do we really need? Why add two ways to do
something?
On 16 July 2012 16:24, Amaury Bouchard ama...@amaury.net wrote:
2012/7/16 Nikita Popov nikita@gmail.com
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] RFC Proposal - Attributes read/write visibility
On 2012-07-16, Andrew Faulds ajf...@googlemail.com 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.
/end rant
On 16 July 2012 14:11, Nikita Popov nikita@gmail.com wrote:
On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard ama...@amaury.net 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] Iterable Type Hint
On 2012-07-12, Stas Malyshev smalys...@sugarcrm.com 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] Iterable Type Hint
On 2012-07-12, Rasmus Lerdorf ras...@lerdorf.com 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] Internal iteration API
On 2012-07-13, David Muir davidkm...@gmail.com wrote:
On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
On 2012-07-12, Sara Golemon poll...@php.net wrote:
--e89a8f235453d7a80104c4975c55
On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara ircmax...@gmail.com
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
[PHP-DEV] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-07-13, Eugene Leonovich gen.w...@gmail.com 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 ra...@ralphschindler.com 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-12, Sara Golemon poll...@php.net wrote:
--e89a8f235453d7a80104c4975c55
On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara ircmax...@gmail.comwrote:
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 smalys...@sugarcrm.com 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] RFC: Property get/set syntax
On 2012-04-20, Christoph Hochstrasser christoph.hochstras...@gmail.com 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
[PHP-DEV] Re: Complete case-sensitivity in PHP
On 2012-04-20, C.Koy can5...@gmail.com 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] Complete case-sensitivity in PHP
On 2012-04-20, Kris Craig kris.cr...@gmail.com wrote:
On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan theanomaly...@gmail.com
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
Re: [PHP-DEV] Re: [RFC] skipping optional parameters
On 2012-04-19, Patrick ALLAERT patrickalla...@php.net wrote:
2012/4/18 Matthew Weier O'Phinney weierophin...@php.net :
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.
snip
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
Re: [PHP-DEV] [RFC] skipping optional parameters
On 2012-04-19, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Just a though for named parameter, since it seems
its becoming a relevant topic now.
2012/4/18 Daniel Macedo admac...@gmail.com :
snip
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
[PHP-DEV] Re: [RFC] skipping optional parameters
On 2012-04-17, Stas Malyshev smalys...@sugarcrm.com 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] New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Ralph Schindler ra...@ralphschindler.com 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] Re: New Feature: Fully qualified class name resolution as scalar with class keyword
On 2012-04-17, Stas Malyshev smalys...@sugarcrm.com 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] Re: Disabling PHP tags by php.ini and CLI options
On 2012-04-13, David Muir davidkm...@gmail.com 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 ?php to the 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] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote:
On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesu...@gmail.com 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] [RFC] Allow use( $longname as $alias) syntax for closures declaration
On 2012-04-13, Nicolas Grekas nicolas.grekas+...@gmail.com 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] Re: Disabling PHP tags by php.ini and CLI options
On 2012-04-13, Tom Boutell t...@punkave.com 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 weierophin...@php.net wrote: On 2012-04-13, David Muir davidkm...@gmail.com 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 ?php to the 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 nicolas.grekas+...@gmail.com 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] [RFC] New .phpp File Type for Pure-Code PHP Scripts
On 2012-04-13, Kris Craig kris.cr...@gmail.com wrote: --f46d04447f47ae95ec04bd949e5f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrens...@priacta.com 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 ?php tag. This is limiting, and goes against the idea of portability. I'm not going to go as far as John and claim it's an attack on existing users or anything -- but I will argue that you're ignoring very, very common use cases and patterns used in PHP, and over-estimating how likely people will want to use the feature as proposed knowing the limitations. -- 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 t...@punkave.com 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 ? is a valid start code for PHP already so it is already valid PHP to write ?@. Another tack to take is to use PHP's streams support. We did this in ZF's Zend_View at one point to emulate short tags when they're disabled. Basically, it allows you to pre-process the template file as it's being included. The downside is, of course, performance. However, you could very easily add a caching layer to this as well to cache the modified code so that subsequent calls do not have to do the pre-processing. Basically, I think this is something that can be accomplished in userland. -- 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: Adopt GitFlow process
On 2012-03-25, Alexey Shein con...@gmail.com 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 kris.cr...@gmail.com wrote: --f46d043892b5d6413304bbb15eed Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 20, 2012 at 10:34 AM, David Soria Parra dso...@gmx.net 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 arvids.godj...@gmail.com 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 ircmax...@gmail.com 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 simonsimc...@googlemail.com 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 kris.cr...@gmail.com 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 xwis...@gmail.com 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
[PHP-DEV] Re: HEADS UP: 5.4 branch is open again
On 2012-03-02, David Soria Parra d...@php.net 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] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
On 2012-03-02, Anthony Ferrara ircmax...@gmail.com 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.
snip
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: [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Pierre Joye pierre@gmail.com 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] [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Sebastian Bergmann sebast...@php.net 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-05, Pierre Joye pierre@gmail.com wrote: On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney weierophin...@php.net 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] Object Casting - An Alternative to Type Hinting
On 2012-02-27, Richard Lynch c...@l-i-e.com 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
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 2011-12-22, Rasmus Lerdorf ras...@lerdorf.com 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.
snip
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
[PHP-DEV] Re: Status update: Git Migration
On 2011-12-29, David Soria Parra d...@php.net 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] 5.4's New De-referencing plus assignment
On 2011-12-01, Anthony Ferrara ircmax...@gmail.com wrote:
On Thu, Dec 1, 2011 at 12:34 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
snip
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-12-02, Rasmus Lerdorf ras...@lerdorf.com 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-02, Dmitri Snytkine dsnytk...@ultralogistics.com 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-11-30, Will Fitch will.fi...@gmail.com 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
ra...@ralphschindler.com 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
Re: [PHP-DEV] 5.4's New De-referencing plus assignment
On 2011-11-30, Sebastian Bergmann sebast...@php.net 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
[PHP-DEV] Re: Thoughts On Implementing Decorator Sugar to core
On 2011-11-23, Anthony Ferrara ircmax...@php.net 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. :)
snip
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.
snip
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.
snip
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
[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] Results of testing ZF against PHP 5.4.0RC1
On 2011-11-17, Stas Malyshev smalys...@sugarcrm.com 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
Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
On 2011-10-28, Nicolas Grekas nicolas.grekas+...@gmail.com wrote: snip 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 pierre@gmail.com wrote: On Thu, Oct 27, 2011 at 1:07 AM, ma...@include-once.org wrote: 2011/10/26 Matthew Weier O'Phinney weierophin...@php.net: 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 a...@ez.no 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 dav...@php.net 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 chrisstockto...@gmail.com 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:
?php
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
SNIP/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 ras...@lerdorf.com wrote: On 09/23/2011 12:13 PM, Patrick ALLAERT wrote: 2011/9/23 Rasmus Lerdorf ras...@lerdorf.com 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 a...@akbkhome.com 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 kar...@negyesi.net 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 ras...@lerdorf.com 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 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=17245r2=17272 http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=17245r2=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=67102r2=69234 http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=67102r2=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=170604r2=171349 http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_builtin_functions.c?r1=170604r2=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 instanceof does not. Thus, string arguments should be handled properly. I can see how it can be argued that 5.3 is mature enough so such changes shouldn't be there, however correct in theory. For 5.4, I see no base for argument here. -- 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-17, Michael Morris dmgx.mich...@gmail.com 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
chrisstockto...@gmail.comwrote:
Hello Stas,
On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev smalys...@sugarcrm.com
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] Function autoloading through spl_autoload*
On 2011-08-14, Derick Rethans der...@php.net 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:
?php
namespace MyProjectName\Posts;
$entries = getEntries(date('Y'));
foreach ($entries as $entry) {
displayEntrySummary($entry);
}
Next, assume the getEntries and displayEntriesSummary functions are
also in the namespace MyProjectName\Posts. How does my code load those
functions?
Traditionally, we've used:
include_once 'MyProjectName/Posts/functions.php';
or
include_once __DIR__ . '/functions.php';
in our files. But why should we have to do that? Why are functions --
which make up the bulk of PHP's functionality, and which are the
bread-and-butter of many PHP projects -- get second-class status when it
comes to autoloading?
I can see an autoloader like this:
function autoloadFunctions($funcname, $type = SPL_AUTOLOAD_FUNCTION)
{
if (!strstr($funcname, '\\')) {
// we won't deal with un-namespaced functions
return false;
}
$namespace = substr($funcname, 0, strrpos($funcname, '\\'));
$funcfile = str_replace('\\', DIRECTORY_SEPARATOR, $namespace)
. DIRECTORY_SEPARATOR . 'Functions.php';
return include_once($funcfile);
}
and that might autoload all functions in a given namespace. I've seen
other projects that put a function per-file -- so those might become
even more granular.
Basically, I don't see why we _wouldn't_ want this functionality in PHP.
It makes namespaces practical and useful for procedural applications.
--
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 les...@lsces.co.uk 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] Choosing a distributed version control system for PHP (or not). Call for Participation.
On 2011-08-12, Lester Caine les...@lsces.co.uk 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
[PHP-DEV] Re: An implementation of a short syntax for closures
$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 der...@derickrethans.nl 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 johan...@schlueters.de 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:
?php
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
[PHP-DEV] Re: deprecating ext/mysql
On 2011-07-10, Philip Olson phi...@roshambo.org 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
[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 smalys...@sugarcrm.com 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
Re: [PHP-DEV] deprecating ext/mysql
On 2011-07-11, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Jul 11, 2011 at 4:41 PM, Christopher Jones christopher.jo...@oracle.com 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
Re: [PHP-DEV] Callable typehint
On 2011-06-07, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable I've edited the Problems section to also point out that Closure is considered an implementation detail which may change in the future -- which could potentially require changing any code type-hinting 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] Callable type
On 2011-06-07, David Zülke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! 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
Re: [PHP-DEV] Callable type
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com 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 david.zue...@bitextender.com 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
[PHP-DEV] Re: [PATCH] Notice on array to string convertion
On 2011-06-02, Patrick ALLAERT patrickalla...@php.net wrote: I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. +1 (for E_NOTICE) This allows warning folks easily during development of potential issues, and for those of us using tools like PHPUnit, we'll catch the problem early. At the same time, it doesn't break existing code. -- 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] Object oriented session handlers
On 2011-06-03, Arpad Ray array...@gmail.com wrote: A while ago I submitted a patch to allow session_set_save_handler() to accept a class, and support the inheritance of the default session handler's methods. The RFC has a more detailed description and the current patch: https://wiki.php.net/rfc/session-oo Changes since this was last discussed: - More sanity checking to prevent handlers being called in unexpected states - ZTS fixes Any thoughts? Makes sense to me, and quite straight-forward in purpose. Can't comment on the patch, 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
[PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On 2011-06-05, Felipe Pena felipe...@gmail.com wrote:
Reading our bug tracker I noticed a good feature request [1] from 2009
which points to an interesting feature that I think makes sense for
us, since we are now working with $f() using objects and strings, and
the array('class', 'method') is an old known for call_user_func()-like
functions.
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to
magic methods, static non-static methods.
The array to be a valid callback should be a 2-element array, and it
must be for the first element object/string and for the second string
only. (just like our zend_is_callable() check and opcodes related to
init call)
Any thoughts?
Huge +1 from me -- having to do constructs like the following have been
a huge headache for me:
if (is_callable($callback)) {
if (is_object($callback) || is_string($callback)) {
return $callback($arg);
}
return call_user_func($callback, $arg)
}
This would simplify that tremendously:
if (is_callable($callback)) {
return $callback($arg);
}
--
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: Enum
On 2011-06-03, Dennis Haarbrink dhaarbr...@gmail.com wrote:
One thing I would really like to see in 5.4 is enums.
There is already an RFC for that: https://wiki.php.net/rfc/enum
This was discussed in february this year, but no consensus was reached.
IIRC, the most notable problems were:
- What is the 'value' of enum constant: string or int, user defined scalar,
defaults
- Ability to make enums more 'class like', some people wanted to be able to
add methods.
Another thing which was discussed (and I think most people agreed on that),
but is not in the RFC: type hinting in method signatures.
I'd like to see some examples of _using_ the enums -- how do you
reference them? How do you make comparisons against them? As an example:
if (!$value in SomeEnum) {
throw new Exception;
}
Would that work? or are you envisioning this:
if (!$value instanceof SomeEnum) {
throw new Exception;
}
(The latter is less intuitive, IMO).
One particular use case I'm curious about: could comparisons take into
consideration logical operators (, |, ^, etc.)?
Comparison and/or type hinting against an enum is really the only
feature I see that makes them worthwhile; otherwise, we already have
namespaced and class-level constants.
I think we should keep this simple proposal simple, let it be an enum in all
its simplicity.
The toughest part would be to decide what would be the default value. Some
proposed to use the name of the constant, which is imho best for
debuggability (i like this one the best), or an auto incrementing int,
saying that it is better performance wise and which is more analog with
mysql's enum type.
So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signatures
--
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] $arr = array('Hello', 'world'); $arr();
On 2011-06-06, Hannes Magnusson hannes.magnus...@gmail.com wrote:
On Sun, Jun 5, 2011 at 17:52, Felipe Pena felipe...@gmail.com wrote:
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
I like it.
I also think we should implement callable typehint.
A lot of framworks are now adopting Closure as a typehint for that,
which is annoying due to the fact you have to wrap anything else in a
closure just to pass that typehint.
Agreed. It's even more problematic because the manual clearly states
that the Closure class is considered an implementation detail, and
should not be relied upon. As such, if the implementation changes in the
future, all those frameworks/libraries will need to refactor.
And for those that try to do it right, they need to jump through a
fair bit of logic (test for object or string, test for array) in order
to hand off execution properly.
Essentially the callable typehint would be the same as
is_callable($arg, true);
That means I can pass in any string with a function name, an array
(with class+methodname), and a closure.
+1.
--
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: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-05, Zeev Suraski z...@zend.com wrote: I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, This is a tough one. I'm typically in favor of having the vote be completely open to anybody. However, since we're talking language features, there are a lot of other considerations -- internals folks will have a much better idea of what the BC and support ramifications are. Perhaps two votes should be considered? A general population vote, and an internals vote? This would show discrepancies between what users of PHP want, and how internals is voting. If internals votes against a feature that the general population has approved, I would expect to see some sort of executive summary showing what technical issues are at play that led to the internals vote. This would serve as a good historical record -- and also potentially show where bias lies within the internals community. is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), I think anything less than a strong majority (2/3 or 3/4) often is indicative of either ambivalence or strongly competing ideas. The question is where that threshold should be set (I'd lean towards 2/3 vote.) can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, I'd argue a 2-3 week period in which to re-work the proposal and incorporate feedback from the prior discussion/voting periods. etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. Zeev -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, June 05, 2011 11:17 PM To: Zeev Suraski Cc: Pierre Joye; PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- 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: [PATCH] Notice on array to string convertion
On 2011-06-06, Ferenc Kovacs i...@tyrael.hu wrote: --00261883a59c62fbe404a50bd89c Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-02, Patrick ALLAERT patrickalla...@php.net wrote: I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. +1 (for E_NOTICE) This allows warning folks easily during development of potential issues, and for those of us using tools like PHPUnit, we'll catch the problem early. At the same time, it doesn't break existing code. I'm curious, why do you think that E_WARNING would break existing code? I didn't mean to imply E_WARNING would break existing code. However, I've often seen error handlers that break execution on E_WARNING and above -- and I'm not 100% convinced that this would be a situation warranting a warning. It feels more akin to a notice from accessing an unset array key. Either way, however, if I'm using PHPUnit, I'll be notified. :) the only think that I can come up with, that some people runs with display_errors = On, and they doesn't mask E_WARNINGs with error_reporting. I think that this would be more reason to use E_WARNING there, else those people won't get noticed about this problem. I personally run E_ALL | E_STRICT, so I catch either -- and log when in production. As noted, it's personal preference. I'm okay with either flag, to be honest. -- 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] Bundling modern extensions
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I can't think of a statement I would disagree more with. These are exactly the ones we should be bundling. My reasoning is simple. The key for bundling extensions is to have them available for most hosting solutions. If a shared host provides No. Join the real world again. Anything not in vanilla PHP is hard to install because it causes more work in maintenance of the server, and increases the risk of fuckups etc etc Can you please stay at a technical level? Thanks. I'm not going to argue if my experiences, feedbacks and interactions with any kind of projects is larger or longer than yours (it is as a matter of fact but who cares?). But one thing is sure, all distributions do include mongodb, memcache(d), couchdb, etc. If you can't run an apt-get install memcached (non core), just like you run apt-get install pdo_mysql (core), then there is something intrinsically wrong in your system. Or it means YOU DO NOT HAVE ROOT. Just because the distributions OFFER the extensions does not mean that users have ACCESS to them. Not everyone has complete control over their boxes, or sysadmins who are willing to update configurations. If the functionality were available as part of core, developers would simply have access, regardless of distribution and permissions. -- 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] Bundling modern extensions
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: It sounds like persons doing these inquiries do not know PHP, its environment and how it works, neither they know that 99% of the linux distribution (and in some extend on windows too) provide most of the modern extensions with their standard distribution. I disagree. Most distributions have a stock install that offers _less_ than a vanilla PHP install, and anything else has to be installed via the system's package manager, or via PECL (assuming you have the rights to install pecl extensions in the first place). So, while they may OFFER them, they're not available BY DEFAULT. For general purposes extensions or really globally useful (as any almost all php users will have a use), PHP's rapid rise in popularity initially was because it DID bundle the kitchen sink, and more, by default. Why was MySQL so popular with PHP in the early days (and still!)? Because it was available by default. Why are so many folks still not using an opcode cache, despite people saying for close to a decade that it should be the first stop towards improving performance? Because PHP has _never_ bundled one by default. Why is JSON so ubiquitous for interacting with PHP services? Because it's available by default. My point is that perhaps PHP has missed the boat a bit by moving everything into extensions. Perhaps if an extension is particularly popular, it should be incorporated into core. But let USAGE drive that, not the opinions of individuals on @internals. -- 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: Short syntax for Arrays (redux)
On 2011-06-01, Michael Shadle mike...@gmail.com wrote: On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates s...@seancoates.com wrote: This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error. Why not make your data in JSON and then $foo = json_encode($data) ? Why try to adopt JSON to PHP, just so it matches another language's format? You do realize adding JavaScript syntax for arrays will only make that consistent with JavaScript, otherwise you're still coding PHP with PHP syntax, functions, etc. for everything else. That argument seems moot. If you're more comfortable with JavaScript, start developing in node if that is your cup of tea. JavaScript is not the only target here. Many, many APIs are utilizing JSON either internally or as the mechanism for communication with other systems. Additionally, have you worked with complex data structures, and attempted to de/serialize to/from PHP? ext/json does fairly well, but there are many places where it fails, and many gotchas to consider to ensure things are serialized correctly. -- 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: Short syntax for Arrays (redux)
On 2011-06-01, Sean Coates s...@seancoates.com wrote: Now, the only reason I would personally support the array shortcut is if it was an implementation of JSON. I know that's not on the table here I don't think anything is officially off the table, unless we forego discussion. My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects—they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query. The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON. This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error. *applause* Well, said, Sean. Basically, this discussion should be likened to adding SimpleXML to PHP -- providing tools that make interoperability with other systems or languages simpler. -- 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 typehint
On 2011-06-06, Stas Malyshev smalys...@sugarcrm.com wrote:
Like I mentioned in the other thread (which I probably should had
repeated here), a lot of libs/frameworks are using the 'Closure'
typehint for callbacks.
Well, they are wrong (unless they mean to use only closures and not
callbacks). But that's no reason to do wrong thing in the language
too.
The problem with that is a function name as a string and
array(classname, functionname) are considered is_callable(). To
get through the intentions of the Closure hint, I would have to wrap
the actual callback in a closure - which doesn't make any sense.
callable is not actually even a type. If we make it a language
construct, then why 'authenticated DB connection', 'name of readable
file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
than 255 characters' or 'balanced binary tree' is not a language
construct? I don't think we need to put every data check into the
language, especially that it actually makes it worse - you can
gracefully handle user-space check, but not a strict typing error.
The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:
public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}
The typehint makes this simpler:
public function addCallback(callback $callback)
which allows us to rely on PHP's native error handling. I, for one,
would love to see this.
--
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: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-06, Chad Fulton chadful...@gmail.com wrote: So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. I think your analysis is great. That said, I think if this is the route ultimately taken, any time an RFC is voted out, a summary of the _technical_ reasons for denying it should be provided. Usually there are very good ones -- but this information can be invaluable to anybody who may want to ressurect the RFC in the future to ensure they don't hit the same pitfalls. -- 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 typehint
On 2011-06-06, Pierre Joye pierre@gmail.com wrote:
--0016e6de0029ddc06f04a5129914
Content-Type: text/plain; charset=ISO-8859-1
How is this argument different than the one in favor of type hinting (or
whatever was what ended in trunk)?
I was simply voicing my support for Hannes' patch, and trying to clarify
my understanding of it for Stas.
If you're comparing it to the scalar typehinting patch, I think it's a
far cry from that -- this is about providing a unified typehint for
functionality represented over multiple constructs in PHP, in order to
reduce code in applications. If it offers no BC issues, and allows
developers to simplify code and remove boilerplate (which can easily
introduce new errors on each iteration), then why wouldn't it be a good
idea?
On 7 Jun 2011 00:16, Matthew Weier Oapos;Phinney weierophin...@php.net
wrote:
On 2011-06-06, Stas Malyshev smalys...@sugarcrm.com wrote:
Like I mentioned in the other thread (which I probably should had
repeated here), a lot of libs/frameworks are using the 'Closure'
typehint for callbacks.
Well, they are wrong (unless they mean to use only closures and not
callbacks). But that's no reason to do wrong thing in the language
too.
The problem with that is a function name as a string and
array(classname, functionname) are considered is_callable(). To
get through the intentions of the Closure hint, I would have to wrap
the actual callback in a closure - which doesn't make any sense.
callable is not actually even a type. If we make it a language
construct, then why 'authenticated DB connection', 'name of readable
file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
than 255 characters' or 'balanced binary tree' is not a language
construct? I don't think we need to put every data check into the
language, especially that it actually makes it worse - you can
gracefully handle user-space check, but not a strict typing error.
The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:
public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}
The typehint makes this simpler:
public function addCallback(callback $callback)
which allows us to rely on PHP's native error handling. I, for one,
would love to see this.
--
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
--0016e6de0029ddc06f04a5129914--
--
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
