Why not leave it as it is? I mean, really, those five strokes?
Wherever it's going, I'm -1 on changing the meaning of the existing macro.
On 11 Feb 2015 16:01, reeze re...@php.net wrote:
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I don't think it'll
Hi Pavel,
On 11 Feb 2015, at 07:41, Pavel Kouřil pajou...@gmail.com wrote:
Also, I realized one thing why I think the strict version is a bad
idea for PHP (in the state PHP is now - in an ideal world I would love
to have nothing but strongly typed PHP, but that's offtopic) - PHP has
many
Hi,
another one of my weird ideas: what about a script signing mode?
- ini setting containing a HMAC key
- first ?php tag in a file must then have a signature, a la
?php:Base64encodedstring
- no parsing of files that fail the signature check
- (maybe optional) disabling of eval
Of course such
Hi!
That one actually looks better to me, but: I'm not sure how annotation
syntax is supposed to support expressions or closures,
keep AST.
So we'd have a zval type that is the raw AST? Would it also be available
to user functions or internal functions/classes? It's an intriguing
Hi all,
On Tue, Feb 10, 2015 at 9:52 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you like or dislike.
Hi Stas,
On Wed, Feb 11, 2015 at 4:32 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you
Hi!
I'm not trying to be perfect, but I would like to make PHP as secure as
other
languages from script inclusion attacks. It's too easy currently...
PHP is already as secure as the other languages. If you have code in
Python that loads arbitrary file and executes it, you could upload
Python
Hi all,
On Wed, Feb 11, 2015 at 8:15 PM, Dmitry Stogov dmi...@zend.com wrote:
I don't think it'll improve something, and may complicate merging from
PHP5 (this is not a big issue, because merging is already not simple).
In any case, the names should be swapped, to be used as:
Hi Rasmus,
On 11 Feb 2015, at 06:36, Rasmus Lerdorf ras...@lerdorf.com wrote:
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
Both D and Eiffel evaluates all contracts defined in parents/interfaces.
That's not what I understand about pre-condition inheritance in D (check
On 02/11/2015 10:52 AM, Lior Kaplan wrote:
Hi,
I've been doing some editing to the NEWS files, and keep getting this
problem
$ git diff NEWS
fatal: ambiguous argument 'NEWS': both revision and filename
Use '--' to separate filenames from revisions
Although I can do as it suggests, I
Hi Lester,
All of the current demands ... and I think they are demands! ... stamp
on past history and load even more work on everybody to have to support
all these new features. Even if dbc is wrapped in comment blocks to hide
it it's potential presence in third party parts of a project means
On 11/02/15 14:14, François Laupretre wrote:
All of the current demands ... and I think they are demands! ... stamp
on past history and load even more work on everybody to have to support
all these new features. Even if dbc is wrapped in comment blocks to hide
it it's potential presence in
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I don't think it'll improve something, and may complicate merging from
PHP5 (this is not a big issue, because merging is already not simple).
Yes it just makes code looks a little better and cleaner.
I didn't
Hi internals!
Since no new discussion topics appeared, the voting on the Group Use
Declarations RFC for PHP7 is now open:
RFC: https://wiki.php.net/rfc/group_use_declarations#votes
Patch: https://github.com/php/php-src/pull/1005
As requested I've split the vote into two slightly different
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Wednesday, February 11, 2015 8:37 AM
To: Xinchen Hui; Andrea Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am
Le 05/02/2015 09:49, Dmitry Stogov a écrit :
The RFC is turned into voting
https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices
Hi,
After discussing this RFC with other people at AFUP, it seems we are the
+1 side, on both propositions.
Thanks
--
Pascal MARTIN, AFUP - French UG
On 11 February 2015 06:36:52 GMT, Rasmus Lerdorf ras...@lerdorf.com wrote:
And in Drupal8 *without turning on strict*:
use Drupal\Component\Utility\String;
it dies with: Fatal error: string cannot be used as a class name in
/var/www/drupal/core/includes/bootstrap.inc on line 11
That
Renamed to NEWS-cvs2svn
Kaplan
On Feb 11, 2015 5:11 PM, Andrea Faulds a...@ajf.me wrote:
Hi,
On 11 Feb 2015, at 09:52, Lior Kaplan lio...@zend.com wrote:
Hi,
I've been doing some editing to the NEWS files, and keep getting this
problem
$ git diff NEWS
fatal: ambiguous
On 11 Feb 2015, at 21:30, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Wednesday, February 11, 2015 8:37 AM
To: Xinchen Hui; Andrea Faulds
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On
I said numerous times that I think that v0.1 of Andrea’s RFC was right on
the mark. I’d vote in its favor in a heartbeat. It gives the exact same
value from an API author’s point of view. It gives the exact same value in
terms of potential performance improvements/JITting/compilation insight.
On 11/02/15 21:46, Andrea Faulds wrote:
Anthony Ferrara also had his own analysis which showed some of the problems
with weak type hinting, and where strict types can be beneficial:
http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html
What is the point of using a 'Better static
On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner m...@php.net wrote:
On 06/02/15 17:44, Daniel Lowrey wrote:
If you doubt that this is a solved problem in userland consider the
performance of my own 100% userland HTTP client demonstrated here
without the use of curl or any other
Forarding again, was rejected by the list because of spammy links :(
-- Forwarded message --
From: Benjamin Eberlei kont...@beberlei.de
Date: Thu, Feb 12, 2015 at 12:59 AM
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
To: Andrea Faulds a...@ajf.me
Cc: Zeev Suraski z...@zend.com,
On 11 February 2015 22:41:21 GMT, Lester Caine les...@lsces.co.uk wrote:
On 11/02/15 21:46, Andrea Faulds wrote:
Anthony Ferrara also had his own analysis which showed some of the
problems with weak type hinting, and where strict types can be
beneficial:
Hey Guilherme,
On 11 Feb 2015, at 22:46, guilhermebla...@gmail.com wrote:
@Andrea: I spent around 2-3 hours speaking with Anthony and the other half
talking to Jordi (Composer, Symfony).
I still think a few things are required to be fully usable.
1- Exceptions RFC (outside of your scope,
On 06/02/15 17:44, Daniel Lowrey wrote:
If you doubt that this is a solved problem in userland consider the
performance of my own 100% userland HTTP client demonstrated here
without the use of curl or any other extensions:
https://gist.github.com/rdlowrey/54171625334670ccb9f5
I can
Hi Marcio,
On 11 February 2015 at 20:50, Marcio Almada marcio.w...@gmail.com wrote:
Hi internals!
Since no new discussion topics appeared, the voting on the Group Use
Declarations RFC for PHP7 is now open:
RFC: https://wiki.php.net/rfc/group_use_declarations#votes
Patch:
Hi,
2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com:
It gives the exact same
value from an API author’s point of view.
But not from an api-consumers point of view. Without either
introducing a new set of casting/conversion rules or changing existing
behavior (**exclusively**) 'weak'
Hi Peter,
I like the idea (reducing the repeated namespace parts), but am not too
keen on the syntax.
If I may offer a hastily thought out, and probably terrible, idea... how
about something like from prefix use ... ? [...]
That's my two cents.
Some people suggested the *from* ... *use *...
On Thu, Feb 12, 2015 at 10:05 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui larue...@php.net wrote:
The fails must be know... relates to key name checking
the leaks
Hi Yasuo,
Yasuo Ohgaki wrote:
Hi Christoph,
On Wed, Feb 11, 2015 at 10:45 AM, Christoph Becker cmbecke...@gmx.de
wrote:
We have been tried to educate users already and introduced some
mitigations e.g. allow_url_include, open_basedir.
However, enough time is passed to prove that wasn't
Hi all,
On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui larue...@php.net wrote:
The fails must be know... relates to key name checking
the leaks needs to be take care, I will look into it.
anyway, these should not
Hi Stas,
On Thu, Feb 12, 2015 at 3:21 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
I'm not trying to be perfect, but I would like to make PHP as secure as
other
languages from script inclusion attacks. It's too easy currently...
PHP is already as secure as the other languages. If
Hi,
On 12 February 2015 at 15:30, Dmitry Stogov dmi...@zend.com wrote:
We don't use macros with variable number of arguments in PHP.
this is not portable.
We could don't have to use variadic macros, we could try something like:
*+PHPAPI void php_error_doc0(int type, const char *format,
Hey:
On Thu, Feb 12, 2015 at 1:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Xinchen,
On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui larue...@php.net wrote:
lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
I
Hi,
On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
That one actually looks better to me, but: I'm not sure how
annotation
syntax is supposed to support expressions or closures,
keep AST.
So we'd have a zval type that is the raw AST?
On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds a...@ajf.me wrote:
A number (or numeric, or num, or some other name) type hint is something I
plan to propose in a future, follow-up RFC.
Hello,
wouldn't polymorphism (via method overloading) solve the use cases and
be much more useful in the
On Tue, 10 Feb 2015, Yasuo Ohgaki wrote:
Hi all,
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you like or dislike.
Con:
- It introduces an
On Wed, 11 Feb 2015, Yasuo Ohgaki wrote:
Hi Markus,
On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer mar...@fischer.name wrote:
What constitutes first token in this context?
Would this be detected as a PHP file?
-8
root:x:0:0:root:/root:/bin/bash
Hi,
I've been doing some editing to the NEWS files, and keep getting this
problem
$ git diff NEWS
fatal: ambiguous argument 'NEWS': both revision and filename
Use '--' to separate filenames from revisions
Although I can do as it suggests, I would prefer to remove the NEWS tag we
have since 2008
On 11/02/15 09:34, Derick Rethans wrote:
Some of you are tired with this topic, but please take a look the RFC
[RFC] Script only includes - this is 3rd version.
https://wiki.php.net/rfc/script_only_include
Please let me know what you like or dislike.
Con:
- It introduces an INI
On 09/02/2015 22:29, Anatol Belski wrote:
ext/imap
ext/mcrypt
ext/pdo_dblib
Sorry if this was suggested already but if those are not maintained much
and should not be used further ideally, shouldn't we add E_DEPRECATED to
them at least?
I understand that they are kept to avoid making the
Hi Joe,
On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins pthre...@pthreads.org wrote:
So it turns out that invariant is already deprecated in D, they have
dropped it in favour of immutable properties.
I guess I'll have to install an old version, or try to extract everything
we need from their
Hi all,
There are a lot of code use php_error_docref() macro, the first
parameter
mostly is NULL, before PHP7, it looks like:
*php_error_docref(NULL TSRML, E_WARNING, recursion detected);*
in PHP7
*php_error_docref(NULL, E_WARNING, recursion detected);*
looks better, but the first
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and __invariant,
or some combination of three.
Any objection to using __ prefixed names, and any
PS:
Github search result:
https://github.com/search?l=cq=php_error_docrefref=searchresultstype=Codeutf8=%E2%9C%93
It seems that no one need the docref at all.
On 11 February 2015 at 16:07, reeze re...@php.net wrote:
Hi all,
There are a lot of code use php_error_docref() macro, the
On Wed, Feb 11, 2015 at 4:07 PM, reeze re...@php.net wrote:
Hi all,
There are a lot of code use php_error_docref() macro, the first
parameter
mostly is NULL, before PHP7, it looks like:
php_error_docref(NULL TSRML, E_WARNING, recursion detected);
in PHP7
php_error_docref(NULL,
I think it is a cleanup, it works but there are too many duplication. it is
the time to make the code clean and easier to understand.
I myself don't know why should I need the first NULL when I am a newcomer
of writing extensions, it just seems everyone do that,
before PHP7 there is a strange
Hi all,
On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote:
I think it is a cleanup, it works but there are too many duplication. it
is the time to make the code clean and easier to understand.
I've never used other than NULL also.
Everyone is going to remove TSRM macros, it's right
OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name
Not that I am aware of, the AST stuff didn't touch the parser like that, it
has the same limitations it had before AFAIK.
Cheers
Joe
On Wed,
http://dlang.org/deprecate.html#invariant as an alias for immutable
It's not an alias, the most recent compiler emits an error if you try to
use invariant contracts, and immutable isn't a kind of contract.
immutable is a property modifier:
immutable: http://dpaste.dzfl.pl/7e724b599640
Stanislav Malyshev wrote in message news:54dafd32.3000...@gmail.com...
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than assert, I'm sure the
thesaurus has a lot of possibilities.
On 11/02/15 07:58, Stanislav Malyshev wrote:
We've spent several years rejecting annotations because no information
can be in comments, not even a little bit, not even a tiny.
I find that a strange comment, since I've been using annotation in PHP
from day one. The phpdoc material helped me get
Hi!
function foo($a)
require($a = 0)
{
}
This is a step better but still we have the similar issues with
readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing improvements
Hi Joe,
On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins pthre...@pthreads.org
wrote:
So it turns out that invariant is already deprecated in D, they have
dropped it in favour of immutable properties.
I guess I'll have to
On 11 Feb 2015 09:38, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/10/2015 07:57 PM, Xinchen Hui wrote:
am I wrong?!
seems I am wrong with this, it's a false alarm... it can restore
automatically.
Yeah, declare() doesn't span files so that isn't a problem.
My worry is still the lack
Hi Joe,
On Wed, Feb 11, 2015 at 5:12 PM, Joe Watkins pthre...@pthreads.org wrote:
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and
Hey:
On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
On Wed, Feb 11, 2015 at 5:21 PM, reeze re...@php.net wrote:
I think it is a cleanup, it works but there are too many duplication. it
is the time to make the code clean and easier to understand.
I've
Jordi Boggiano wrote on 11/02/2015 10:40:
On 09/02/2015 22:29, Anatol Belski wrote:
ext/imap
ext/mcrypt
ext/pdo_dblib
Sorry if this was suggested already but if those are not maintained
much and should not be used further ideally, shouldn't we add
E_DEPRECATED to them at least?
I
Hi Anatol,
On Tue, Feb 10, 2015 at 3:35 PM, Anatol Belski anatol@belski.net
wrote:
Maybe it'd be worth it to move one step after another, see what features
can be implemented and how do they improve? Maybe they'll be so crucial to
even make a special case that one can say - yeah, don't
I don't think there is time to get something finalised for 7.0, I
certainly wouldn't want anything cryptography related to be rushed, so
this is a pre-RFC discussion to gather ideas and opinions for
something we can work towards in PHP 7.1 and that can live as a PECL
extension between now and
Hi,
I don't think it'll improve something, and may complicate merging from PHP5
(this is not a big issue, because merging is already not simple).
In any case, the names should be swapped, to be used as:
php_error_docref(E_WARNING, recursion detected);
or
php_error_docref_ex(NULL,
Hi,
On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano j.boggi...@seld.be wrote:
On 09/02/2015 22:29, Anatol Belski wrote:
ext/imap
ext/mcrypt
ext/pdo_dblib
Sorry if this was suggested already but if those are not maintained much and
should not be used further ideally, shouldn't we add
On Wed, Feb 11, 2015 at 10:58 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
/**
* @requires ($a = 0)
*/
function foo($a) {
}
We've spent several years rejecting annotations because no information
can be in
On 10/02/15 14:31, Lester Caine wrote:
in interbase/ibase_blobs.c
zval *blob_arg, *string_arg;
ibase_blob *ib_blob;
RESET_ERRMSG;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, blob_arg,
string_arg) == FAILURE) {
WRONG_PARAM_COUNT;
}
2015-02-11 13:25 GMT+02:00 Dmitry Stogov dmi...@zend.com:
yes. some special attributes. requires/ensures/invariant
Oh, and syntax is *ugly* ;)
It's from HHVM. I don't like it as well, please, propose the better one.
I like syntax, like a switch:
function add(int $a, int $b) : int
De : Dmitry Stogov [mailto:dmi...@zend.com]
I think we should just repeat the related D semantic.
It must be defined in contracts inheritance rules.
What if we have contracts for prototype method in parent class and
interface?
Should we still validate contracts of parent and interface if
-Original Message-
From: Sebastian B.-Hagensen [mailto:sbj.ml.r...@gmail.com]
Sent: Thursday, February 12, 2015 2:11 AM
To: Zeev Suraski
Cc: guilhermebla...@gmail.com; Rasmus Lerdorf; PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
Hi,
2015-02-12 0:08 GMT+01:00 Zeev
Hi Xinchen,
On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui larue...@php.net wrote:
lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
I feel...that might be something wrong :
I do think so. It's Core i7 with 32GB
We don't use macros with variable number of arguments in PHP.
this is not portable.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 6:01 PM, reeze re...@php.net wrote:
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I don't think it'll improve something, and may
71 matches
Mail list logo
