While it's technically safe to include user supplied data in
json_encode() serialized values. The fact that characters such as '
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data to
While it's technically safe to include user supplied data in
json_encode() serialized values. The fact that characters such as '
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data to
While it's technically safe to include user supplied data in
json_encode() serialized values. The fact that characters such as '
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data to
looks like this unidentified problem is not specific to json
On 11/29/07, Sara Golemon [EMAIL PROTECTED] wrote:
While it's technically safe to include user supplied data in
json_encode() serialized values. The fact that characters such as '
remain as is means there room for some as-yet
Stanislav Malyshev wrote:
You're absolutely correct that this won't save us from brain-dead
engineers, what it will save us from is broken browsers which
misinterpret otherwise legitimate data and get broken out of their
proper context. (Yes, I've seen browsers do exactly this, and you can
One thing to consider is changing json_encode to add a header
Content-type: application/json (or x-javascript), unless the additional
arguments are used..
That way someone using the function to intermingle with HTML will be
faced with the fact they have to encode the output, otherwise it breaks
payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
script
var =
I also wrote a similar public domain implementation of MD4, which I can
provide for inclusion in hash_md.c if there's any interest.
No objections from me on replacing the implementations in ext/hash.
Those were written with functional correctness in mind, not speed. So
long as the test
Sam Barrow wrote:
If anyone here is experienced enough to help me, I will pay for a patch
to allow for multiple class inheritance (class D extends A, B, C)
against PHP 5.3 CVS. Or if you can just help me get started on writing
it, I'm sure I could finish myself. I'm just stuck at the basic zend
The attached patch implements automatic decoding of chunked
transfer-encoding.
Any objections against committing the patch into PHP_5_3?
I didn't have objections when I offered this filter several years ago,
and I still don't. I do recall Andi (or perhaps it was someone else)
saying it was
Now, I'll take some blame here for not being involved over the past
couple years and having not noticed this inanity sooner, but could
someone explain this cluster-f?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_API.h?r1=268281r2=269153
This breaks the existing module API
At first I don't understand why you are trying to deallocate variable.
+ if (CG(active_op_array)-T == (parent-u.var - 1)) {
+ CG(active_op_array)-T--;
+ }
Isn't the same variable reused as result of ZEND_FETCH_DIM?
Yeah, I hastily recanted that
OK. Now your patch will work, but I would like to
think about more elegant solution.
The problem that I am busy with other work.
Could you please wait a week and then commit it if
I won't return (on the next Tuesday).
Argh. Can we please accelerate this somehow?
This patch is necessary
Dmitry-
You asked for it, you get it :) Hopefully it'll be self-explanatory,
the one part I hope you don't notice is that I put the auto_global check
back into fetch_simple_variable_ex in order to force direct access to
autoglobals ($foo = $_GET;foreach($_POST as ...) etc...) as
I fixed one error in your patch, so now it passes all tests.
Which error? I notice some changes related to minimizing performance
impact, but I'm not seeing what I did wrong. Just curious for my own
benefit on that one.
BTW I am against this patch.
Fair enough.
1) It adds sloppily
I fixed one error in your patch, so now it passes all tests.
Which error? I notice some changes related to minimizing performance
impact, but I'm not seeing what I did wrong. Just curious for my own
benefit on that one.
BTW I am against this patch.
Fair enough.
1) It adds sloppily
Btw, having a request object was one of the #1 requests in framework
:) People actually really like encapsulating this because it
also makes unit testing easier down the road...
Just mentioning this because I don't think we should be too set with
our ways esp. for people who need to
Personally, I try to follow commits on
php.cvs, bug reports, Change Log,
user notes on the online manual..
but I still have the feeling of missing
a lot of changes. After a year away from
the project, I have _no_ clue what was
added, when, and whether it was added
to our documentation or not.
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array(foo, bar)) == [1, 2, [foo, bar]]
array(key = 1, key2 = 2) == [key = 1, key2 = 2]
An enthusiastic thumbs-sideways.
I'll probably use this at some point, but not for anything which needs
to be version agnostic.
-Sara
To facilitate this, I propose that we create a new directive called
extensions_path that allows the sysadmin to configure a search path for
extensions. I see the usage as going something like this:
extensions_path = /local/extensions:$DEFAULT_EXTENSIONS_DIR
Seems very useful and a good tool
I would argue that list() (and [] when used like list()) should remain a
terminal expression. Yes it's possible to make it non-terminal, but I
don't like what the resulting syntax winds up looking like.
-Sara
Good question. If it's possible to make it behave this way, I don't see
why not.
Doesn't seem like this ever got commited.
Can we include this in PHP 5.2.2? It doesn't break existing APIs so I
think it's a good idea.
I think adding bignum functions is OK (though it duplicates GMP to a
measure) - while we are at it, why not add implementation for
btwoc(number) also?
I'd
I am working on a command line client (written in php, run by php-cli)
and I'd like to use a password entry as in mysql client - with no
echoing etc. I've found the function which I need:
#include unistd.h
char *getpass( const char * prompt );
But in man getpass it is marked as
Stanislav Malyshev wrote:
FWIW, this doesn't work with the other superglobals (in function
context):
[EMAIL PROTECTED]:~$ php -r '$_GET[foo] = bar; function baz() { $get =
_GET; return ${$get}[foo]; } $get = _GET; echo ${$get}[foo],
baz(), \n;'
bar
Notice: Undefined variable: _GET in Command
Stanislav Malyshev wrote:
$_SCOPE doesn't need to be that special... It can just be an object
with overloaded array access... Whenever a dim is fetched for that
object, check current_execute_data-prev-symbol_table for the
variable and return that.
Once again - current_execute_data-prev at
Ian Young wrote:
Hi all,
I'm applying for one of PHP's Google Summer of Code projects. The ideas
page (http://www.php.net/ideas.php) includes this text: If you are
applying for a project in the PHP code itself (in C), you may find
useful the PHP hackers guide, which also includes our C coding
Ditto Richard's comments about false-implications of security, but I'd
also like to add that *IF* folks decide on the whole that this is worth
adding, it should be done more generically than a setting for md5 and a
setting for sha1.
e.g.
input type=hidden name=__COMPUTE_HASH value=md5
or
Currently, an empty check like the following returns false because
SimpleXML only checks for node existence in has_property. I'd like to
propose the attached patch to change this to look at the node's children
and apply PHP's emptiness rules to the content.
$data = '?xml version=1.0 ?
doc
Attached is a patch which exports an internals hook in zend_class_entry
for fetching function pointers similar to the object hook get_method()
available to instance methods.
This patch also exports a userspace hook __call_static() which operates
in the fashion of the current __call() magic
Thomas Moenicke wrote:
This is actually a very good idea. I had to put a hook into the opcode handler
for static method calls to get the same result which is not really elegant. I
was waiting for this feature for a couple month.
Also I found out that the names of the static methods are already
I'll probably be lynched for bringing up this subject again, since it
caused a long discussion a year ago. Anyway I look in the archives and
there was never a real conclusion made, so I'm bringing it up again.
This time for a feature I personally would like to see in PHP 6.
Very often I want
Sara Golemon wrote:
Attached is a patch which exports an internals hook in zend_class_entry
for fetching function pointers similar to the object hook get_method()
available to instance methods.
This patch also exports a userspace hook __call_static() which operates
in the fashion
[EMAIL PROTECTED] wrote:
On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
I won't applay it to HEAD without php-5.
I need it in php-5. HEAD may wait.
We all need it to 5. But we also need it to test it before it goes to
the stable branch.
I would really love to get back our
Etienne Kneuss provided me a patch to handle static called class methods
properly - it works fine. Now i need antother patch for:
__static_call_patch
__static_set
__static_get
where can i find it?
__staticCall() is already in PHP6. __staticGet/Set/Isset/Unset don't
exist (yet).
-Sara
--
So I looked at the code and came up with this
change for http_fopen_wrapper.c line 547
(http://lxr.php.net/source/php-src/ext/standard/http_fopen_wrapper.c#547):
if ((options STREAM_ONLY_GET_HEADERS) ||
(php_stream_context_get_option(context, http, ignore_errors,
tmpzval) == SUCCESS
Did the voting close already? One day seems awfully short. :(
On Wed, Jul 18, 2012 at 7:54 AM, Laruence larue...@php.net wrote:
Hi:
Call for voting for Allow use T_AS in closure use statement,
https://wiki.php.net/rfc/useas#voting
any comment will be appreciated.
thanks
--
For all the reasons already stated, most explicitly because it make the
code ugly as sin, my vote is somewhere between No, and Hell No.
-1 on bracketless try/catch
On Thu, Jul 19, 2012 at 2:44 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi internals,
As you certainly know,
For this type of situation, you could equally go with something like:
zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, n, val) == FAILURE)
{ RETURN_NULL(); }
Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as is,
IS_STRING/IS_OBJECT (with toString() behavior)
Same as you would in PHP code. Make an IS_STRING pointing at a global
function, or IS_ARRAY pointing at a class method, or an IS_OBJECT
supporting __invoke(). If you're asking how you can call a C function
directly via this callback: You can't. You can can, however, make an
internal method to
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds ajf...@googlemail.comwrote:
I think PHP could benefit from making arrays, strings, integers,
floats, and possibly booleans, into pseudo-objects. By this I mean
that they are not really objects (they are still primitive types and
keep their
Then I'm not sure what problem you're trying to solve either. :/
On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon poll...@php.net
escreveu:
For this type of situation, you could equally go with something like
. Granted this is a bit
of a hack and won't work for all situations. Your approach is more
comprehensive, just saying that for many cases it's not strictly needed.
-Sara
On Thu, Jul 19, 2012 at 2:33 PM, Nikita Popov nikita@gmail.com wrote:
On Thu, Jul 19, 2012 at 11:23 PM, Sara Golemon poll
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajf...@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the same
thing.
Fair enough, noone is talking about giving them properties or formal class
definitions.
And what do you mean by technical debt?
I mean
do I make my objects have scalar passing semantics, then?
On Jul 20, 2012 12:35 AM, Sara Golemon poll...@php.net wrote:
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds ajf...@googlemail.comwrote:
I never said treat them as objects. I said give them methods. Not the
same thing.
Fair enough
My first thought was how could someone reading the code see, that it
is a generator?
Somewhat snarky answer: By documenting the code in the first place.
Yeah, I know, we all inherit other people's code and the other person never
writes comments.
I don't think this is as big of a problem in
Or when you have programming errors, when you write
function blubb()
{
... yields...
...
... return
}
(you may only see the return).
But that's okay, because PHP *does* see both, and it tells you yield may
not be used with return in a lovely little parser error. Some developers
Suggestion:
For a generator, rename the keyword function to ... generator or
something like that. Example:
generator hugo()
{
yield ...
}
As Nikita pointed out, having a T_GENERATOR token will cause side-effect
problems from namespace collisions. This is a concern any
The micro benchmark is just that, and is not as far as I can see testing
the sort of iterating process that would happen normally when going through
a data set. It simply times the iterator, but does not compare like with
like!
I hear your concerns about performance, and you're good to
For all those things you probably shouldn't have been doing anyway
That description is on the package because you... probably shouldn't
be doing these things.
Further, any discussion of runkit should focus on individual features of it.
Custom Superglobals: I consider these fairly
On Thu, Aug 2, 2012 at 4:17 PM, Leigh lei...@gmail.com wrote:
Sandboxing: Complicated by the fact that it only works in a threaded
build, can't transfer all types (e.g. resource, complex objects), and
can't run concurrently. Until/unless these problems can be
meaningfully solved, I wouldn't
On Aug 2, 2012, at 17:16, Ángel González keis...@gmail.com wrote:
On 03/08/12 01:22, Sara Golemon wrote:
In all seriousness, I'd love to hear how you'd do Sandboxing without
using the tsrm context hack I used in runkit. That approach had
nothing to do with being in PECL, it had to do
http://wiki.php.net/rfc/uconverter
Discuss!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
- the UCNV prefix is not necessary, we are in the UConverter class
already, I would simply use LATIN_1, or ILLEGAL for exampe.
- I would add ERROR_ to the error related constants (UNASSIGNED co), or?
For the UConverterType enum I could maybe get behind that. For
UConverterCallbackReason I
1. transcode() accepts options, but there's no comparable way to set
options to the object. I think these APIs should be synchronized.
Imagine code keeping options in array/config object - it's be really
annoying to have two separate procedures to feed these to object and to
transcode().
With the exception of renaming the UConverter::UCNV_* constants to
remove the UCNV_ prefix, I believe I've addressed the concerns thus
far. ((Waiting to hear if anyone else wants to weigh in on the
contants)) The RFC has been updated accordingly.+
--
PHP Internals - PHP Runtime Development
ahar...@php.net wrote:
On 31 October 2012 06:18, Sara Golemon poll...@php.net wrote:
With the exception of renaming the UConverter::UCNV_* constants to
remove the UCNV_ prefix, I believe I've addressed the concerns thus
far. ((Waiting to hear if anyone else wants to weigh in on the
contants
The requisite one week minimum has passed and there have been no
further comments since my last update (which addressed all comments
thereto) so I'm opening the voting process on
https://wiki.php.net/rfc/uconverter
Cheers,
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To
Sorry to be late to the conversation, but fwiw, HipHop is adding
Generics (and some other cool things) to our PHP implementation. We
plan to provide a PHP equivalent implementation in the form of a
pre-processor extension which can live in PECL. The implementation
would of course be cleaner if
for the record, it is one week minimum, not maximum :)
If you think that the implementation details are solved and ready to be
voted on, then heh, go ahead :)
On Mon, Nov 5, 2012 at 6:26 PM, Sara Golemon poll...@php.net wrote:
The requisite one week minimum has passed and there have been
against it.
-Sara
On Tue, Nov 6, 2012 at 12:48 AM, Lester Caine les...@lsces.co.uk wrote:
Sara Golemon wrote:
There doesn't seem to be any further discussion. I figured if someone
has more objections during the week this stays open for voting they
can be addressed, and if need be the voting
would look like? Maybe this
is a good moment for HipHop and PHP to do something together.
Am 06.11.2012 um 04:14 schrieb Sara Golemon poll...@php.net:
Sorry to be late to the conversation, but fwiw, HipHop is adding
Generics (and some other cool things) to our PHP implementation. We
plan
From: http://php.net/manual/en/language.operators.comparison.php
An object compared to anything which is not a bool, null, or object
should result in the object appearing to be greater than the other
operand. For example:
$a = new stdClass();
$b = new stdClass();
var_dump(null $a);
It's been a few weeks since voting opened and it's unanimous so far.
If no one objects I'll plan on pushing into git on Friday.
On Mon, Nov 5, 2012 at 9:26 AM, Sara Golemon poll...@php.net wrote:
The requisite one week minimum has passed and there have been no
further comments since my last
https://wiki.php.net/rfc/request-tempnam
Just a bit of hand-holding for those who don't remember to clean up
their messes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
An obvious question is: When in shutdown should that be called? Assume I
have a session handler which uses such a temporary directory which is
backed by a custom stream while having a registered shutdown function
accessing that session (what did i forget to put into that scenario?)
Is this
I've being reading about HHVM and the numbers are looking great but I was
just wondering if we will we ever see something like HHVM being added to
the PHP core?
No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach
is not something any of us are looking at.
To echo Rasmus'
On Mon, Nov 26, 2012 at 9:09 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/26/2012 09:03 PM, Sara Golemon wrote:
P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)
I think you misread my reply. I specifically said that a JIT
, 2012 at 2:37 AM, Sara Golemon poll...@php.net wrote:
On Mon, Nov 26, 2012 at 9:09 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 11/26/2012 09:03 PM, Sara Golemon wrote:
P.S. - I do disagree with Rasmus' statement about none of us looking
at fitting a JIT into PHP. ;)
I think you
It's been awhile since I last commited (pre git, in fact) and now I'm
getting a failure during 'git push'. It asks for my password, I enter
it, it asks again, I enter again, and I get a permission denied error.
Do I need to do something to update my access? I've done a password
change on
/2012 05:02 PM, Sara Golemon wrote:
It's been awhile since I last commited (pre git, in fact) and now I'm
getting a failure during 'git push'. It asks for my password, I enter
it, it asks again, I enter again, and I get a permission denied error.
Do I need to do something to update my access
Yeah, a subsequent push picked it up. Don't think we need to worry
about cronning it, but I'll add a note to the git workflow page
mentioning how recovery works in this situation for future reference.
On Sat, Dec 8, 2012 at 7:28 AM, David Soria Parra d...@php.net wrote:
On 2012-12-05, Sara
Last july Gustavo (cataphract@) committed
980dc7111bc1d1e759c5b6044f6e7d203915d81f zend_parse_parameters: allow
! for non pointers which is awesome, but it creates a difference in
behavior between pointer and non-pointer types when used with the '!'
modifier. So before 5.5 hits freeze, I'd like
Opening RFC to allow trailing comma in function call argument lists
https://wiki.php.net/rfc/trailing-comma-function-args
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
ro...@kingsquare.nl wrote:
Just a question from one of the lingering listeners: would this change also
ease the `skipping` of default values for parameters? (as discussed for RFC
https://wiki.php.net/rfc/skipparams)
That way
On Tue, Feb 19, 2013 at 6:51 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
While I think it's a good idea I just have one question about the
implication of the change. Does this mean that null will be passed to the
function argument when a trailing comma remains?
No. The trailing comma is
On Wed, Feb 20, 2013 at 12:47 AM, Florin Razvan Patan
florinpa...@gmail.com wrote:
For example, I would expect that if I have:
function A($b, $c = 'd') {}
when I see A($b, ) to have no syntax errors but rather $c defaulted to
the value in the function signature, which is not implied nor
On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon poll...@php.net wrote:
Opening RFC to allow trailing comma in function call argument lists
https://wiki.php.net/rfc/trailing-comma-function-args
For the record, I've updated the RFC just now to include
function/method/closure declarations as well
On Wed, Feb 20, 2013 at 3:32 AM, Martin Keckeis
martin.kecke...@gmail.com wrote:
-1
For array it's okay, but for functions? I think the code is harder to read
that way...
If I would see a call written this way:
phpinfo(,)
There are three possible values: Defaultvalue, null or something
PHP 5.4 added support for expressions of the kind (new Foo)-bar(), (new
Foo)-bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
A winner is you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
(For me, it's changes like Sara's trailing comma proposal that are too
small to have needed an RFC)
When it comes to changing syntax, there is no such thing as too small
of an RFC IMO. Runtime changes can occasionally be hand-waved, but
syntax changes are serious business.
-Sara
--
PHP
When it comes to changing syntax, there is no such thing as too small
of an RFC IMO. Runtime changes can occasionally be hand-waved, but
syntax changes are serious business.
Seeing this quoted makes me realize I expressed myself poorly. What I
meant to convey was:
When it comes to syntax
On Mon, Feb 25, 2013 at 2:35 AM, Pierre Joye pierre@gmail.com wrote:
While reading both PRs and features requests in bugs.php.net, I would
like to strongly suggest to make any new proposal (new features, PRs,
etc.), no matter how small, targeting 5.6 or later.
5.5 will go in beta soon and
Before drafting an RFC I would like to gauge interest in adding:
get_object_constants and get_class_constants
I have already drafted up a PR with the changes and supplemental data:
https://github.com/php/php-src/pull/292
You took the time to make a PR, but not an RFC? This should really be
On Wed, Feb 27, 2013 at 3:06 AM, Zeev Suraski z...@zend.com wrote:
Are there any additional clarifications and/or unanswered questions people
are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?
It's been nearly a month since the RFC was posted and there's been
On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon poll...@php.net wrote:
Opening RFC to allow trailing comma in function call argument lists
https://wiki.php.net/rfc/trailing-comma-function-args
Some unofficial votes going either way... Let's open the voting to
see where things fall.
https
Making this a new thread per rfc process:
Voting is open on https://wiki.php.net/rfc/trailing-comma-function-args#vote
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
${'_'.!$_=getCallback()}();
Well now, that's an... interesting abuse of resolution order and type juggling.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I noticed that multiple people who expressed support for the RFC on this
thread have since cast No votes on the RFC. I'm confused. Does No
correspond to supporting the idea in this case, or did something happen
outside this thread that changed people's minds about it?
They probably just
https://wiki.php.net/rfc/php-array-api
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I would like to kill other APIs in next major as well, time for
cleanup and ease maintenance. Yes, it is a bit more work for
extensions developers but as you plan to do pecl releases as well for
these inlined functions, that should be a good thing in the long run.
I'm not sure how you plan to
Nice API, I am a bit worried though about conversion routines.
Specifically, php_array_zval_to_double() uses different conversion
algorithm than PHP's standard zval to double conversion, which may
result in different results in edge cases. Also, these functions seem to
duplicate existing
1a) The c modifier seems like an unnecessary microoptimization. Compilers
should be able to optimize strlen() calls on constant strings away and even
if they didn't, it wouldn't be much of a big deal. Also using the
c-variants on a non-literal would not throw an error and just use an
invalid
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.
https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think it's a worthy direction to go
in ... a
Are we ignoring the ZEND_IS_SMALLER issue?
if ($gmp 123) { ... }
There's no ZEND_IS_GREATER opcode, so it gets quietly turned into:
if (123 $gmp) { ... }
Which will be confusing.
I dealt with this in operator by having the user apply a patch before
building:
Why would this be confusing? I'd agree if this happened in userland
(people
could wonder why the operators are swapped), but internally we are
already
dealing with this anyway. E.g. when you implement compare_objects you
have
to be aware of this (to understand stuff like the return 1
It's time to play Spot the double quoting!
#define ZEND_NS_FENTRY(ns, zend_name, name, arg_info, flags)
ZEND_RAW_FENTRY(ZEND_NS_NAME(ns, #zend_name), name, arg_info, flags)
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) ZEND_NS_FENTRY(ns,
#zend_name, name, arg_info, 0)
I know this conversation kinda stopped a couple weeks ago, but I want to
throw into the ring that HHVM already has a syntax for return type hinting
and it'd be awesome if we (with my PHP hat on) brought the two
implementations together rather than take them further apart.
In HHVM's case a
While playing with GO I did found that this type of syntax is a bit better.
Yeah, we played with a few formats (including the one originally proposed
and found some issues (like specifying closures as return types: function
function($foo, $bar) ($foo) { return makeCallback($foo); } Even if
With regard to any sort of hinting, an issue of 'one of' return types
would need to be addressed (I hope).
function foo(SomeClass $bar, int $baz) : bool, SomeClass {}
Allowing for a failure (False) or a success (SomeClass).
We (HHVM) deal with failure alternates by way of a nullable
While HHVM is a very interesting project, their use case is pretty
specific and narrow, and, as I understand, connected to a single
application (albeit running huge traffic numbers). So I'm not sure
copying whatever they do is necessarily good for PHP as a whole. HHVM
case is basically static
1 - 100 of 1464 matches
Mail list logo
