ehavior at that time? Will an exception or error be thrown? If
so, will it be a new one, or an existing one?
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
a different mechanism so you
can use standard conditional branching.
As such, there are a lot of situations where I may not want to use
exceptions. Two common ones:
* Input validation. In most cases, _invalid input is expected_, and a
condition you will handle in your code. Exceptions are a really poor
mechanism for this.
* "Not found" conditions, such as not finding a matching row in a database
or a cache. Again, this is expected, and something you should handle via
conditionals.
Currently, there's no _generic_ way to handle these sorts of error
conditions from functions. You can create "result" types specific to each
operation, but this is a lot of boilerplate. You can resort to exceptions,
but these are a poor fit due to performance and logic flow.
I'm currently not yet convinced on the proposal Larry is making, but I
definitely understand what's driving it, and would love a language-level
solution.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall wrote:
>
>
> On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a stri
On Mon, Aug 26, 2024, 12:02 PM Larry Garfield
wrote:
> On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> > wrote:
> >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> >> > You're absolutely right, I would be interested to see any via
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall wrote:
>
>
> On Aug 24 2024, at 12:49 pm, Bilge wrote:
>
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
>
> Seems like you are missing an optio
On Sat, Aug 24, 2024, 11:50 AM Bilge wrote:
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
This is a feature I've wanted for a very long time! The RFC is very
straight forward, and the appe
On Tue, Aug 20, 2024, 4:56 PM Rob Landers wrote:
>
>
> On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote:
>
> On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote:
>
>
>
> On 20 August 2024 00:21:22 BST, Rob Landers wrote:
> >
> >I assume you are worried about something like this passing
On Tue, Jul 23, 2024 at 9:06 AM Larry Garfield
wrote:
> On Tue, Jul 23, 2024, at 1:42 PM, Matthew Weier O'Phinney wrote:
> > On Fri, Jul 19, 2024 at 12:41 PM Gina P. Banyard
> wrote:
> >> Hello internals,
> >>
> >> I have opened the vote for the meg
no mention of this character as a wildcard anywhere in that
RFC.
Can somebody clarify?
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Sat, Jul 20, 2024, 9:31 AM Tim Düsterhus wrote:
> Hi
>
> On 7/19/24 00:51, Christoph M. Becker wrote:
> > And frankly, how much code would be affected? I mean, does anybody
> > actually put a comment between `yield` and `from`? Is there a case
> > where this may make sense? "Because we can"
what problems_ the current approach of
using namespaced code doesn't address. I can definitely see a need for
marking things as package private (i.e., not part of the publicly
consumable API), but that also feels like something we could address in
other ways. I know Larry has asked this same question before, and it's
really what I want to see answered, because packages might be the solution,
but there may be other approaches we could take that also accomplish those
goals.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Jun 24, 2024, 7:35 PM Stephen Reay wrote:
>
> Sent from my iPhone
>
> On 24 Jun 2024, at 23:43, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
>
>
> On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas <
> nicolas.grekas+...@g
quot; format to mimic the notation that
Composer uses on the CLI when specifying a package with a constraint:
"symfony/yaml:7.2.0". This can be parsed easily, and won't suffer from
having arbitrary spacing and version naming prefixes.
(Still would prefer a "scheduledRemoval" field, as knowing when it was
deprecated is far less interesting than knowing when it will be removed.
Yes, I can assume the next major version, but what if it's major version +
1? What if a project allows removals during minor releases? Knowing what
version it will be removed in makes it far easier to understand what will
happen when I upgrade next.)
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Thu, Jun 20, 2024, 1:27 PM Niels Dossche wrote:
> On 20/06/2024 16:28, Matthew Weier O'Phinney wrote:
> >
> >
> > On Mon, Jun 10, 2024 at 1:15 PM Niels Dossche <mailto:dossche.ni...@gmail.com>> wrote:
> >
> > Hi internals
> >
> &g
Niels
>
Question: why is `Dom\Document::$head` marked as readonly?
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
On Mon, Jun 3, 2024 at 9:46 AM Ilija Tovilo wrote:
> Hi Matthew
>
> On Mon, Jun 3, 2024 at 3:15 PM Matthew Weier O'Phinney
> wrote:
> >
> > On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer
> wrote:
> >>
> >> The vote for the RFC #[\
eprecated. What would be far more
useful to a consumer is an argument indicating when something will be
removed (e.g. $toRemoveInVersion, $versionForRemoval, etc.). This helps me
as a user plan for the future.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
e);
// 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
ame less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
I personally would go with just "accessors".
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/
he/him
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
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 bui
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,
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
t; 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 p
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
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
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,
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
> >
annot
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
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 cha
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=8146
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
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
htt
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 pr
g 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
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 { ... }
>> }
>>
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 "fak
(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# sem
locks 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
t;>
>> 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\B
On 2012-07-13, David Muir wrote:
> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
> > On 2012-07-12, Sara Golemon wrote:
> > > --e89a8f235453d7a80104c4975c55
> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara
> > > wrote:
> > > >
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
'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-p
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 doSomethi
ing
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
}
$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
req
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 |
riable, 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-
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 aft
On 2012-04-19, Patrick ALLAERT wrote:
> 2012/4/18 Matthew Weier O'Phinney :
> > My one comment, which others have raised, is readability of multiple
> > commas -- TBH, at first glance it has the appearance of a mistake. I
> > think those suggesting a keyword such as &
n 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.co
nnotations 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 I
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
On 2012-04-13, Kris Craig wrote:
> --f46d04447f47ae95ec04bd949e5f
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw
> wrote:
>
> > > >
> > > > On top of this, there's an argument that you're not addressing: most
> > > > template engines in PHP eit
es
(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:
the expense once per file.
> On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
> wrote:
> > On 2012-04-13, David Muir wrote:
> > > On 13/04/12 14:55, Stas Malyshev wrote:
> > > > > If this is a pecl module library developers cannot use it and trust
ocal 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 -
/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
#x27;t it also be handled using streams to inject a leading file prior to inclusion? A PECL extension would then just make it run a
> bit faster.
I made this very suggestion earlier this week (we do this in ZF1 to
emulate short tag support for those who use them).
--
Matthew Weier O'P
s a symmetry to how "use" is used when
importing classes/namespaces; I've often attempted to use "as" within my
closure use statements, only to get burned.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framewo
On 2012-04-09, Tom Boutell wrote:
> There's a reason I didn't try to kick this out as a fully formed RFC (:
>
> The choice of @ is a nonstarter, yes. I forgot that start code for PHP already so it is already valid PHP to write http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matth
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 process
uot; 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
HP:
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 val
>> > 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
>&
On 2012-03-05, Pierre Joye wrote:
> On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney
> wrote:
>
> > +1.
>
> Votes are for later.
This was an indication of being in favor of the proposal, no more, no
less.
> > Since so many distros and ISPs tend to
> 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 Weie
on 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
ents 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.
--
Matt
On 2012-03-02, David Soria Parra wrote:
> just a heads up. The PHP_5_4 branch is open for commits again.
Related: With 5.4.0 out... how soon will the cutover to git occur?
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.
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 lang
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 no
ixed 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...@ze
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 hand
alidation
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
On 2011-12-02, Rasmus Lerdorf wrote:
> On 12/02/2011 08:50 AM, Matthew Weier O'Phinney wrote:
> > if (!(($validator = new SomeValidator())->isValid($value))) {
> > // Validation failed, get messages...
> > $view->assign(&#x
rrors' => $validator->getMessages());
return $view->render('error');
}
// validation passed, do something...
Yes, this could be written as follows:
$validator = new SomeValidator();
if (!$validator->isValid($value)) {
// ...
}
On 2011-11-30, Sebastian Bergmann wrote:
> Am 30.11.2011 19:09, schrieb Ralph Schindler:
>> $value = ($obj = new Foo)->produceAValue();
>
> -1
Just curious: why?
(Not that I'm 100% sure I agree with it myself, but curious why you
would vote against it...)
--
Matthew
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
dled, 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'P
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
an 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
eded 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
Z
On 2011-10-26, Pierre Joye wrote:
> On Thu, Oct 27, 2011 at 1:07 AM, wrote:
> > 2011/10/26 Matthew Weier O'Phinney :
> > > My main point, however, is that the standard was ratified quite some
> > > time ago already -- we just now have parties intere
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
ssB::MethodTwo());
>
> ?>
>
> // prints
> string(17) "ClassA::MethodOne"
> Fatal error: Undefined class constant 'self::VERSION' in
>/testbug.php on line 14
That makes complete sense to me -- ClassA is referring to self, which
resolves to ClassA... whi
,
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?&
P'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
he 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 $_
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.zen
oken, 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 undocum
t; 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 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
mi
- 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
On 2011-08-14, Derick Rethans wrote:
> On Sat, 6 Aug 2011, Ferenc Kovacs wrote:
> > I would like to introduce this RFC which would provide function
> > autoloading through the spl_autoload facility without userland BC
> > breakage.
> >
> > https://wiki.php.net/rfc/autofunc
>
> I understand the pr
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,
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://frame
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 fu
ng, 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 ha
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 Inte
1 - 100 of 156 matches
Mail list logo
