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
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
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
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 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 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 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 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
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
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
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
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
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.
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 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
> 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 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
>> > 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
>&
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
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
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
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
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
#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
/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
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 -
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
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:
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
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
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
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
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 &
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
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-
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 |
}
$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
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
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
'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
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
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:
> > > >
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
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
(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
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
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 { ... }
>> }
>>
f the biggest things I miss coming from perl to PHP.
--
Matthew Weier O'Phinney
Zend Certified Engineer
http://weierophinney.net/matthew/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the svn:externals point, and then use
"svn info" on that externals URL to determine what the current revision
is. When we build the tag, we then create a new svn:externals definition
for the new tag that pins to that specific revision.
I'll find the relevant code from our build scripts and paste it in here
if you need specifics.
--
Matthew Weier O'Phinney
mweierophin...@gmail.com
http://weierophinney.net/matthew/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not argue about thy
> syntax of the annotation because this isn't final.
Um, you're being contradictory here -- you're actually _suggesting_ a brand new
syntax, which leads to the exact opposite of what you assert. Using existing
docblocks and adding an annotations parser to it w
favor of the idea of
annotations.
(I'm still not entirely convinced that the same goals could not be achieved via
code written on top of a docblock parser extension.)
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.co
tors; it could be
used in a number of projects that scan docblock annotations in order to get
parameter and return value typehinting (we use this in ZF for the various server
classes), and more.
Let's argue this one on its own merits, and not on the basis of whether or not
it can be used for anno
BC breaks here are worth it -- they make the
behavior more predictable, easier to document, and easier to understand.
--
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
t
> as easy as it seems. You (or anybody else) is welcome to try and prove
> me wrong with a good RFC, though :) But take care to actually go a
> number of steps beyond simplest use cases - that's where the trouble starts.
Exactly -- I know a number of the edge cases already.
I'll see if I can find some time after ZendCon to write something up...
and somebody willing to work with me to see if it's possible. (I can
write tests...)
--
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
in trunk, only a
vague idea about what may or may not be ready, and competing ideas about
what constitutes grounds for branching. "Just go with it" may work for a
few people, but that sort of attitude leaves those whose features were
skipped over or who were away from the list and/or IRC f
unable to make the deadline. "I can't
do it by this release, but I should have no trouble making the next."
* Less stressful for release managers. If the code isn't ready by the
deadline, it's not merged to the branch, plain and simple.
The status quo works great f
e, the app will still work so
> I am not buying your "two flavours" argument.
While the code may still work, it won't work *as* *expected*. If the
PHP interpreter can execute the application, then it should provide the
same output given the same input -- and this would not be the
ut discovery is a lot harder.
Perhaps. But that's what mailing lists, issue trackers, and blogs are
for. I've had very little issue with discovery, to be honest.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.
the ZF1 trunk to ZF2 master is often a matter of hours;
with SVN, this process was so daunting, we simply wouldn't do it in
favor of creating new branches and starting over.
--
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
is.
>
> Leaving the very small conference crowd for a second: nobody never
> ever heard of php6 before the total fiasco a couple of months ago.
Not true. There have been "PHP 6" books *published* and on the market
for literally years.
--
Matthew Weier O'Phinney
Pr
l. It often aids readability to use fluent
interfaces when performing operations that are simply changing state,
and being able to call the setters directly would make that possible:
$time->setHours(3)
->setMinutes(17)
->setSeconds(34);
Additionally, this seems like a ver
to "class" or "trait" and "get" to "__get" you
> need almost no new syntax :)
Not really. With __get() and __set(), it's entirely likely that the class into
which the trait is mixed in might override this already -- and not take into
account the prope
y itself exists. But once defined, a property always exists
>> (think of methods, for example).
>>
>> (Sorry for sending again Stas, I forgot to reply all)
>> - Dennis
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubs
n opcode cache, the notion of compile time as a
differentiation from runtime in PHP has little relevance -- you still
only find out when the script executes.
There's already a way to mitigate this as well: write a testing suite
for your application, and exercise it often. If you write your test
On 2010-12-10, Nathan Nobbe wrote:
> --0016e6d7e101e083a4049714bad3
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney <
> weierophin...@php.net> wrote:
>
>> On 2010-12-10, Nathan Nobbe wrote:
>> >
s used at all).
>>>
>>
>> I don't thinks it's that confusing. This new option just prevents PHP from
>> doing any automatic reading and processing of the POST data, leaving it
>> entirely on the hands of the programmer to that, if he wishes, through
>> php
On 2010-12-16, Pierre Joye wrote:
> On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
> wrote:
>> On 2010-12-16, Pierre Joye wrote:
> > The only way I can see such an action being "sensible" is if it's also
> > runtime configurable (i.e., via i
there is no way
> around properties. However, there should be a way that a developer
> can notice that the code might not behave as expected in the composed
> class.
+1
The test cases you include are exactly how I would expect traits to work
with regards to properties.
--
Matthew Weie
c on conflicts, though -- just with
the highest declared visibility (e.g., if one trait defines as private
and the other as protected, protected wins).
--
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
reating backwards compatibility
> issues or creating future problems. As for the secondary suggestion I made,
> allowing namespaces to be specified in the include statement, I'll drop that
> from this recommendation to focus on the changes to tag style setting.
>
> --0016e6da
On 2010-12-19, Stefan Marr wrote:
> On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote:
> > Exactly. I wouldn't default to public on conflicts, though -- just with
> > the highest declared visibility (e.g., if one trait defines as private
> > and the other as
;PF','private function _');
>>> MACRO('SCOPE_CLASS','class MyProject_');
>>>
>>> class UseMacro
>>> {
>>>PF preSave($object)
>>>{
>>> //...
>>>}
>>>
>>> }
>&g
pport to nothing at all. I've been bitten by the same issue Stas describes,
and having a way to tie into touch and chmod in my stream wrappers would be
incredibly useful -- even if it won't work with _every_ stream.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend
e ternary operator much more
> > useful to me e remove lots of verbose code for handling arrays.
>
> Well, it would change the semantics. And Ben, no, it isn't shorthand for
> an isset() it is like writing (boolean)$var?$var:$something
It may change the semantics as they stand,
;s not uncommon to use nested arrays or
objects for configuration -- and configuration is one place where you
may or may not have values. Having a shortcut to retrieve the value if
present or provide a default is not just laziness, but also a way to
improve your coding -- by removing yet another pl
out this? And how about applying the
>> >>>> current/revised patch to trunk thus making it easier to play with and
>> >>>> break, but not freeze its features/API yet.
>> >>>>
>> >>>> Also the wiki is up again so:
>> >&
for the language and very bad for all of users.
>>
>> That's simply not true. But just because one group of users feel strongly
>> about something doesn't mean it should go in. There has to be some level of
>> curation or we end up with every feature under the sun
Doc annotations).
A native docblock annotation parser would much better suit our purposes.
So, basically, we're in a situation where there's no consensus on
whether the feature is needed or what the approach should be, and people
pointing fingers at eachother indicating the other party is
or annotations than introducing a new syntax. Others have stated the
same. I'd like to see why a new syntax is considered "necessary", and
why native support for docblock annotations is not considered a
reasonable path.
--
Matthew Weier O'Phinney
Project Lead
included in RFC the links to .NET and Java implementation examples.
I'm not one of those people. I already know that the support exists
elsewhere. I'm simply not convinced we need anything outside of the
ability to grab annotations from docblocks -- something that can be done
in userland n
On 2011-05-10, Ferenc Kovacs wrote:
> --bcaec51a7af89cba6304a2f01d01
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, May 10, 2011 at 8:20 PM, Mike Robinson wrote:
>
> > May-10-11 11:57 AM Matthew Weier O'Phinney wrote:
> >
> > > A native docblock
core dev community to grow and
> at its current state it doesn't seem to be able scale due to the lack of a
> roadmap/process.
>
> I'm not trying to be a douche here, just saying: I see lots of criticism
> towards everything and very few agreements.
>
> Best regards,
>
>
ocs were taking between 80 and 110 minutes with phpDocumentor, and
consuming ~2GB of RAM. They now take around 10 minutes and consume less
than 1GB of RAM. :)
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: ht
erencing)
>
> http://marc.info/?l=php-internals&m=129080024516125&w=2
> https://wiki.php.net/rfc/instance-method-call
One thing not on the RFC that I'm curious about: if the class defines
__invoke(), would the following work?
new MyClass()();
That would be particularly
>
> 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'Ph
iki.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, thou
ing 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 tremendou
> - 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.c
ly.
> 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.
hind 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
On 2011-06-06, Ferenc Kovacs 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 wrote:
> >
E 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
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 Developme
ny 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 t
t; 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 S
k($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
s 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
plications. 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 O'Phinney"
> wrote:
> > On 201
e --
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
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
1 - 100 of 154 matches
Mail list logo