On Wed, Feb 27, 2013 at 3:06 AM, Zeev Suraski 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
little-to-no discuss
On Tue, Feb 19, 2013 at 4:06 AM, Sara Golemon 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.
htt
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
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 pla
> 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
>
>> 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
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:
https://github.com/php/pecl-php
>
> > 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
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)
ZEND_NS_NAMED
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 function
> 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 y
> 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 "nullabl
> 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 st
> Should I conclude that there's enough interest for this feature and
> move from a gist to a RFC? If so, I would definitely need someone to
> help out with the implementation.
>
> Without wanting to put the cart too far before the horse, I'll mention
that FB is willing to offer resources (me, basi
If you run into issues (yes, our build system still sucks a bit) poke me in
IRC freenode/#hhvm (or ptarjan or any other @ in that channel).
And just to jump in front of what I detect in your comment "albiet compile
it". Repeat: HHVM is not a code translator anymore. Hasn't been for
awhile now.
>
> > 1) HHVM isn't just running FB. A number of sites have either already
> started using HHVM, or intend to soon.
>
> Were could I read about those?
>
> I didn't list any because I don't know how they individually feel about
sharing that info. I realize that takes the wind out of my statement,
were changed
based on the feedback received from this group.
I'm on PHP's side, guys.
On Thu, Jul 11, 2013 at 1:47 PM, Nikita Popov wrote:
> On Thu, Jul 11, 2013 at 10:27 PM, Sara Golemon wrote:
>
>> I won't suggest that PHP should follow HHVM, if anything I&#x
> @Sara: thank you for the offer, I'll send you a mail, if it's ok with
> you, in the next days, I'd want to make this as a tutorial and maybe
> me implement it with your guidance, but more on this another time.
>
> Sure thing. PHP needs more developers with deep understanding of the
engine. I'd
> My question is, why specifically doesn't it?
>
> Because Perl.
If run right now, it will always produce the same value (4), but it isn't
*defined* to do so. What that means is that behavior is subject to change
without notice, warning, or justification. This is a somewhat harsh way of
saying "Don't write expressions with ambiguous evaluations, that's clowny."
On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki wrote:
>
>
> If there aren't comments, I'll rewrite the example.
>
>
> There were comments. I explicitly told you that that the behavior is
defined as undefined. You CHOSE to ignore that comment. You CHOSE to
break the documentation.
I think the idea comes from a good place, but the actual, practical
usefulness of it is so low that the availability of workaround negates even
the very small amount of effort it would take to create (and maintain!)
shadow functions for the language constructs.
array_filter($arr, function($val) {
Lack of parenthesis and the fact that EVERY project out there takes
advantage of this affordance. So BC *nightmare*.
On Fri, Jul 19, 2013 at 9:16 PM, Ryan McCue wrote:
> Johannes Schlüter wrote:
> > So, unfortunately no, language constructs have different semantics which
> > we can't emulate in
Well, now... to be fair... You could make them functions and use the same
parser trick the backtick operator uses. to map the non-parenthesized
versions feels messy though. I'd just hate to get stuck with a hacky
workaround like that for the long term.
On Fri, Jul 19, 2013 at 9:23 PM,
if, technically, either order of evaluation will result in the same
answer for this contrived expression. ++$a * $a++ is a more obviously
ambiguous answer for a language which explicitly does not define an order
of resolution.
On Fri, Jul 19, 2013 at 9:28 PM, Yasuo Ohgaki wrote:
> Hi
verage PHP
user, leading to weird unreproducible bug reports).
-Sara
On Fri, Jul 19, 2013 at 9:28 PM, Ryan McCue wrote:
> Sara Golemon wrote:
> > Well, now... to be fair... You could make them functions and use the same
> > parser trick the backtick operator uses. to map the non-parent
sus building over unilateral cowboy commits.
-Sara
On Fri, Jul 19, 2013 at 10:08 PM, Sherif Ramadan wrote:
>
> Sara,
>
> On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon wrote:
>
>> What's undefined isn't the relationship between preinc/postinc and add.
>> W
At a glance, this looks awesome. There are a few changes where you
introduced #ifdef WIN32 checks that I want to spend a little more time
looking at...
-Sara
P.S. - Could I convince you to put it on a github fork to make it easier to
read? No big deal if not... I just like that web view. :)
O
Ah, yeah, I can see that clearly now. Looks universally cool to me. Do
you just need someone with engine karma to push it?
On Wed, Jul 31, 2013 at 1:35 AM, Andrey Hristov wrote:
> Hi Sara,
>
> On 07/31/2013 12:55 AM, Sara Golemon wrote:
>
>> At a glance, this looks awesome
I have mixed emotions on the yes/no side of things, but on the "how" side,
I think we can do this fairly easily.
During parse, when a non-scalar const expression is encountered, the actual
binding to the class is deferred, and bytecodes are emitted in the "(main)"
function. To put it in psuedo-co
if(true) return;
> class Foo {
> const halfpie = M_PI/2;
> }
>
> Oooh, excellent point. Wave a finger and tell the user not to do that?
I wasn't going to bring this up, but an intersectional idea I had a few
years ago Static Constructor. Just like an instance constructor, but
called on init
Apart from managing lifecycles, the SAPI is also resposible for things like
directing I/O between the host application, how does null-sapi handle this?
On Fri, Aug 16, 2013 at 9:36 AM, J David wrote:
> Hello,
>
> We recently successfully embedded PHP into our application using an
> approach bas
Right, gotcha. I think ideally someone should put in the grunt work to do
what you suggested: Build libphp5.so all the time, then link up php/
mod_php5.so/etc... against that as a shared system library (which in turn
other programs or SAPIs could link against).
I'm not sure if anyone has the time
Ah, I see. I wasn't taking "null" quite literally enough. :)
That sounds pretty awesome to me. Assuming the implementation looks good
you'd get my vote.
On Fri, Aug 16, 2013 at 11:03 AM, J David wrote:
> On Fri, Aug 16, 2013 at 12:40 PM, Sara Golemon wrote:
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes and files (also recommended in the
> PSR). But for func
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
> Nothing, really... Just countering your specific premise.
> > Those function calls would only kick in if the function/constant wasn't
> > already defined, which will be the excep
Big +1 from me, though as Stas pointed out, multiple unpacks in a single
call don't really work with PHP parameter typing, so I'd make that use an
error.
On Sat, Aug 31, 2013 at 10:57 AM, Adam Harvey wrote:
> On 30 August 2013 08:23, Nikita Popov wrote:
> > The syntax it introduces looks as fo
Seems reasonable to me, but Wez should probably weigh in on it. I vaguely
recall a conversation with him when he first implemented stream_socket_*()
and a reason why listen wasn't in the API.
-Sara
On Thu, Sep 5, 2013 at 10:30 AM, Daniel Lowrey wrote:
> The stream socket functions are incredi
Still funny, but that troll has been played before. I don't think anyone's
suggested the Euro yet though, maybe go for that next time.
On Fri, Sep 6, 2013 at 2:48 PM, yigal irani wrote:
> make all dollar sign usage optional except in double quoted strings and
> when calling calling functions b
>
>
> I'd like to go forward with voting on this. Are there any issues that still
> need to be resolved?
>
> Assuming the RFC as-is represents the current state, I'm +1 on all of it.
I'm not a fan of some of the proposed alterations which would translate
arrays (a la call_user_func_array()). To c
> Assuming the RFC as-is represents the current state, I'm +1 on all of it.
>>
>> I'm not a fan of some of the proposed alterations which would translate
>> arrays (a la call_user_func_array()). To clarify, the following output is
>> what I'd expect:
>> function f(...$args) {
>> echo count($args
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=268281&r2=269153
This breaks the existing module API bec
However nobody ever posted anything on internals about it. The
differences between the implementation and the RFC as well as the
questions raised by this addition show that it would be better to
discuss prior to commit.
But as it is in trunk, that's less a problem, that's why trunk exists:
a deve
However nobody ever posted anything on internals about it. The
differences between the implementation and the RFC as well as the
questions raised by this addition show that it would be better to
discuss prior to commit.
But as it is in trunk, that's less a problem, that's why trunk exists:
a deve
Stanislav Malyshev wrote:
Add JSON_Serializable interface
Objects implementing JSON_Serializable will have
their ->jsonSerialize() method called
Similar to serialize() and __sleep()
Why should we have special mechanism for JSON? I.e., now we have one for
serialize(), separate one for json, th
I was just looking through the implementation of openssl_encrypt() (and
openssl_decrypt()) today because I need to make some encrypted payloads,
but the prototype didn't have anywhere to place an initialization vector.
On opening ext/openssl/openssl.c, I noticed line 4620 which simply
hardcode
Fixing this is a simple matter, but I wanted to bounce approaches for BC (or
lack thereof) off everyone else since this version of openssl_encrypt() is
already "in the wild".
I think it's worth a BC break. Comments?
To break BC is a no go, even if your arguments are appealing (even in
a majo
Mathias Grimm wrote:
If php have annotations feature its be very simple.
Transient private $dtCreated;// or JsonIgnore or JsonTransient
[*snip*]
This seems to be an attempt to solve a subset of the problem solved by
JSONSerializable, but from a negation rather than a explicit
orientatio
The only BC break is the warning raised when using openssl_encrypt() without
an IV. Given the extremely bad practice using a NULL IV represents, I think
this is a reasonable course of action.
It changes the signature making the fifth argument a complete
different thing. I strongly disagree with
I didn't say that I didn't understand the purpose of it. I said that it
provides less functionality than what we already have implemented.
Mathias Grimm wrote:
_json function to override properties and jsonIgore properties
when call json_encode($obMyClass) the __json and __jsonIgore will be c
I know this issue has been seen before, but I hope to do something about it.
$json = '1234567890123456789';
$x = json_decode($json);
/* $x is now a float *aproximately*
* equal to the original value
*/
For database indexes, being off by one can be disasterous for
application flow, so I'd like
Ilia Alshanetsky wrote:
Could you not treat a very large integer as a double? We do that in a few
areas of the code already.
Treating it as a double is exactly what json_decode() *currently* does,
and it's the problem I'm trying to work around by leaving it in string form.
When a large intege
This test is failing because of the good old-well known floating point
drift issue.
4.9 + 0.1 > 5.0
The kludge attached below "solves" it, but... well... it's a kludge. It
basicly adds (or subtracts) the smallest measurable piece of a double
during the comparison step (so as to not alter the act
> I came across a subtle bug a developer introduced into our
> application. It took us a month to realize the bug was
> there because PHP didn't throw a notice.
>
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_execute.c?revision=1.755&view=markup
Down inside zend_fetch_dimension_address(), you'l
Attached is a patch and corresponding test file
I would like to submit for inclusion in PHP.
I would like this patch to be included in PHP 5.2.1,
as it is entirely new code (and thus shouldn't cause
regressions), but as RC2 was just released earlier
today, I understand if it must wait until PHP 5.
For reasons best left on IRC, it looks like I'll be working on runtime
JIT. To that end, I've come up with a few proposals of varying
complexity and feature-set completeness:
Option 1:
Dump support for compile-time JIT and replace it with a call at runtime
using the same semantics.
Advantag
> Sorry but I wasn't on IRC so I don't quite
> understand what you're trying to accomplish ;)
> Can you please explain? Once I understand what
> you're trying to accomplish I'll be more than
> happy to provide feedback to the
> options list.
>
Oh, sorry, I thought you were in the email thread whic
As I told you, there was already a consensus on this solution, check
my initial proposal (solution #2):
http://news.php.net/php.internals/26965
No, that's a consensus on compile-time versus runtime. What I offered
in my post was four variants of how runtime could be implemented.
In respons
Option 4:
Include fetchtype and subelement during runtime JIT callback allowing
JIT callback to only do work necessary to prepare for the read/write
call being performed.
e.g.
int php_example_jit_callback(int str_type, zstr str, int str_len,
int stage, zval *container, int fetch_type, zva
The solution I'm tempted to pursue for this is to back up yet another
step and make autoglobals be CVs by extending the zend_compiled_variable
struct to contain a flag indicating how the var should be fetched (the
determination for which happens during fetch_simple_var during the
compilation.
the attached patch introduces a new handler to the engine that is
supposed to help debugging overloaded objects. It allows to return a
temporary hash rather then the object properties. This way an extension
can show non properties in var_dump() and print_r(). It will be used
in extensions like S
allow_url_include has been bashed lately for being "not good enough",
and there is a kernel of truth to that, though where the ultimate blame
falls if of course a touchy subject.
So rather than continue the fight over who's shoulders the job of
security should fall on, how about the attached p
It is interesting and very clear patch.
Probably you idea can be extended to support regular globals too. I mean
$GLOBALS["name"].
>
GLOBALS is itself in the auto global registry, so these would
automatically get picked up too. Oh, no, you probably mean have that
entire expression boil down t
I assume this would also mean all userland stream wrappers become is_url=1?
Anyway, +1.
This patch, by itself, doesn't affect the is_urlness of userspace
wrappers. Whether or not we change their designation is up to a
separate concensus (I'm in favor of it for the record).
Funnily enough th
Could you also run Zend/bench.php to check that patch doesn't slowdown local
fetches.
I think the patch can be commited into HEAD (not into PHP_5_2), but I would
prefer collect all performance patches and commit them into PHP_5_3 and HEAD
together.
without with
simple
[EMAIL PROTECTED] wrote:
The optimizer already does most of those things, so I think things like
that are best left there rather then being done in the core.
How exactly does the (by "the" I presume you mean "your") optimizer
manage to turn $_POST['foo'] into a single CV based DIM fetch? The
One last thought on global CVs... How's this for fixing the loophole of:
ZEND_BEGIN_SILENCE
ZEND_FETCH_R $0 '_POST' (global)
ZEND_FETCH_DIM_R $1 $0 'foo'
ZEND_END_SILENCE
I know it seems like a pretty minor gain, but (A) using @$_GET['foo']
isn't an uncommon practice, and (B) pushing this all
+ /* Give temp var back if it was the most recently assigned only
*/
+ if (CG(active_op_array)->T == (parent->u.var - 1)) {
+ CG(active_op_array)->T--;
+ }
Ergh, ignore that section It doesn't belong there (obviously)...
I pas
I know that the 'TSRMLS' is an abbreviation of 'Thread Safe Resource Manager
Local Storage', but what means is 'CC' and 'DC' in the 'TSRMLS_CC' and
'TSRMLS_DC' ?
This has been asked multiple times before on this list, but once again:
_CC - call with comma
_C - call (without comma)
_DC - dec
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 th
>> 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
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
non-a
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 built
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 built
> 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 accomp
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.
Wi
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 a
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. On
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 s
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
char *getpass( const char * prompt );
But in man getpass it is marked as "This fun
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
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 s
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.
or
or
or whatever hash algo you're looking for. Th
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 = '
0
foo
';
$s
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 met
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 l
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 t
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 of the
[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 _develo
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
--
P
On Mon, Aug 31, 2015 at 12:29 PM, Bob Weinand wrote:
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
I just want to toss in my two cents as someone who's been using short
closures on a PHPish platform for some time already, because
predictions are one thing, experience in ano
On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins wrote:
> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two syntaxes can be used.
>
I'm down
On Sep 6, 2015, at 07:01, Bob Weinand wrote:
> Also, Hack is using a completely different parser, doesn't look like we could
> borrow anything there.
>
True, Hack's parser is ocaml based and unrecognizable to the majority of this
list. But HHVM's parser (which implements the runtime side of Ha
On Sep 6, 2015, at 18:19, Bob Weinand wrote:
> Oh, I thought that feature to be Hack-only. Looks like I'm wrong and hence
> looked at the wrong place. [I always heard Hack has short Closures, but never
> was told HHVM had them too...]
Semantics semantics semantics.
Short closures *are* only su
401 - 500 of 1512 matches
Mail list logo
