On 01/03/15 23:05, Stanislav Malyshev wrote:
> Hi!
>
>> This email is to announce the formal opening of discussion for an RFC
>> to clean up the behaviour of the constructors shown by several
>> internal classes.
>>
>> https://wiki.php.net/rfc/internal_constructor_behaviour
>
> I'm not sure why t
Hello!
On 01.03.15 21:19, Yasuo Ohgaki wrote:
>>> The answer is no, it's just not worth it. Having a function called
>> str_pos which is an alias of strpos, but only on some versions, is more
>> confusing, not less.
>>
>> My sentiment too. Factor in that someone already using the proposed
>> himse
2015-02-24 17:17 GMT+01:00 Thomas Gielfeldt :
> Hi internals.
>
> I've made PR proposing a feature request: A new interface Sortable.
>
> https://github.com/php/php-src/pull/1116
>
> If possible, I would like to create and RFC describing this in more
> detail, and perhaps get a voting on.
>
> Than
Hi Yasuo,
It may be to late for 7.0.
Also Alexander liked to to add another proposal, but I saw only
pre-required one(s)
Anyway, it's not a big problem to vote now.
I may take care about implementation for https://wiki.php.net/rfc/dbc2 (but
only if it wins).
Thanks. Dmitry.
On Sun, Mar 1, 2015 a
Please, write additional RFC if you are ready to work on it and provide
implementation.
The class hierarchy is definitely not the main part of this one.
The idea was just to make difference between Exception, EngineException and
ParseException.
Thanks. Dmirty.
On Fri, Feb 27, 2015 at 5:47 PM,
Am 02.03.2015 00:52 schrieb "Daniel Lowrey" :
>
> I'd like to initiate discussion on a proposal to implement generator
> delegation via the following new syntax inside generator functions:
>
> yield *
>
> The Generator Delegation RFC is available here:
>
> https://wiki.php.net/rfc/generator-de
Hi Yasuo,
2015-03-02 1:43 GMT-03:00 Yasuo Ohgaki :
> Hi Marcio,
>
> On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada
> wrote:
>
> I like the idea.
>
> /** fn expects a variable-length argument lists */
> function fn($arg) {
> $arg = func_get_arg();
> $args = func_get_args();
> }
>
> fn(1);
Hi Marcio,
On Mon, Mar 2, 2015 at 8:02 AM, Marcio Almada wrote:
> I'm moving the "Strict Argument Count" RFC into discussion phase:
>
> RFC: https://wiki.php.net/rfc/strict_argcount
> PR: https://github.com/php/php-src/pull/1108
>
> Many different opinions were collected during research phase an
Hi!
> The difference is that fopen can fail even if passed parameters that
> are correct e.g. due to file permission problems. Because of that the
> failure is not exceptional and so needs to be checked. Having to do
Failure of the formatter on wrong format or data is of the same kind -
its not e
Hi!
> This proposal is about code modularization. Software engineering is
> a history of better modularization.
>
> - Structured programming
> - Object Oriented programming
> - AOP
> - DbC
>
> Exception is one of them.
I'm sorry, I have hard time understanding what exceptions have to do
wi
Hi Rowan,
On Mon, Mar 2, 2015 at 2:22 AM, Rowan Collins
wrote:
> On 1 March 2015 15:18:09 GMT, "S.A.N" wrote:
> >Maybe better implement for method calls on primitive types in PHP 7?
> >https://github.com/nikic/scalar_objects
>
> We'd have a whole bunch of tough decisions to make - does HTML esc
Hi all,
On Mon, Mar 2, 2015 at 9:55 AM, S.A.N wrote:
> 2015-03-02 2:17 GMT+02:00 Terry Cullen :
> > On 2 March 2015 at 01:18, S.A.N wrote:
> >
> >> Maybe better implement for method calls on primitive types in PHP 7?
> >> https://github.com/nikic/scalar_objects
> >>
> >>
> > I've searched throu
2015-03-02 2:17 GMT+02:00 Terry Cullen :
> On 2 March 2015 at 01:18, S.A.N wrote:
>
>> Maybe better implement for method calls on primitive types in PHP 7?
>> https://github.com/nikic/scalar_objects
>>
>>
> I've searched through the internals archive looking for debate on using
> scalar objects wi
On 2 March 2015 at 01:18, S.A.N wrote:
> Maybe better implement for method calls on primitive types in PHP 7?
> https://github.com/nikic/scalar_objects
>
>
I've searched through the internals archive looking for debate on using
scalar objects without much luck. I'd love to see some discussion a
2015-03-02 0:52 GMT+01:00 Daniel Lowrey :
> Hi folks,
>
> I'd like to initiate discussion on a proposal to implement generator
> delegation via the following new syntax inside generator functions:
>
> yield *
>
> The Generator Delegation RFC is available here:
>
> https://wiki.php.net/rfc/gen
Hi folks,
I'd like to initiate discussion on a proposal to implement generator
delegation via the following new syntax inside generator functions:
yield *
The Generator Delegation RFC is available here:
https://wiki.php.net/rfc/generator-delegation
This proposal is conceptually related to
On 1 March 2015 at 22:05, Stanislav Malyshev wrote:
> I'm not sure why this RFC assumes the exception is much better than
> returning null.
>
> It is a long standing tradition in PHP that operations that can be
> expected to fail - like fopen().. do not produce
> fatal errors but instead return
+1000 on this; so much better than the BaseException stuff!
> On 27.02.2015, at 15:31, Sebastian Bergmann wrote:
>
> Am 23.02.2015 um 19:15 schrieb Nikita Popov:
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has
Hi, internals
I'm moving the "Strict Argument Count" RFC into discussion phase:
RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108
Many different opinions were collected during research phase and the RFC
was updated with real BC break measurements and othe
Hi Stas,
On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev
wrote:
> > This email is to announce the formal opening of discussion for an RFC
> > to clean up the behaviour of the constructors shown by several
> > internal classes.
> >
> > https://wiki.php.net/rfc/internal_constructor_behaviour
>
Hi Joe and Rowan,
On Mon, Mar 2, 2015 at 7:14 AM, Yasuo Ohgaki wrote:
> Hi Joe and Rowan,
>
> On Mon, Mar 2, 2015 at 6:37 AM, Rowan Collins
> wrote:
>
>> On 01/03/2015 20:34, Lester Caine wrote:
>>
>>> On 28/02/15 06:48, Joe Watkins wrote:
>>>
This is just a quick note to announce my
Hi Joe and Rowan,
On Mon, Mar 2, 2015 at 6:37 AM, Rowan Collins
wrote:
> On 01/03/2015 20:34, Lester Caine wrote:
>
>> On 28/02/15 06:48, Joe Watkins wrote:
>>
>>> This is just a quick note to announce my intention to ready this RFC
>>> for voting next week.
>>>
>> Since there is nothing in
Hi!
> This email is to announce the formal opening of discussion for an RFC
> to clean up the behaviour of the constructors shown by several
> internal classes.
>
> https://wiki.php.net/rfc/internal_constructor_behaviour
I'm not sure why this RFC assumes the exception is much better than
returni
Hi Rowan,
On Mon, Mar 2, 2015 at 6:32 AM, Rowan Collins
wrote:
> On 01/03/2015 21:26, Yasuo Ohgaki wrote:
>
>> Although it seems current code does not have code like GMP. I'm sure
>> we'll have this before release. i.e.
>>
>> $new = $some_ustring . 'abc'; // $new is UString object
>>
>> To imple
On 01/03/2015 20:34, Lester Caine wrote:
On 28/02/15 06:48, Joe Watkins wrote:
This is just a quick note to announce my intention to ready this RFC
for voting next week.
Since there is nothing in this which needs any changes to the core then
surly it simply needs to exist in pecl until suc
On 01/03/2015 21:26, Yasuo Ohgaki wrote:
Although it seems current code does not have code like GMP. I'm sure
we'll have this before release. i.e.
$new = $some_ustring . 'abc'; // $new is UString object
To implement feature like this, it cannot be PECL.
Why not? I would have thought any exten
On 01/03/2015 20:59, Yasuo Ohgaki wrote:
However, I don't mind too much allowing any encoding stored in "Text"/
"UString" object. IIRC, Ruby does this and have not much problem.
As I understand it, Ruby's string type is actually a whole bunch of
overloaded types, each responsible for re-implem
Hi Lester,
On Mon, Mar 2, 2015 at 5:34 AM, Lester Caine wrote:
> On 28/02/15 06:48, Joe Watkins wrote:
> > This is just a quick note to announce my intention to ready this RFC
> > for voting next week.
>
> Since there is nothing in this which needs any changes to the core then
> surly it sim
Hi Florian,
On Mon, Mar 2, 2015 at 5:57 AM, Florian Margaine
wrote:
> Le 1 mars 2015 21:26, "Derick Rethans" a écrit :
> >
> > Hey Joe,
> >
> > I think there are a few issues with the proposal, although I like the
> > general idea. I've had the tab with the RFC open since October... but
> > nev
Hi Joe and Derick,
On Mon, Mar 2, 2015 at 5:25 AM, Derick Rethans wrote:
> I think there are a few issues with the proposal, although I like the
> general idea. I've had the tab with the RFC open since October... but
> never looked at it until now :-/. So, a few comments:
>
> - UString as a name
Hi,
Le 1 mars 2015 21:26, "Derick Rethans" a écrit :
>
> Hey Joe,
>
> I think there are a few issues with the proposal, although I like the
> general idea. I've had the tab with the RFC open since October... but
> never looked at it until now :-/. So, a few comments:
>
> - UString as a name.
>
>
On Sat, 28 Feb 2015, Rowan Collins wrote:
> On 28/02/2015 06:48, Joe Watkins wrote:
> > Morning internals,
> >
> > This is just a quick note to announce my intention to ready this RFC
> > for voting next week.
> >
> > I know I'm a little late maybe, I was real sick most of last week, s
On 28/02/15 06:48, Joe Watkins wrote:
> This is just a quick note to announce my intention to ready this RFC
> for voting next week.
Since there is nothing in this which needs any changes to the core then
surly it simply needs to exist in pecl until such time as a proper
replacement for unicod
On Sun, 1 Mar 2015, Yasuo Ohgaki wrote:
> Hi Joe,
>
> On Sun, Mar 1, 2015 at 7:14 PM, Yasuo Ohgaki wrote:
>
> >public function __construct([string $string [, string $source_codepage
> > [, string $substitute_char] ]);
>
> One additional comment for constructor. It should have default
> no
Hey Joe,
I think there are a few issues with the proposal, although I like the
general idea. I've had the tab with the RFC open since October... but
never looked at it until now :-/. So, a few comments:
- UString as a name.
I think I am going to prefer "Text" as a class name. Unicode (and
int
Hi Markus and Fischer,
On Sun, Mar 1, 2015 at 11:23 PM, Markus Fischer wrote:
> On 01.03.15 13:53, Rowan Collins wrote:
> > On 1 March 2015 11:29:49 GMT, Yasuo Ohgaki wrote:
> >
> >> How about rename all of these functions according to CODING_STANDARD
> >> for
> >> PHP7
> >> and have aliases fo
Am 01.03.2015 um 20:04 schrieb Dan Ackroyd:
On 1 March 2015 at 18:35, Marc Bennewitz wrote:
What are the reasons to not make this class instantiable / extendable ?
That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for
On 1 March 2015 at 18:35, Marc Bennewitz wrote:
> What are the reasons to not make this class instantiable / extendable ?
That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for it to not
be extendible or instantiable. Obviou
On Sun, Mar 01, 2015 at 05:22:05PM +, Rowan Collins wrote:
> On 1 March 2015 15:18:09 GMT, "S.A.N" wrote:
> >Maybe better implement for method calls on primitive types in PHP 7?
> >https://github.com/nikic/scalar_objects
>
> We'd have a whole bunch of tough decisions to make - does HTML escap
Hi Dan,
Am 01.03.2015 um 15:55 schrieb Dan Ackroyd:
Hi Internals,
This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.
https://wiki.php.net/rfc/internal_constructor_behaviour
I really like this R
On 1 March 2015 15:18:09 GMT, "S.A.N" wrote:
>Maybe better implement for method calls on primitive types in PHP 7?
>https://github.com/nikic/scalar_objects
We'd have a whole bunch of tough decisions to make - does HTML escaping really
belong as a method of the string type? What are printf and sc
On 1 Mar 2015 15:56, "Dan Ackroyd" wrote:
>
> Hi Internals,
>
> This email is to announce the formal opening of discussion for an RFC
> to clean up the behaviour of the constructors shown by several
> internal classes.
>
> https://wiki.php.net/rfc/internal_constructor_behaviour
>
> For reference t
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objects
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Internals,
This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.
https://wiki.php.net/rfc/internal_constructor_behaviour
For reference this was discussed before
https://marc.info/?l=php-internals&
On 01.03.15 13:53, Rowan Collins wrote:
> On 1 March 2015 11:29:49 GMT, Yasuo Ohgaki wrote:
>
>> How about rename all of these functions according to CODING_STANDARD
>> for
>> PHP7
>> and have aliases for old names?
>
> If this list had an FAQ (which I think it should), this would be on it.
>
Hey Zeev,
> Another change being considered and not yet in the RFC is re-allowing
> leading and trailing spaces for numeric strings (sorry Paddy.)
I think that rejecting leading and trailing spaces for stringy ints is for the
best.
If I only want to accept an integer (in either int or string for
On 1 March 2015 11:29:49 GMT, Yasuo Ohgaki wrote:
>How about rename all of these functions according to CODING_STANDARD
>for
>PHP7
>and have aliases for old names?
If this list had an FAQ (which I think it should), this would be on it.
The answer is no, it's just not worth it. Having a functio
Hi,
I like this idea. But I'm afraid of BC. There will be some scripts who
won't work after that, because they already use functions with these names.
But since we already have some BC for PHP 7, I think it's about the right
time to do this.
But we have to keep the old names for at least
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27
How about rename all of these functions according to CODING_STANDARD
Hi Joe,
On Sun, Mar 1, 2015 at 7:14 PM, Yasuo Ohgaki wrote:
>public function __construct([string $string [, string $source_codepage
> [, string $substitute_char] ]);
One additional comment for constructor. It should have default
normalization. I think
it should be NFC as most system uses i
Hi Joe,
On Sun, Mar 1, 2015 at 6:14 PM, Yasuo Ohgaki wrote:
> On Sat, Feb 28, 2015 at 3:48 PM, Joe Watkins
> wrote:
>
>> This is just a quick note to announce my intention to ready this RFC
>> for voting next week.
>>
>> I know I'm a little late maybe, I was real sick most of last week,
On 01/03/15 00:37, Yasuo Ohgaki wrote:
>> Yes, the global vs local setting issue is distinct from the question of
>> > "is phar://blah a URL?"
>
> I think your question is about remote/local resource.
> Is phar:// local resource? It's yes.
> Is phar:// URL/URI? I think it depends how people unders
Hi Joe,
On Sat, Feb 28, 2015 at 3:48 PM, Joe Watkins wrote:
> This is just a quick note to announce my intention to ready this RFC
> for voting next week.
>
> I know I'm a little late maybe, I was real sick most of last week, so
> couldn't do anything useful.
>
> A couple of us inten
Hi Dmitry,
On Fri, Feb 27, 2015 at 9:10 PM, Dmitry Stogov wrote:
> With the recent discussions of JIT/AOT and the good progress we made on
> PHP-7, we decided to open up the JIT experiment we've been working on.
>
> https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
>
> You may ju
54 matches
Mail list logo
