Re: [PHP-DEV] FPM: Three-Phase running idea for faster frameworks

[Markus Fischer]

On 09.04.21 20:22, André Hänsel wrote:

Have you tried Roadrunner? I think your design is quite similar (identical?) to 
what Roadrunner does, only that your
worker pool is managed by FPM instead of Roadrunner and that the worker exits 
after serving one request - which you
*can* do with Roadrunner, but it's not recommended.



Also, since OP mentioned Laravel, https://github.com/laravel/octane/ has 
been made public recently.


It was announced on the recent Laracon. There's no official release yet 
though development seems in super-full-force mode and it supports Swoole 
and RoadRunner.


I think they're aiming for the "killer app" (well, framework) here.

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Changes to Git commit workflow

[Markus Fischer]

Hi Bishop,

On 01.04.21 06:54, Bishop Bettini wrote:

I've documented why we need signing, and how to set it up:

https://wiki.php.net/vcs/commit-signing

Feedback welcomed!


I'm not even the target audience in terms of php-src access, but rarely 
have I seen such a good tutorial approach on this (though have not 
tested it).


Just wanted to mention this, really great. It mentions it's based on 
internal LifeOmic docs, so kudos to them too I guess :)


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Markus Fischer]

On 04.01.21 16:12, Markus Fischer wrote:

I can't say whether just `: string` is too much, but in general I like it.


Apologies, I meant to write "too magic" :}

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Markus Fischer]

Hi,

On 04.01.21 15:05, Rowan Tommins wrote:

On 04/01/2021 11:15, Markus Fischer wrote:

On 03.01.21 12:01, Mike Schinkel wrote:

So in my perfect world this:

enum BookingStatus {
  case PENDING;
  case CONFIRMED;
  case CANCELLED;
}

Would be equivalent to:

enum BookingStatus {
  case PENDING = "PENDING";
  case CONFIRMED = "CONFIRMED";
  case CANCELLED = "CANCELLED";
}


I'm with Mikes' suggesting here, see also my previous messages [1] [2].

I don't know how to back this up with numbers, but the way I see it 
the majority of use cases will have a benefit of being able to 
directly use the literal values derived from the lexical ones and the 
ability to have custom values is feature next to it.



I would personally be OK with this if it was allowed but opt-in, e.g. 
adding the ": string" would default the values in that way, or even 
something magic like ": auto".


I can't say whether just `: string` is too much, but in general I like it.

I can follow the reasoning having no value by default and opt this in. 
The opt-in you suggested is very low-overhead (albeit a bit subtle, but 
maybe someone has a smarter idea :)


Maybe not evident, I like the enum RFC but think the most value for many 
use cases will having automatically values.


thanks!
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Markus Fischer]

Hi,

On 03.01.21 12:01, Mike Schinkel wrote:

So in my perfect world this:

enum BookingStatus {
  case PENDING;
  case CONFIRMED;
  case CANCELLED;
}

Would be equivalent to:

enum BookingStatus {
  case PENDING = "PENDING";
  case CONFIRMED = "CONFIRMED";
  case CANCELLED = "CANCELLED";
}


I'm with Mikes' suggesting here, see also my previous messages [1] [2].

I don't know how to back this up with numbers, but the way I see it the 
majority of use cases will have a benefit of being able to directly use 
the literal values derived from the lexical ones and the ability to have 
custom values is feature next to it.


[1] https://externals.io/message/112626#112655
[2] https://externals.io/message/112626#112663

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Markus Fischer]

On 30.12.20 12:00, Rowan Tommins wrote:

On 30 December 2020 08:43:33 GMT+00:00, Markus Fischer  
wrote:

What is the scalar value for a ScalarEnum if none is explicitly
defined?


The question has no answer, because the declaration of the enum itself would be 
invalid:


If an enumeration is marked as having a scalar equivalent, then all cases must 
have a unique scalar equivalent defined explicitly.


enum Suit: string {
case Hearts;
case Diamonds;
}

Presumably, this would result in an Error being thrown when compiling the 
declaration.


I see.

What's the quickest way (=less code) to have an enum represent it's 
lexical name as the literal values?


So that `… case Foo; case Bar; …` results in `::Foo->value === 'Foo'` etc.?

Is this possible without implementing this manually for all cases?

thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Markus Fischer]

Hi,

On 28.12.20 21:21, Larry Garfield wrote:

The full RFC is here, and I recommend reading it again in full given how much 
was updated.

https://wiki.php.net/rfc/enumerations


I tried to answer the following question but failed to do so:

What is the scalar value for a ScalarEnum if none is explicitly defined?

The RFC makes this example:
> enum Suit: string implements Colorful {
>case Hearts = 'H';
>case Diamonds = 'D';
…
> 'D' == Suit::Diamonds->value; // true


What in this case?

> enum Suit: string {
>case Hearts;
>case Diamonds;
…

What is the outcome of `Suit::Diamonds->value` ?

Thanks!
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enumerations

[Markus Fischer]

Hi,

On 05.12.20 10:22, Pierre R. wrote:
I think that ::cases() should always return an array/iterable without 
keys, and let userland write their own code to create hashmaps with 
those when they need it. I think that having one case (non primitive 
cases) that doesn't yield string keys and the other (primitive cases) 
which holds string keys may create a confusion because behavior is 
different.


If behavior is different, this would mean you couldn't mix primitive and 
non primitive cases on the same enum, which, why not couldn't we do that?


I've no strong feelings and I think your idea makes sense.

But I would argue, of course without having hard facts, that the 
_majority_ will have the use-case for a 1:1, aka array with key => 
value, mapping.


Thus I would argue that having (considering your proposal being added) 
still such functionality would be useful for a very wide-audience 
without everyone having to reinvent a helper method to use the iterable.


thanks for considering,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Attributes and constructor property promotion

[Markus Fischer]

Hi!

On 06.10.20 17:15, Sara Golemon wrote:

My opinion on constructor property promotion (CPP) is that it's something
for small value object classes and should probably be regarded as
code-smell on larger classes. At the same time, annotations belong with
more complex objects and not so much with small "struct-like" classes.


Just wanted to chime in on this:

I can foresee already the impact CPP will have on dependency injection: 
sometimes you just have complex business logic with lots of (auto-wired) 
dependencies and have to pull in n+1 classes into the constructor.


Currently 5+ deps create 3*(5+) codelines for not much value. My point 
is that I see much more value _outside_ of "value object classes" with 
auto-wiring, reducing boilerplate _a lot_.



That said: I err on the side of forbidding it, if we've no clear 
consensus how to do it!


thanks,
- Makrs

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[Markus Fischer]

On 05.10.20 12:24, Andreas Leathley wrote:

On 05.10.20 12:08, Lynn wrote:

How should php deal with the scenario where you want to `use` everything
and have one variable by reference?

```
function () use (*, &$butNotThisOne) {};
```


The easiest would be to only allow "use (*)" with no references or
additional syntax. "use (*)" would only copy all local variables into
the closure, no references. Personally I have never used references with
"use", I think it is much more niche compared to the regular copying,
and there is still the explicit (current) syntax to do references.


FTR, short arrow function implicitly only support "by value" bindings, I 
just checked the docs.


I do use by ref with closures btw.

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Markus Fischer]

Hi,

On 03.09.20 09:58, Côme Chilliet wrote:


 foreach ($iterable as $key => $_) { ... }


I currently use foreach (array_keys($array) as $key) { ... }
  to avoid complains from code analysers on unused var, is it slower?


one argument brought forward initially (sorry, can't find the email 
right now) is the resource management: array_keys() has to create a copy 
[*] which might be an issue depending on the size of data.


- Markus

[*] I now about shallow-copy, I'm just trying to cite the initial 
argument as best as I can :)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Request for couple memory optimized array improvements

[Markus Fischer]

On 31.08.20 20:13, Riikka Kalliomäki wrote:

Another similar problem with creating array copies is the detection of
"indexed" arrays (as opposed to associative arrays).


I'm looking forward to an answer from someone proficient in this area 
because _I think_ the engine _internally_ keeps track of this for 
performance optimizations, though I don't think it exposes it.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Markus Fischer]

On 10.08.20 13:32, Jordi Boggiano wrote:

https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c


This is really really useful!

However I suggest to look at the raw text rather, because the 
highlighting is unaware of the syntax and may bias "how it feels to look 
at it" (*):


https://gist.githubusercontent.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c/raw/ccb612d2547c99fe69d1bf09138efae22b956b37/attributes.php

Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>` 
in fact is the most "unreadable" version to me because duplicate 
occurrence of a single character somehow creates a noise _for me_,


I don't feel eligible to have a vote, but based on that and certainly 
aware IDEs in the future will help with this, I would vote for 
_anything_ not duplicating characters, i.e. favoring `#[]` or `@[]`


:-}

- Markus

(*) Apologies for lack of words trying to describe my thoughts

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe operator

[Markus Fischer]

Hi,

On 14.07.20 10:51, Ilija Tovilo wrote:

Would this still work together with short-circuiting and the null
coalesce operator?

$country = $session?->user?->getAddress()?->country ?? 'defaultCountry';


Yes, your example will still work, this is solely about references :)


Thanks for clarifying, that's fantastic :)

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe operator

[Markus Fischer]

Hi Ilija,



I'd like to introduce another RFC I've been working on:
https://wiki.php.net/rfc/nullsafe_operator

It introduces the nullsafe operator ?-> that skips null values when
calling functions and fetching properties. In contrast to the last few
attempts this RFC includes full short circuiting.


Would this still work together with short-circuiting and the null 
coalesce operator?


I just didn't see a clear example about this but also figured that could 
be a practical way to use this:


```php
$country = $session?->user?->getAddress()?->country ?? 'defaultCountry';
```

(hope the example is readable, my MUA insists on wrapping the lines)

thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Markus Fischer]

Hi Theodore,

On 08.06.20 06:36, Theodore Brown wrote:

```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
   ManyToMany(Phonenumber::class),
   JoinTable("users_phonenumbers"),
   JoinColumn("user_id", "id"),
   InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),



private $phonenumbers;

// 160 characters for attributes
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
```


When your proposal came up, my first thought was this is great and 
should be supported; I simply had a liking for this terse syntax over 
the older.


Until I read your email last night and saw some direct text comparison.

I noticed that my `@` character did bleed/meld almost with the first 
character of the attribute name. I noticed this in my MUA so I figured a 
proper test in the IDE with my font of choice is more realistic; here's 
a plainly colored version first:


https://i.imgur.com/tq7FzQz.png

Notice how wide characters like the `M` almost touch the `@`.

Same now in a best attempt PHP syntax highlighted source file (courtesy 
of PhpStorm, obviously not supporting this ATM):


https://i.imgur.com/WVXL8S7.png

But even a clearly distinct colored `@@` token did, for me personally, 
not increase the readability by much ("to me").


At this point I forgot if the following is a valid combination, but it 
wouldn't matter as I want to make comparison data point for my 
personally and even this version is by far more readable, to me at least:


https://i.imgur.com/GI3HlsM.png

Until I had this realization, I was absolutely in favour of `@@`. I'm 
not so much anymore.


Since we humans read source more often then we write, I can only suggest 
to everyone to conduct their own "visual" testing first and not just 
judge on technical merits => I think it makes sense to consider both 
here, since we're already discussing a change here.


(note: I'm not a voter here)

I wonder what others think about this.

thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Mixed type

[Markus Fischer]

On 24.04.20 16:33, Bob Weinand wrote:

Actually,


Really had to laugh, reading your previous and then this mail :-)




I forgot that for proper generics implementations, collections etc. will obviously need 
to specify "allowing any type". As such the introduction of mixed is pretty 
much necessary.

As in class Foo { … } $foo = new Foo;

As such, I'm actually in favor of introducing it.


Re-quote:
> "allowing any type"

That would make the case for the `any` type instead of mixed; IMHO much 
more clear.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Mixed type

[Markus Fischer]

Hi,


just picking on one of the examples:

On 20.04.20 17:45, Benjamin Eberlei wrote:

- json_encode, serialize, and more generally serialization and encoding
functions, as return value as well for the inverse operations


But how would this work for serializing resources, which is part of mixed?

Seems to me exactly this case would benefit from a, albeit long though 
more accurate, actual union type.


Hope that makes sense,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Markus Fischer]

Him

On 02.04.20 12:07, Nikita Popov wrote:

Reflection will see the state after desugaring. That is, it just sees
normal properties and normal constructor args. I've made this more explicit
in the RFC now: https://wiki.php.net/rfc/constructor_promotion#reflection


Thanks!

Another one, also related a bit to your PHP-Parser (?): will the 
tokenization process "see" the code before desugaring?


I'm wondering how automated translation tool can detect that a certain 
code is not "sugared" and promote this?


thanks!
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Markus Fischer]

Hi,
On 2020-03-26 14:30, Nikita Popov wrote:

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is *easy* to use.


The amount of boilerplate this would cut down for e.g. projects using DI 
and DTOs is unfathomable.


How does this work together with reflection? Will reflection see the 
properties _and_ the extended constructor definitions?


thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.4.1 Released!

[Markus Fischer]

On 18.12.19 12:45, Derick Rethans wrote:

Changelog:


I think the date here is wrong, it says "19 Dec 2019" but it's the 18th 
today 🤷‍♀️


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Adding explicit intent for SWITCH/CASE fall through?

[Markus Fischer]

On 18.10.19 00:07, Mike Schinkel wrote:

case 'educationtype':
   $update = false;
   fallthrough;


I was about to suggest `continue`, alas we know that would clash :-)

Suggestion: `next;` instead?

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures

[Markus Fischer]

Hi,

On 15.06.19 23:53, Wes wrote:

https://wiki.php.net/rfc/alternative-closure-use-syntax



Thanks for the RFC and effort,


I know it seems overkill and wrong to have two different syntaxes for the
same thing, but I really believe that's all we need to fix one of the most
hated PHP syntax bits.


Technically, no versions seems better than the other.

Personally I don't see how this fixes anything but introduces two ways 
of doing the same thing.


I've never really seen people having problems with the current syntax 
but I'm not saying there aren't. The same argument can be made for all 
the array/str function and people having a hard time to remember which 
function takes theneedle/haystack and what argument position or similar 
to map/reduce/etc.


From the RFC:
> Specifically, it requires a lot of effort to write compared to normal 
expressions.


This are bold words: "a lot". The problem with this argument is that 
there's almost no way to properly argue for or against this. This is 
like art and creativity: it's a personal choice and some like it, some not.


Choice is nice and all, but in terms of code style it just creates an 
overhead (= decision to make which style to use) and I rather prefer 
"one true" way of doing things unless absolute necessary.


I'm -1 on introducing a 2nd syntax without clear benefits of any kind 
that I can see.


That syntax exists now for 10 years, I'd say people can and do 
accommodate and there's no need for this.


thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Numeric Literal Separator

[Markus Fischer]

Hi,

On 29.05.19 09:49, Côme Chilliet wrote:

What bugs me with this RFC is that it seems to be mainly intended for grouping 
digits by 3, which from what I understand is cultural.
At least some asian languages have a concept of 
https://en.wikipedia.org/wiki/Myriad and group them by 4, at least from the 
language point of view.
It does seem when writing as numbers they still group by 3, but it seems other 
usages exists:
https://japantoday.com/category/features/lifestyle/10-000-or-1--japanese-schools-are-starting-to-move-commas-on-big-numbers-but-why


My understanding from the RFC is that that the grouping is not relevant, 
the `_` is stripped regardless.


I would expected this all to work the same

- 1_000_000 => 100
- 100_  => 100
- 1_0_0_0_0_0_0 => 100

It even gives similar examples with the hex variant:

0x42_72_6F_77_6E; // with separator

Am I wrong?

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[Markus Fischer]

Hi, Gabriel,

On 10.04.19 10:33, Gabriel O wrote:

Those parentheses are important when having multiple argument


Please don't top post, thanks!

Thanks for pointing it out, I'm aware.

Still `===>` would better stand out to _me_ personally.

thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[Markus Fischer]

On 10.04.19 00:10, Robert Hickman wrote:

- $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url));
- $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url));

I would say that when lambda functions occurs in function calls I find the
\ or ==> syntax more readable.



To me, in that context, '==>' is the most readable as it does not have
parentheses on the argument. It's a bit visually noisy with them.


I concur, `==>` to me also stands out the most easiest to read without 
too much parenthesis noise.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Offset-only results from preg_match

[Markus Fischer]

On 19.03.19 15:58, Nikita Popov wrote:

I'm wondering if we shouldn't consider a new object oriented API for PCRE
which can return a match object where subpattern positions and contents can
be queried via method calls, so you only pay for the parts that you do
access.


Or also a literal syntax would be very very nice :-)

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Offset-only results from preg_match

[Markus Fischer]

On 14.03.19 20:33, C. Scott Ananian wrote:

ps. more ambitious would be to introduce a new "substring" type, which
would share the allocation of a parent string with its own offset and
length fields.  That would probably be as invasive as the ZVAL_INTERNED_STR
type, though -- a much much bigger project.


That feature would be incredible to have.

Erlang/Elixir use these concept and it's incredible what they can do 
with this.

However, the data types there are also immutable so it's whole other league…

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

[Markus Fischer]

Hello,

On 06.03.19 01:16, Andrea Faulds wrote:

https://wiki.php.net/rfc/trailing_whitespace_numerics

I expect this should be an uncontroversial proposal, but maybe I'm 
jinxing it there. I hope you all like it. :)


Thanks to Nikita for reminding me it existed and thus motivating me to 
pick it up again. Also thanks to Nikita for suggesting a potential 
follow-up RFC, and also making the “Saner string to number comparisons” 
RFC, both providing additional impetus for me to finally clean this up 
and put it to discussion.


Hmm, my first reaction would be the opposite.

For all the changes which happened during the years, PHP got stricter; 
this would make it more lax.


I know this is totally not the goal of the RFC, by my feeling is if we 
would change something (ignoring BC break for a sec) that it would be to 
actually _remove_ support for leading whitespace 🤷‍♀️


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] phpenmod/phpdismod

[Markus Fischer]

Hi,

On 04.02.19 07:24, Remi Collet wrote:

Le 02/02/2019 à 20:24, Legale Legage a écrit :

These scripts are included to the standard deb/rpm packages


No, this is a deb only stuff

RPM installed = extension enabled.


Remi


P.S. I have never understand the need of such tools...
did it made sense in previous century, where download have a cost ?


I find them mostly useful when developing and sometimes useful when in 
production to not have to navigate around the filesystem how to 
enable/disable.


Need ensure my unit tests don't accidentally use redis? `phpdismod 
redis` and done. For all installed PHP versions (maybe due to using the 
popule Ondrey packages though).


Temporarily disble opcache in production because I suspect an issue with 
it? `phpdismod opcache`, reload FPM and done. Don't have to remember 
which exact directory/file which is like 
`/etc/php/./mods-available/ .


That said, it seems really distribution specific to me too.

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Markus Fischer]

Hi,

On 22.01.19 21:34, Girgias wrote:

- phpversion (use PHP_VERSION constant)


The function takes an optional argument `string $extension`, what is the 
replacement for that?



- intval (for arbitrary base change there exists the math function
base_convert)


I've seen and myself use the following construct a lot to "quickly" 
convert data within an array:


$data = array_map('intval', $data);

It's really practical because I don't have to write a (more verbose) 
closure.


I'd argue this applies to the other `*val` calls too.


- join (alias of implode)

Old signatures:

- implode (historical signature)


Is there a correlation here why you mention the alias join and the 
actual function implode? I hope you would want to leave either in the 
language  :-)



cheers,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making stdClass iterable

[Markus Fischer]

On 12.01.19 21:13, Dan Ackroyd wrote:

Hi Duncan,

[...] great points

I was about to reply to Craig when Dans' email hit the list.

I couldn't agree with Dan more.

The expanded use of stdClass feels wrong to me, as in: wrong solution to 
a problem best solved differently. Dan gave ample examples about that.


I think one more approach not mentioned is that you could also `(array) 
$yourStdClassVar`. Of course you didn't ask for it, but nevertheless: 
stdClass is already a weird thing on its own and I wouldn't want to see 
it getting more attention to increase the encourage to use it.


cheers,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface

[Markus Fischer]

On 11.12.18 16:42, Marco Pivetta wrote:

  > People who don't know what FFI is, don't need it.

I think this is a very dangerous way of designing, writing and documenting
software.

I appreciate your efforts in pushing this forward, but please reconsider
when approaching the naming problematic, because this point of view is
extremely flawed.



I'm fine with FFI and it matches other scripting languages (python, 
ruby, lua). Not saying that's the reason to not change it but seems to 
me the name is most appropriate in its field; I see no harm.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Add FILTER_VALIDATE_INCLUDE validation filter for variable includes

[Markus Fischer]

On 21.09.18 14:07, Andrey Andreev wrote:

On Fri, Sep 21, 2018 at 3:03 PM, Rowan Collins  wrote:

Hi Arnold,

Please remember to click "Reply All" / "Reply List" rather than just
"Reply", to make sure the list is included in your replies. Right now, most
of us are only seeing half the conversation:
https://externals.io/message/103196



Weird, I see the list as a recipient in his replies ... Maybe
something's blocking him?


I didn't see this reply either, only yours. Maybe you received them 
because you were directly addressed? 🤷‍♀️


cheers,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.3 Release Manager Selection

[Markus Fischer]

On 01.05.18 20:19, Sara Golemon wrote:

With 7.3.0-alpha1's date on June 7th I'd like to have RMs confirmed by
mid-May.  To that end, I'm placing a deadline on nomination/acceptance
of April 30th and will be opening the vote (assuming we have more than
2) on May 1st.


Whelp! It's May day, and cmb and stas are the only official volunteers
(Derick has withdrawn his offer to step in since Stas is available).
With only two candidates, there's no need for a vote.

Ladies and gentlemen, I give you your PHP 7.3 Release Managers:
Christoph M. Becker and Stanislav Malyshev


Thank You! \o/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Markus Fischer]

On 2018-02-11 20:41, Wes wrote:

Hello PHPeople, I present to you... the shortest RFC ever.

https://wiki.php.net/rfc/deprecate-backtick-operator

Let me know what you think!



I don't have much of an opinion yet on the issue (observing the 
arguments in the discussion so far), but one thing which stuck out for 
me from one other recently announced RFCs [1] was the additional thought 
of automating the code change via migrations tools, etc.


No one likes to do things manually and getting support for code fixers 
could be of help here.


cheers,
- Markus

[1] https://wiki.php.net/rfc/fallback-to-root-scope-deprecation

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Shorthand proposal for associative arrays

[Markus Fischer]

Hi,

On 28.01.18 03:51, Christian Schneider wrote:

2) More importantly: It hides the variable being used: 'src' instead of $src 
which makes it harder to search for the variable or statically analyse the code.


I'm not sure about that argument.

compact() been around basically since forecer. Modern PHP IDEs do 
support this already and I'm pretty sure static analyzers do too (I now 
for a fact that both PhpStorm and phpstan support it).


In contrast, I've this argument:
With compact() you have a clear call acting as a boundary when such a 
behaviour is used. Use the direct-variable syntax doesn't give you that 
because you would at least know the name of a variable or apply regular 
expression for such but I bet you can't easily use any tool at hand like 
you could with compact.


Is this _more_ relevant than your arguments? I'm not to judge :)

But I too believe compact() serves well and covers everything and the 
proposal is one more thing to put alternative syntax for something 
already possible.


I also weight that it's practical impact is much more less then compared 
to e.g. the coalesce operator. That ons is also just syntax sugar but it 
really made an impact to the language because that pattern is very very 
common.


I don't think this applies to compact(); it only has very special 
use-cases (and it's not only templating…), I see it in almost every 
project I work and (and use it myself) and I never felt something 
"fix-worthy" with it.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Markus Fischer]

Hi all,

On 26.12.17 16:56, Sebastian Bergmann wrote:

Am 26.12.2017 um 16:46 schrieb li...@rhsoft.net:

would you mind to explain this?


"Foo|Bar", "array|string", etc. (still) make no sense to me.

"scalar" makes sense to me although it is but an alias for
"bool|float|int|string".


I followed the discussion and found it interesting how strong the focus 
shifted about the discussion of the practical use cases. I would be for 
union types or scalars in ab instant, but I never had reason to scan our 
code-base and figure what would make really sense.


Mind you this is a private codebase (Laravel based, as can be seen by 
some of the class names) but one where we tend to be very explicit about 
documenting everything, thus I knew I could just go ahead and extract 
the type hints using the '|' character and get back a pretty complete 
picture:


$ grep -r '@param' *|grep \| | awk '{ print $4 }'|sort -u
Attachment[]|Collection
Attachment[]|null
Builder|null
Channel|Post|int|null
Channel|int|null
ClientInterface|null
Client|int|null
Collection|Attachment[]
Collection|Channel[]
Collection|Comment[]
Collection|JsonapiModel[]
Collection|Model[]
Collection|Post[]
DateTime|Carbon|string|null
Dispatcher|null
EloquentCollection|JsonapiModel[]
Exception|null
Group|Group[]|Client|Client[]|Channel|Channel[]|null
Group|int|null
JsonapiModel|null
Model|int|null
Post[]|null
Post|int|null
Profile|int|null
ResponseInterface|null
Throwable|null
User|int|null
\ArrayAccess|array|JsonapiModel[]|null
array|false
array|null
int[]|int
int|int[]
int|null
mixed|null
null|LoggerInterface
null|Model
null|Model[]|Collection
null|string
string[]|Expression[]
string|int
string|null

This is extracted from a codebase with ~400 files and ~43k LOC (incl. 
comments). I'm not saying anything like this is relevant codebase, but 
it's a project whose code quality I know well and I know the reason for 
every piece there.


Since the discussion focuses on scalars here and ignoring all the 
nullables (they're auto-documented that way via PhpStorm) as well as 
ignoring the pseudo array-type hints, this leaves us really with only:


- array|false
  Only 1 occurrence, used for crafting a remote HTTP call which has an 
interface which accepts either an array or false 🤷‍♀️

- string|int
  Only 1 occurrence, used for error codes which may come in either 
flavor, send back via HTTP somewhere


I was surprised how less of a use we would really have for a) `scalar` 
itself and b) scalar unions.


OTOH, typed array hints seem to be very useful as are class based union 
types. Although if one looks closely, it's clear this isn't a "union" 
problem, but rather an emulation due to the absence of Generics, e.g.


Attachment[]|Collection

Is clearly a replacement for something like

Collection

I hope I didn't distract to much from the discussion but though I throw 
in some data from an actual application. I'm sure there are much better 
OSS projects out there which could be used for such analysis.


thanks,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Markus Fischer]

Hello Rasmus,

On 19.06.17 22:22, Rasmus Schultz wrote:

If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?

I think I would just keep using the old syntax, then - for consistency, and
to save myself the frustration of factoring back and forth.


I'm writing closures every day and it's so rare to have this changes 
from single/multiple I don't even remember. I think in practice this is 
a non-issue except for very rare special cases and, don't forget: it's 
optional, you don't have to.



In my opinion, if this is worth doing, it's worth doing it right.


No counter-argument here :)

I just think your example is an exaggeration to what happens in practice.

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Snapping php

[Markus Fischer]

On 10.05.17 16:05, Alan Pope wrote:

What we're really after though is feedback. We've got documentation
[3], tutorials [4] and a fourm [5] where the developers hang out.
We're keen to know where the rough edges are, and what we can do to
improve the experience for developers and users alike.


Your initial mail wanted me to check it out on snapcraft.io (never heard 
of snaps before) and I had to go to 
https://snapcraft.io/docs/snaps/intro to "get" what this is about.


For me these 3 point bullet list was the important part and thought it 
would be better suited on the start page.


My Feedback 2€ ;)

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

[Markus Fischer]

Hi,

On 29.04.17 17:53, Sara Golemon wrote:

1. If the parameter isn't reflectable, then it shouldn't be subject to
enforcement.
This argument holds no water because internal functions can only
reflect array or object type hints, yet we enforce other types
routinely.


I selected unfortunate words and wanted to mention reflection as an 
example (in retrospect a bad and confusing one), but would I really 
meant was the "user readable / visible" contract of the function 
definition, as in: "you look at it and know what to expect what it accepts".


I've read through the thread and see your arguments but, to me, the fact 
that this is "nested hidden" in the data structure passed to the 
function still doesn't want me to have this dependent on the strict 
types. I feel that strict types is misused here.


regards,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

[Markus Fischer]

Hi,

On 22.04.17 13:40, Colin O'Dell wrote:

Hello internals,

I'd like to propose an enhancement to curl_setopt()
 which is used to
configure a given curl session.  The second argument of this function
defines which option to set and the third argument provides the
corresponding value to use.

Because each option expects the value to be a specific type, it makes sense
to enforce these types in strict type checking mode.  I'd therefore like to
propose that we introduce strict type enforcement inside curl_setopt() when
"declare(strict_types=1);" is being used.


I'm sorry to say but I think this /approach/ is a horrible idea :(

To me the intention of strict types is clearly on the functions publicly 
visible contract, i.e. it's reflectable parameters and not some business 
logic hidden inside a function.


regards,
- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization

[Markus Fischer]

Hi,

On 06.01.17 18:02, Wes wrote:
> Greeting fellow elePHPants and happy new year.
> 
> I've just started the vote for the RFC in subject. You can find it here:
> 
> https://wiki.php.net/rfc/throwable-code-generalization

The RFC states:
"In practice this is mostly a documentation change ... "

Does this now mean there will be a code patch for \Exception and \Error
or not?

IMHO the text is not so clear on that and no diff/patch/PR is linked.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Outdated links on https://wiki.php.net/systems

[Markus Fischer]

On 18.01.17 10:44, Maciej Sobaczewski wrote:
> I will ask differently: will wiki.php.net/systems be updated afterwards?
> 

I saw a few outdated links there, maybe someone can correct/remove them?

Within "Machine Status"

- "public network status" http://monitoring.php.net/status/ => 404
- "available here" http://monitoring.php.net/munin/ => 404
- "protected area" http://monitoring.php.net/nagios/ => 404
- And it isn't "Nagios" anymore but "Icinga".

Seems only http://monitoring.php.net/ itself is relevant anymore.


:-)

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Change in type-hint representation

[Markus Fischer]

On 11.01.17 13:07, Dmitry Stogov wrote:
> https://gist.github.com/dstogov/1b25079856afccf0d69f77d499cb0ab1

- there's a typo "/* this is a calss name */" a few times

- a few times I see this condition: "if (info->type > 0x3ff) {"

  Shouldn't we use *some* descriptive constant for this seamingly
  cryptic looking 0x3ff ?

The approach looks great .. are there any benchmarks?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

[Markus Fischer]

Hello,

On 13.12.16 10:17, Silvio Marijić wrote:
> After much thinking regarding array in immutable objects I'm thinking of
> revoking this RFC. If someone has some suggestion on that matter now is the
> time, but otherwise my work is done on this one.

It would be nice if you could summarize the feedback into the RFC too
(i.e. the "Cons" points), maybe someone wants to pick it up later or
learn from it.

And thanks for the effort!
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] User defined session serializer

[Markus Fischer]

Hi,

On 05.12.16 02:44, Yasuo Ohgaki wrote:
> This RFC exposes session serializer interface to user space. It works
> like user defined session save handler.
> 
> Users are able to encrypt/validate session data transparently. e.g.
> You can save encrypted session data to database, decrypt encrypted
> data from database transparently.
> 
> https://wiki.php.net/rfc/user_defined_session_serializer
> Vote starts: 2016-12-05 Vote ends: 2016-12-19 UTC 23:59:59
> 
> Although we don't have consensus about number of votes to pass, I set
> this RFC to require 2/3 votes.

thanks for the RFC. I voted "yes", because I see the value in having the
format of the serialization being separated from how sessions are
loaded/stored.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC DISCUSSION] User defined session serializer

[Markus Fischer]

Hello,

On 17.11.2016 11:55, Yasuo Ohgaki wrote:
> 
> Session module implements serialize handler as module.
> This RFC is to expose it to user space.
> 
> RFC
> https://wiki.php.net/rfc/user_defined_session_serializer
> 
> PR
> https://github.com/php/php-src/pull/2205
> 
> Comments are appreciated!

Well, I like it. It's sometimes necessary to share session state with
non-PHP application and this is IMHO a welcome addition to ease the
exchange.

Btw, what is the proper way to signal a problem during
serialization/unserialization? I couldn't figure it out from the RFC nor
the PR and there doesn't seem to be a test case for it.
Return null/false? Throw an exception?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint

[Markus Fischer]

Hi,

On 23.10.16 09:39, Michał Brzuchalski wrote:
> I would like to initiate discussion for Object typehint RFC
> https://wiki.php.net/rfc/object-typehint
> 
> This feature is developed to provide missing functionality which is needed
> and quite easy to introduce.
> There are many people which I've talked about the benefits of this
> functionality.

I just wished a few weeks ago I was able to typehint that. Actually I
even tried just to lern it doesn't work.

It's a unit test helper method to make a method on an object public,
signature:

protected function makeMethodPublic(object $obj, string $methodName):
ReflectionMethod

So, I can come up with exactly one (to me) useful case, but it's
arguable not "that important" and I certainly wouldn't and didn't add an
is_object check for this, so there goes my priority for it.

thanks,
- Marus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Counting of non-countable objects

[Markus Fischer]

Hi,

On 04.10.16 11:32, Craig Duncan wrote:
> I'd like to propose the introduction of warning when counting objects that
> can't be counted.
> 
> The default behaviour is to return 1 for these objects, which can be
> misleading and hide bugs when attempting to count iterable objects (eg
> Generators). Adding a warning would alert developers to the issue
> 
> https://wiki.php.net/rfc/counting_non_countables

FTR, this also applies to certain non-object types too, see
https://3v4l.org/jqntq :

http://www.php.net/unsub.php

[PHP-DEV] About session.use_strict_mode=0 by default (was: Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing)

[Markus Fischer]

Everytime I see a thread mentioning session.use_strict_mode I'm
wondering why we haven't got around to enable it by default (by means of
php.ini-development/php.ini-production ).

Maybe someone can step forward and propose this change for the next
version (not 7.1 ...)?

It could be documented as a breaking change, refer to the documentation
and finally call it a day :-)

- Markus

On 02.07.16 10:39, Leigh wrote:
> Actually decided to post so
> 
> On Sat, 2 Jul 2016 at 09:16 Leigh  wrote:
> 
>> On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki  wrote:
>>
>>> Hi all,
>>>
>>> Currently session module uses obsolete MD5 for session ID. With
>>> CSPRNG, hashing is redundant and needless. It adds hash module
>>> dependency and inefficient (There is no reason to use hash for CSPRNG
>>> generated bytes).
>>>
>>> This proposal cleans up session code by removing hash.
>>>
>>> https://wiki.php.net/rfc/session-id-without-hashing
>>>
>>> I set vote requires 2/3 support.
>>> Please describe the reason why when you against this RFC. Reasons are
>>> important for improvements!
>>>
>>
>>
>  So I have a few issues that span the RFC and the implementation.
> 
> Your RFC states
> 
>> hardcoded default and php.ini-* default values are the same.
> 
> This is not the case.
> 
> Originally the session id length and character set were controlled by
> session.hash_function and/or session.hash_bits_per_character. These
> customisations to configuration will be lost when the user upgrades. You
> have provided a mechanism to control length and charset, but it will
> require new changes to the default settings. This needs to be noted as a
> breaking change.
> 
> Your default for session.sid_length is 48. Up to 7.1 the session id length
> is 32. Your default for session.sid_bits_per_character is 5, up to 7.1 the
> session id uses 4 bits per character. This is a breaking change. (Imagine
> custom session handlers that validate session id character sets, or
> database schemas that will truncate after 32 characters)
> 
> Your patch updates session.use_strict_mode from 0 to 1. I actually don't
> know what this changes, but it's an undocumented change.
> 
> Overall your patch looks very similar to the one I was working on earlier
> in the year, although you appear to have deleted a bunch of tests that you
> could have just updated. You should probably put those back, and update
> them.
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New escaped output operator

[Markus Fischer]

On 01.07.16 05:34, Михаил Востриков wrote:
> Because it is almost impossible to add template engine in a big project
> with PHP templates. But new version of language usually can easily be used.

I interpret "But new version of language usually can easily be used" as
in a new PHP version being installed on a server touted as being
"easier" than changing/replaced/adding a new template language component
with a framework?

I object to this. I can easier add a new template to e.g. a Laravel
project (own parser, own extension, living next to existing blade
templates) then switching to a new PHP version on production servers.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)

[Markus Fischer]

Hello Nikita,

On 23.05.16 21:27, Nikita Nefedov wrote:
> When you pass an `int` to a `string` type parameter in weak mode
> it's being coerced to the needed type (not just directly passed).
> 
> This is quite complex, because you'd need to copy zend_function
> and all its members (without changing the original zend_function).
> 
> I would love to support it but all in all it comes down to
> implementation here for me, so I'd rather do it in a separate
> RFC.


I like the RFC, however I do not like this behavior.
This would behave differently then how current weak/strict mode works.

I was never a fan of the weak mode to begin with, but now introducing
something which deals in the area of argument passing and not behaving
to what a 2/3 majority agreed is IMHO a no-go. The current RFC does not
even mention that.

Maybe it's not feasible anyway, but in any case I'm missing
input/discussion in this area.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Markus Fischer]

Hey,

On 07.04.2016 14:21, Andrea Faulds wrote:
> Bob and I have made an RFC which proposes an alternative syntax for list():
> 
> https://wiki.php.net/rfc/short_list_syntax
> 
> Please tell us your thoughts.

Reading the last sample in the RFC:

>  Both due to implementation issues, and for consistency's sake, list()
cannot be nested inside [], nor vice-versa:
[...]
> // This, however, is allowed:
> [[$a, $b], [$c, $d]] = [[1, 2], [3, 4]];

and then

>  This RFC has no impact upon OPcache or other extensions dealing with
PHP opcodes, because the compiled result is identical to the list() syntax.

Without any deeper technical knowledge, these two things don't look
compatible to me at first. It's probably a non-issue, but mentioning the
list() can't be nested, the new destructuring syntax can, but "the
compiled result is identical to the list() syntax" doesn't add up somehow.

If you can elaborate on this, that wold be nice. Thanks :)

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] Session ID without hashing

[Markus Fischer]

On 06.04.2016 07:47, Yasuo Ohgaki wrote:
> Session module does not require hashing to generate session ID. This
> RFC removes hashing from session module and enable use_strict_mode as
> an insurance for broken RNG.
> 
> https://wiki.php.net/rfc/session-id-without-hashing

I cannot talk about the merits of the randomness-change here, but
use_strict_mode defaulting to 1 is major +1 from me.

Why it's advertised everywhere as best practice but even set to 0 in
php.ini-production is beyond me.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Traits with interfaces

[Markus Fischer]

Hello,

On 17.02.16 15:25, Kevin Gessner wrote:
> I've noticed s pattern in Etsy's code and elsewhere, where a trait provides
> a common implementation of an interface.  Classes that use the trait are
> required to also explicitly declare the interface to benefit.  I propose
> that traits be permitted to declare and implement interfaces.

I like this, because this is a pattern I experienced myself.

In my code I've:

- interface GroupBulkFilterable { .. }
- trait GroupBulkFilterTrait { .. }

and later


class AbstractModelBridge implements ModelBridge, GroupBulkFilterable {
  use GroupBulkFilterTrait;

Would use the interface on the trait in an instant.


> Classes that
> use such a trait would then implement the interface, as though it were
> declared on the class, without declaring the interface explicitly.

I don't like this. I prefer explicit over implicit.

I would still see value in the first point only (but haven't thought
that through ...).

cheers,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a new array function

[Markus Fischer]

Hi,

On 08.02.16 18:06, Cesar Rodas wrote:
>>> return array_keys($arr) !== range(0, count($arr) - 1);
> 
> `array_keys($array) === range(0, count($array)-1)`

That approach would fall flat when the numeric keys are not consecutive:

$array = [1=>"a", 3=>"b"];

Disclaimer: AFAIK complete goal of the function wasn't yet stated, thus
this could be considered /acceptable/.

cheers,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

[Markus Fischer]

Dear Giovanni,

I brought this up last July, see https://bugs.php.net/bug.php?id=70050 ;
because in a few code bases I tested back then, this was the first issue
I hit.

Unfortunately, it was only deemed a "Documentation Problem" back then.
AFAIK this is the most up to date information. Sorry I don't have
further news.

cheers,
- Markus

On 11.01.16 14:31, Giovanni Giacobbi wrote:
> Greetings,
> 
> Short premise before I get flamed: I know PHP 7 is rolling and it is way
> too late for this, that I should've tested the RCs, follow the mailing list
> and so on, but I'm a dev like you guys and struggle with the time to do
> everything by the book, including reading the previous threads because I'm
> pretty sure this was brought up by somebody, but as there are hundreds of
> message under the "Throwable" topic and I can't read all of them.
> 
> In short I have this situation:
> 
>  class SpecificHandler {
>   public function exception(Exception $e) {
> .. do something very useful...
>   }
> }
> 
> function global_handler($e) {
>   SpecificHandler::exception($e);
> }
> 
> set_exception_handler("global_handler");
> ?>
> 
> This happens because the specific handler will output the exception
> according to the expected format (HTML, JSON, or even an image).
> 
> Now after upgrading to PHP7 when one of the new Error exception is thrown,
> I get the following error:
> 
> PHP Fatal error:  Uncaught TypeError: Argument 1 passed to
> SpecificHandler::exception() must be an instance of Exception, instance of
> Error given, called in [...]
> 
> Having been a PHP dev for 10 years now I know that the policy is to try to
> break as little as possible while implementing new features, and I like
> that. I know that sometimes things must be broken to progress, but in this
> case maybe there is a very simple fix that I can suggest to avoid breaking
> existing code, change set_handler_exception like this:
> 
> set_exception_handler(callback function, bool also_throwables = false);
> 
> The new parameter "also_throwables" defaults to false, so the same
> behaviour as before is preserved. If you want it to catch also the new PHP7
> Error exceptions, you can just set it to true.
> 
> What is your take on this? I know I can easily fix my code to work on both
> PHP 5.x and PHP 7.x, but I really disliked this kind of BC.
> 
> Kind regards
> Giovanni
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST request to fastcgi FPM with chunked encoding does not properly return result

[Markus Fischer]

Hello Xinchen,

since I've seen you did most of this work around fastcgi during this
transition, I was wondering if you maybe have any idea what the problem
could be?

thanks,
- Markus

PS: sorry for top-posting, but though it was more appropriate as there's
no context-specific question on my part yet.

On 23.12.15 23:15, Markus Fischer wrote:
> Hello,
> 
> I wrote up a detailed question at SO but I had a hunch it could be a
> real bug (
> http://stackoverflow.com/questions/34440220/post-request-to-php7-with-chunked-encoding-does-not-properly-return-result
> ).
> 
> Basically, a POST request to php-fpm with "Transfer-Encoding: chunked"
> and post data (could be even empty) does not return anything:
> 
> $ curl -XPOST http://localhost/ -H "Transfer-Encoding: chunked" -d ''
> curl: (18) transfer closed with outstanding read data remaining
> 
> The PHP script could be anything returning a small amount of data, i.e.
> below 4kb. A simple echo "world" would suffice.
> 
> 
> The last commit I was able to compile which works was this one:
> https://github.com/php/php-src/commit/16265a59ac6bd433bfb636e4e44da1ad57cdcda9
> 
> After that, for a few commits, the tree for me was in a state where I
> couldn't compile it.
> 
> The first commit I was able to compile again, but which already exhibits
> the problem, was
> https://github.com/php/php-src/commit/86de98cabada88f4667839794c176ea37648498b
> .
> 
> These are the commits in between I couldn't compile:
> 
> $ git bisect skip
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> ba5ecf355fe792a5a2a8e6582d5e081d02b16fbf
> e383cb4493031a7cd952cfcaed3297e583149c07
> fef18f4bea1980a59a9283c2197bd090aaf500cb
> 18cf4e0a8a574034f60f4d123407c173e57e54ec
> We cannot bisect more!
> 
> 
> The diff is quite involving due files being moved around.
> 
> I'm not very experienced in this area so I'm not sure if the curl call
> should work; however it does work fine in PHP 5.6. I can work around
> this in my application by avoiding "Transfer-Encoding: chunked" but I
> actually want to understand the issue better here, maybe it's even a bug?
> 
> thanks,
> - Markus
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] POST request to fastcgi FPM with chunked encoding does not properly return result

[Markus Fischer]

Hello,

I wrote up a detailed question at SO but I had a hunch it could be a
real bug (
http://stackoverflow.com/questions/34440220/post-request-to-php7-with-chunked-encoding-does-not-properly-return-result
).

Basically, a POST request to php-fpm with "Transfer-Encoding: chunked"
and post data (could be even empty) does not return anything:

$ curl -XPOST http://localhost/ -H "Transfer-Encoding: chunked" -d ''
curl: (18) transfer closed with outstanding read data remaining

The PHP script could be anything returning a small amount of data, i.e.
below 4kb. A simple echo "world" would suffice.


The last commit I was able to compile which works was this one:
https://github.com/php/php-src/commit/16265a59ac6bd433bfb636e4e44da1ad57cdcda9

After that, for a few commits, the tree for me was in a state where I
couldn't compile it.

The first commit I was able to compile again, but which already exhibits
the problem, was
https://github.com/php/php-src/commit/86de98cabada88f4667839794c176ea37648498b
.

These are the commits in between I couldn't compile:

$ git bisect skip
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
ba5ecf355fe792a5a2a8e6582d5e081d02b16fbf
e383cb4493031a7cd952cfcaed3297e583149c07
fef18f4bea1980a59a9283c2197bd090aaf500cb
18cf4e0a8a574034f60f4d123407c173e57e54ec
We cannot bisect more!


The diff is quite involving due files being moved around.

I'm not very experienced in this area so I'm not sure if the curl call
should work; however it does work fine in PHP 5.6. I can work around
this in my application by avoiding "Transfer-Encoding: chunked" but I
actually want to understand the issue better here, maybe it's even a bug?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium

[Markus Fischer]

On 21.05.2015 03:15, Scott Arciszewski wrote:
> I've just opened an RFC for precisely this purpose:
> https://wiki.php.net/rfc/libsodium

>From https://github.com/jedisct1/libsodium-php :

// Binary to hexadecimal
$hex = Sodium::sodium_bin2hex($bin);

// Hexadecimal to binary
$bin = Sodium::sodium_hex2bin($hex);

// Hexadecimal to binary, ignoring a set of characters
$bin = Sodium::sodium_hex2bin($hex, $string_of_characters_to_ignore);

What's the reason for this redundancy (Sodium::sodium_*) ?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices

[Markus Fischer]

Hi Matteo,

On 16.03.15 12:43, Matteo Beccati wrote:
> On 15/03/2015 19:30, Matteo Beccati wrote:
>> In PHP4 times it was in fact quite common to change inherited method
>> signatures to bend them to one's will and/or remove parameters and
>> hardcode them in the parent constructor call. We now know it is bad
>> practice, but I bet there's lot of code using these practices in
>> controlled situations.
>>
>> I'm going to attempt fixing the app code (including the bundled pear
>> libs) and report back.
> 
> So... I've spent a few hours on the cleanup and I'm still far from
> getting a green build.
> 
> As you mentioned in the RFC, turning E_STRICT into E_WARNING is going to
> be a BC-break for someone, and fixing this one in particular requires
> far more effort than a simple search/replace.

am I correct assuming that your existing test suite was running with
E_STRICT excluded from error_reporting ?

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Reclassify E_STRICT notices

[Markus Fischer]

On 15.03.15 16:46, Nikita Popov wrote:
> To ensure we have no shortage of new RFC votes...
> 
> https://wiki.php.net/rfc/reclassify_e_strict#vote
> 
> Voting is open for ten days :)

>From the RFC:

"Signature mismatch during inheritance
...
Possible alternative: Convert to E_DEPRECATED, if we intend to make this
a fatal error in the future.
"

Has there been any decision made which course to follow? I ask since I
don't see voting option for it (not saying it needs one!), it just would
be nice to carve in stone what's going to be done about it.

Otherwise good cleanup RFC IMHO, +1

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Markus Fischer]

On 11.03.15 22:28, Bob Weinand wrote:
> after all, some people are not happy with the current proposals about scalar 
> types. So, they both still possibly may fail.
> 
> Thus, I'd like to come up with a fallback proposal in case both proposals 
> fail:
> 
> https://wiki.php.net/rfc/basic_scalar_types
> 
> It shouldn't prevent any future improvements and still give use all the 
> advantages of scalar types.

I'm not sure I'm seeing improvements over the other RFCs here ... or I
just missed something obvious. From a quick glance, this one here:

Type declration "string" and you pass in a "bool" type.

When in practive the conversion is like this:

$ php -r 'var_dump( (string) false ); var_dump( (string) true );'
string(0) ""
string(1) "1"

$ php -v
PHP 5.5.9-1ubuntu4.6 (cli) (built: Feb 13 2015 19:17:11)


- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Consistent function names

[Markus Fischer]

On 03.03.15 00:10, Yasuo Ohgaki wrote:
> I would love to have new & clean APIs.
> 
> Please think my proposal as legacy API cleanups. Many of candidates will
> remain
> without CORDING_STANDARSDS confirmed names almost forever. This is what
> I would like to improve. If you don't care about legacy stuff cleanups,
> please don't
> care. The cleanups will not hurt anything, almost.

No ill intentions here, but adding the aliases and, as you propose,
literally adding *hundreds* of aliases is actually a mess to me.

What you call "new & clean" is as a shield for effectively introducing
duplicates. You do not clean up anything that way. You leave a even
bigger mess behind. By going for your honorable goal of correcting
things I think you got lost in the woods.

IMHO the only forward is to make sure new/future additions to the
language adhere to the coding standard or use a smart way (i.e. the
scalar addition).

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Consistent function names

[Markus Fischer]

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
>> himself, things can only go south from here.
>>
>> If PHP wants to clean up, then do it right: use a namespace for it.
> 
> 
> I agree use of namespace is better solution. It's rather severe BC, though.
> How about rename functions except "string" and "array" related functions?
> 
> BTW, I cannot change document system, but I'm going to update all doc
> contents if this passes.

I'm not sure we're on the same page. I'm talking about moving in
"no-BC-break" way, if at all. That is, no existing function be touched.

As to whether namespaces-aliases are really necessary I leave for others.

I think a sensible thing to do at this stage would be, rather than
changing existing stuff, laying the ground work how to do it in the
future. What I mean is: an RFC for consistent introducing new "names" in
the PHP language.

So that /future/ functionality does not always get slapped into the
global namespace but that we finally start using our reserved PHP\
namespace and put stuff in there instead of the global pollution.

Yeah, I think that direction is a sensible start and gather peoples
mindset about this instead of going backwards, renaming stuff without
clear plan, etc.

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Consistent function names

[Markus Fischer]

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.
> 
> 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
himself, things can only go south from here.

If PHP wants to clean up, then do it right: use a namespace for it.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

[Markus Fischer]

Hi Zeev,

On 21.02.15 18:22, Zeev Suraski wrote:
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
> 
> I think it’s the RFC is a bit premature and could benefit from a bit more
> time, but given the time pressure, as well as the fact that a not fully
> compatible subset of that RFC was published and has people already
> discussing it, it made the most sense to publish it sooner rather than
> later.
> 
> http://wiki.php.net/rfc/coercive_sth

Thanks for the refreshed approach. Although there are already oh-so-many
RFCs and discussion, I found the sum up to be very clear. Thanks to you
at al.


1) About impact / BC

There's one thing I never understood, even not for 0.3 which almost went
through: why have this impact on internal
function/zend_parse_parameters/ZPP at all?

Why not just keep this strictly user-land /for now/ ?

The user-land change is much more controllable. The internal function
change is ... not sure how to say. Has such a big impact and I'm not
sure what should be the gain at all here.


2) I'm with Pierre regarding accepting e.g. 42.0 for an int. Just
imagine you pass the result of a calculation which happens to be a
result with a clean .0 fractional part and everything works. The next
time you calculate with a different input and *boom* your value is 42.1
and thus reject. That's quite a POLA [1] right there.



I know I will derail this whole thing when I write the next point but I
really think one of the best ways to move forward is to
- only support strict types, e.g. function foo(string $bar)
- in user-land code

That way the there's almost no BC impact sans the possible clashes of
classnames (which I probably just missed how this will be resolved?).


Future RFCs could still reason about other typo of hints (initial weak
STH or now this coercive STH) and expand on the syntax.



thanks,
- Markus

[1] http://en.wikipedia.org/wiki/Principle_of_least_astonishment

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Make empty() a Variadic

[Markus Fischer]

On 21.02.15 06:11, Thomas Punt wrote:
> Hello Internals!
> The following RFC aims to make empty() have a variable arity: 
> https://wiki.php.net/rfc/variadic_empty. This is a simple feature that 
> enables for a short-hand notation of checking multiple expressions for 
> emptiness (which is a pretty common thing to do).
> I have avoided including the is_*() functions into this RFC because my main 
> priority is to get this particular feature into PHP 7.0 before feature 
> freeze. Provided I have some free time over the next week, I'll write up 
> another RFC + patch to cover the is_*() functions.


>From the RFC:
> This behaviour seems to be the most prevalent usage of multiple empty
checks in a condition, therefore benefitting the most end users.

Here I disagree.

I would have assumed from the start that empty() would only return true
if *all* of the entries are empty, i.e. AND things together.

If we enable variable arity then it will join the group of function
where no user sanely can remember if in_array/etc. take the
needle/haystack first or second argument. I.e. whether it will OR or AND
all arguments.


>From the RFC:
> Also, it will make empty() more inline with the not-too-disimillar
isset(), which is good for the Principle of Least Astonishment (mainly
aimed at neophyte developers).

  From http://php.net/manual/en/function.isset.php :
  "If multiple parameters are supplied then isset() will return TRUE
  only if all of the parameters are set. Evaluation goes from left to
  right and stops as soon as an unset variable is encountered."

But this is an AND: "... if all ... are set":

"isset($a,$b)" behaves like "isset($a) && isset($b)"

IMHO this absolutely violates your POLA because as I said this is also
how I would assume empty() with variable arguments would work: Only
return true if all are true.


My personal opinion is that any attempt to change this is ill-fated
because people will no be able to memoize the exact usage of it because
it would mean different things to different people and would just add
more confusion.

-1 on the proposed change.


- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7

[Markus Fischer]

On 20.02.15 18:55, Sara Golemon wrote:
> Announcing this in its own thread:
> https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
> 
> This RFC acts as an addition to Levi's
> https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
> forum for voting on additional types not included in his RFC:
> resource, object, scalar, mixed, numeric

>From the RFC:

“resource”
“object”
“scalar”
“mixed”
“numeric”

"... prohibits their usage as class, interface and trait names."


This is such a major BC break.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7

[Markus Fischer]

On 20.02.15 18:55, Sara Golemon wrote:
> Announcing this in its own thread:
> https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
> 
> This RFC acts as an addition to Levi's
> https://wiki.php.net/rfc/reserve_more_types_in_php_7 by creating a
> forum for voting on additional types not included in his RFC:
> resource, object, scalar, mixed, numeric


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Discussion] In Operator

[Markus Fischer]

On 20.02.15 18:16, Dan Ackroyd wrote:
> On 20 February 2015 at 12:54, Niklas Keller  wrote:
>> Hi internals,
>>
>> It would really make sense to vote on this RFC after there has been a
>> vote on https://wiki.php.net/rfc/context_sensitive_lexer.
> 
> That is an understatement:
> https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr.php#L443
> 
> I don't think changing the language in a way that breaks Doctrine
> would be feasible.

I second this. I didn't immediately reply when I read this restriction
regarding methods but it should have been obvious.

IMHO this is an absolute no-go; and the contex_sensitive_lexer sounds
reasonable but has it's own problematic areas.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Comparable: the revenge

[Markus Fischer]

On 19.02.15 22:40, Adam Harvey wrote:
> Those of you with long memories will remember that I proposed a
> Comparable interface way back in the pre-5.4 days, but withdrew it
> when it became obvious that there was no consensus for it as a feature
> and that a vote was likely to fail.
> 
> RFC: https://wiki.php.net/rfc/comparable
> PR: https://github.com/php/php-src/pull/1097

Afaik \DateTime object already implement a way to be used with <,>,etc.
but they don't use an interface for that.

$ php -r '$past = new DateTime("-1 month"); $future = new DateTime("+1
month"); var_dump($past < $future);'
bool(true)

$ php -r '$past = new DateTime("-1 month"); $future = new DateTime("+1
month"); var_dump($past > $future);'
bool(false)

Shouldn't they retroactively be adopted to that? Extend from that
Interface, implement a compoareTo?

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

[Markus Fischer]

On 19.02.15 16:23, Dmitry Stogov wrote:
>>
>> - how does zend.assertions and assert.exceptions work with
>> "assert_options()" , i.e. isn't the exception behavior meant to be an
>> addition to assert_options() too ?
>>
> 
> zend.assertions control assert() compilation and execution
> 
> zend.assertions=-1 zero-cost, assert() won't be compiled at all (including
> inner code)
> zend.assertions=0  low-cost, assert() will be compiled but won't be
> executes (including inner code)
> zend.assertions=1  assert() wiil be compiled and executed as now

Pardon me, but it doesn't explain what the role of the existing
"assert_options()" function will or does play?


>> - the RFC says: "enabled (zend.assertions=1) on development machines,
>> and disabled (zend.assertions=0) in production"; a few paragraphs above
>> it says "-1 - don't generate any code (zero-cost, production mode)".
>> Shouldn't be -1 the default value for production then?
>>
> 
> With zend.assertions=0 in production, you'll able to switch to
> zend.assertions=0 at any time.
> With zend.assertions=-1 of course not.

I don't understand this. "With 'foo' in production, you will be able to
switch to 'foo' at any time. With 'bar' of course not" ?

Maybe I was unclear. What I meant:
- a few paragraphs above it says that "-1 doesn't generate any code
(zero cost)"
- so why isn't THAT '-1' promoted to be the default in production
php.ini instead of '0' setting?


>> - the RFC says: "A call to assert(), without a fully qualified namespace
>> will call assert in the current namespace, if the function exists. An
>> unqualified call to assert is subject to the same optimization
>> configured by zend.assertions. ". Does this mean I can control whether a
>> function in a namespace is being optimized-away with when zend.assertion
>> equals -1 and otherwise do my own stuff in there and need to raise an
>> AssertException on my own to signal assertion fails?
>>
> 
> Yes. you are able to eliminate your own assert() functions in namespaces.

Wow. The RFC doesn't explain this very well but I wrote this based on
assumption and guesswork.

This sounds two-folded to me: "very cool" (albeit I can't see a use-case
right now) on one hand and "utter magic" on the other.

With utter magic I mean: suddenly a function named 'assert' in a
namespace is eligible to rules before ever only applied to a global
existing function.

I'm not saying it's bad. It's just very magic, sounds cool but could be
a real PITA. Maybe just a documentation problem after all.



As Pierre already mentioned, the RFC really lacks some more details. But
in general, it looks good.

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Expectations

[Markus Fischer]

Hi,

On 19.02.15 10:09, Joe Watkins wrote:
> Morning internals,
> 
> The expectations RFC is now in voting phase:
> https://wiki.php.net/rfc/expectations#vote

- I somehow miss information what the exact differences are to the
current implementation, to better judge the impact.

- how does zend.assertions and assert.exceptions work with
"assert_options()" , i.e. isn't the exception behavior meant to be an
addition to assert_options() too ?

- the RFC says: "enabled (zend.assertions=1) on development machines,
and disabled (zend.assertions=0) in production"; a few paragraphs above
it says "-1 - don't generate any code (zero-cost, production mode)".
Shouldn't be -1 the default value for production then?

- the RFC says: "A call to assert(), without a fully qualified namespace
will call assert in the current namespace, if the function exists. An
unqualified call to assert is subject to the same optimization
configured by zend.assertions. ". Does this mean I can control whether a
function in a namespace is being optimized-away with when zend.assertion
equals -1 and otherwise do my own stuff in there and need to raise an
AssertException on my own to signal assertion fails?

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

[Markus Fischer]

> 2015-02-13 13:50 GMT-03:00 Nikita Popov :
>> use PhpParser\NodeVisitorAbstract;
>> use PhpParser\Error;
>> use PhpParser\Node;
>> use PhpParser\Node\Name;
>> use PhpParser\Node\Name\FullyQualified;
>> use PhpParser\Node\Stmt\Namespace_;
>> use PhpParser\Node\Stmt\Use_;
>> use PhpParser\Node\Stmt\Class_;
>> use PhpParser\Node\Stmt\Interface_;
>> use PhpParser\Node\Stmt\Trait_;
>> use PhpParser\Node\Stmt\Function_;
>> use PhpParser\Node\Stmt\Const_;
>> use PhpParser\Node\Stmt\Catch_;
>> use PhpParser\Node\Stmt\TraitUse;
>> use PhpParser\Node\Stmt\TraitUseAdaptation\Precedence;
>> use PhpParser\Node\Expr\StaticCall;
>> use PhpParser\Node\Expr\StaticPropertyFetch;
>> use PhpParser\Node\Expr\ClassConstFetch;
>> use PhpParser\Node\Expr\New_;
>> use PhpParser\Node\Expr\Instanceof_;
>> use PhpParser\Node\Expr\FuncCall;
>> use PhpParser\Node\Expr\ConstFetch;
>>
>> Damn, this looks unwieldy. With this proposal it becomes:
>>
>> use PhpParser\{NodeVisitorAbstract, Error, Node};
>> use PhpParser\Node\{Name, Name\FullyQualified};
>> use PhpParser\Node\Stmt\{
>> Namespace_, Use_, Class_, Interface_, Trait_, Function_,
>> Const_, Catch_, TraitUse, TraitUseAdaptation\Precedence};
>> use PhpParser\Node\Expr\{
>> StaticCall, StaticPropertyFetch, ClassConstFetch, New_,
>> Instanceof_, FuncCall, ConstFetch};
>>

It's only the former (existing) format which has benefits at all to me:

- cognitively *I* can much easier glance through to "find" something.
Because my eyes just have to scan up/down on the same character column

- It's not alphabetically sorted (which just is important to "find"
things for a human, IMHO). No problem! Good text editors allow to sort a
selected text area alphabetically. Good look trying that with the group
syntax; this requires manual labor work or tooling.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

[Markus Fischer]

On 10.02.15 01:52, Yasuo Ohgaki 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.

How exactly does this detection work?

> move_uploaded_file() searches “start tag” token if it is located as
the first token.

What constitutes "first token" in this context?

Would this be detected as a PHP file?

-8<
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Combined Comparison (Spaceship) Operator

[Markus Fischer]

On 02.02.15 14:49, Nikita Popov wrote:
> I've voted -1 because I think this should be a function and not an
> operator. compare($a, $b) is more obvious than $a <=> $b and it's not like
> writing comparison functions is such a super common use case that it needs
> the extra brevity of an operator. A function can furthermore be used as a
> callback, while an operator requires a wrapping closure.

I support what Nikita said, but it doesn't influence my vote; I see them
separate.

Btw, I would be hesitant to introduce such a common name 'compare'.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Markus Fischer]

Hello Andrea,

On 02.02.15 00:49, Andrea Faulds wrote:
> The RFC has been updated to cover return types, since Levi’s Return Types RFC 
> has passed. The patch is a work in progress: it works, but lacks tests for 
> return types.
> 
> Version 0.3 of the RFC can be found here: 
> https://wiki.php.net/rfc/scalar_type_hints

although my involvement here is very sparse at the moment, please let me
tell you that I a) find it great that you don't give up, are
persistently going for your idea while b) still being objective rather
then emotional. I'm really happy to see such technical, lively
discussion you initiated so far. Thank you :-)

That said ...

- I dislike the RFC since the introduction of the declare() adaption
(effectively 0.2/0.3 now) and did not 100% agree with 0.1

- Since consensus on the strict mode does part the community (or, the
greater community also outside @internals) my impression is that the
current best way to move forward would be

 - get the rfc to only go for weak types for now
 - using the "cast-like syntax": function foo( (int) $bar );

and ultimately keep the strict type out for /now/ and try it at a later
time, the "function foo( int $bar )"-syntax.

I'm actually not really in favor of just weak types, I would consider
myself a "strict type" voter, but through the community communication
here I saw a) the benefits of weak types hinting/casting b) without
getting in the way of a possible future strict type (e.g. with the
"non-cast-like syntax").

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][DISCUSSION] Group Use Declarations

[Markus Fischer]

On 31.01.15 01:09, Marcio Almada wrote:
> After a period of research along with part of the PHP community I'd
> like to present this RFC which aims to improve PHP namespaces.
> 
> The RFC: https://wiki.php.net/rfc/group_use_declarations
> Along with its pull request: https://github.com/php/php-src/pull/1005
> 
> Needless to say, I'm open to suggestions that could improve the proposal.

The RFC says:
"Group use statements makes it easier to identify that multiple imported
entities are from the same module."

IMHO that's too subjective. What "is hard" with the current state of
affairs?


Btw, here's a CON you can add to the RFC (and, btw., it doesn't contain
any):
- Prevents searching sources literally for used namespaces


Another observation thing from my side: with proper tooling I almost
can't remember when I wrote the statements by hand; they usually a) get
automatically managed b) thus alphabetically sorted and c) folded away
in general.

What is the real benefit of using groups it and who's the group
benefiting from that change? Maybe you can expand on that in the RFC.

sincerely,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] journald support for Linux systems that use systemd

[Markus Fischer]

On 08.01.15 02:14, Johannes Schlüter wrote:
> On Wed, 2015-01-07 at 17:01 -0500, Mark Montague wrote:
>> I'd like to start an RFC (see the draft proposal at the end of this 
>> message) for adding
>> journald support to PHP on Linux systems that use systemd.  This message 
>> is to
>> measure reaction to the intended proposal prior to requesting RFC karma.
> 
> I believe the sd_journal_* functions could go in a PECL version, for the
> logging I'd love if logging could be cleanup in a way that we have a
> good internal API for internal use as well as integrates with userlevel
> expectations (-> PSR 3 Log)

That would have been my reaction too, but looking at the diff it plays
on the same level as the "syslog" logging, i.e. it's integral in the
system in parts where a PECL extensions couldn't reach ...

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

On 04.01.15 04:43, Pierre Joye wrote:>
>> I agree with your sentiments about data loss, but I am reluctant to
> deviate much from the behaviour of internal functions to avoid the
> inconsistency that plagued the previous RFC.
> 
> Right, but this is what I would expect. Am I the only one?

Definitely not; since strict types would elevate such problems that's my
preference anyway.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

On 03.01.2015 05:50, Pierre Joye wrote:
> I am also not a fan of errors, exception, at least for methods, make
> much more sense. I know it is relatively easy to handle errors as
> exception but still, let do it right now.

I second this; this could be an excellent opportunity into that
direction favored by many developers here (judging by the number of
times this and related "exception" topics come up on the list) but yet
we lacked the "how to start"/"how to get it right" approach and this
could be the gradual start of the shift.

thanks for bringing this up,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

Hello Jordi,


On 02.01.2015 15:01, Jordi Boggiano wrote:
> Looking at it from an OSS maintainer perspective, introducing strict 
> hints in code would be a huge BC break as I don't know how people use my 
> code, nor if they validate/coerce their user input early or not. If I 
> suddenly declare something as int and someone used to pass '5', they get 
> an error. That would make adoption quite hard in OSS IMO if you don't 
> want to bother people.

I'd argue if your concern is so big, you just wouldn't do it ... it's up
to the author how he sees it fit and wants to use it. You could make all
your public facing methods don't use them but only use it internally
(aha, just saw someone mentioned this in another email too; weird).

> With weak typing on the other hand, I get to remove tons of @param 
> annotations which would be amazing
[...]

I hope you don't because @param should also be describing the
purpose/usage of the parameter ;-)

> It's not my call as a library author to decide 
> whether the users of the lib should cast user inputs to ints or validate 
> them or do nothing at all.

That's really interesting, because I as library author actually do
provide "how to use my library". I mean:
- I create it with my vision
- I document it
- I create the examples how to use it
- I decide what's private/protected/public, i.e. how extensible things are

Well, there's lot of "I" but that would also apply to teams and their
decision how to use it.


My want-to-be-on-the-safe-side-code currently is either riddled with
explicit casts or simple nothing; I try to keep my methods small and
that overhead could outweigh code logic sometimes which I'd consider
counterproductive.
> 
> Besides, IMO if strict typing was so desirable we would see more of the 
> String/Int classes out there, or we would see people do things like:

Well, performance; manual boxing/unboxing is IMHO not really feasible to
do with the interpreter currently (ok; gut feeling here, no benchmark).
So, yes, I would use it if the overall overhead incurred would IMHO just
not make it feasible. (sorry for repeating)

> 
> function foo($number, $string) {
>  expectNumber($number); expectString($string);
> }
> 
> That'd be a simple lib to write, it barely adds more code to your 
> functions, and you get strict typing. But I hardly see anyone do this, 
> and I would argue it's because it sounds appealing in theory but it's 
> not worth it in practice.

I'd love to to that but simply also don't want to clutter my code with
such an approach.

The current situation to me is a bit like: it bothers me, but not to the
point I'd clutter my code with an approach like you've shown (and was
tempted multiple times in the past to do ...)


Although it seems like I wrote so many "counter" argument, please don't
misinterpret. For the love of history I merely told my view and I'm
actually glad you shared yours; with this important topic for PHP,
however it ends, there can't be too many views on that matter.

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

On 02.01.15 05:36, Levi Morrison wrote:
> I don't necessarily have any more insight to provide than has already
> been done, but I do want to chime in and say that I personally favor
> strict types as Nikita Popov has been advocating.

Same from me. I support all arguments so far made by Nikita; they're
well laid out, better than I could have done it.

I think the only real world usefulness is the strict typing; however:

Building on that I also think that the weak proposal using

  function( (int) $a_number)

has it's place and could be very good for moving forward. It would give
both side of the camps their options.

But to move this forward in this line I think a new RFC would need to be
created because it's a different goal.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

Hello Andrea,

On 01.01.15 16:19, Andrea Faulds wrote:
> I think it’d be weird to have different syntaxes for scalars and non-scalars. 
> We already use the syntax the RFC proposes in the PHP manual, and I don’t 
> think anyone’s confused by it. 

I didn't meant to stay there's something wrong with the syntax, sorry if
my text was confusing! I was rather trying to point out that it does not
hint at anything but proactively tries to convert types; see below for more:

>> 2. Casting and Validation Rules
>>
>> "While this RFC merely follows PHP's existing rules for scalar
>> parameters, used by extension functions, these rules may not be familiar
>> to all readers of this RFC."
> 
> Yes and no. With the exception of hexadecimal numbers in strings, explicit 
> casts and internal functions follow the same rules for conversion. However, 
> the validation rules don’t match. Explicit casts never fail, while internal 
> functions will reject arguments that are non-scalar or don’t fit certain 
> rules.
[...]
> 
>> 3. "Non-numeric strings not accepted. Numeric strings with trailing
>> characters are accepted, but produce a notice. "
[...]

>> What's the point of continuing the code when developer asked for "int"
>> and code logic continues with "something not quite an int"?
>>
>> Doesn't that defeat the whole purpose of the use of this RFC?
[...]

> 
> I can’t say I love that behaviour either. It is, however, our existing 
> behaviour. I’d rather we be consistent with internal functions.

And as you also pointed out: those conversion rules are different from
what a plain "(int)$whatever" would do.


I completely understand the technical ratio here: internal function have
an existing argument/parsing system which is now exposed to the end
developer ("php user") here.

I argue this system is fit and works (and, err, talk BC; obviously!) for
the whole internal PHP function/method system but ..

.. does not reflect the needs and requirements of a php user/developer
because exactly of these implicit conversion rules with three different
output states (everything ok, hard type mismatch, notice on partial
conversion).

I'd also argue that scalar types in function signatures behaving
differently than object type hints is potentially a bad thing for future
of PHP and I already made my point which is the most important to me:

>> What's the point of continuing the code when developer asked for "int"
>> and code logic continues with "something not quite an int"?



Now, going on step back here (talking about me), I'm speaking up because
>my< needs are developer are different (mostly speaking about backend
code, interfaces, libraries, frameworks) but OTOH I'm not a big known
open source framework developer either ;)

I would honestly be interested what the big framework/library players
actually want/need; do they prefer this implicit scalar type conversion
system or rather have a rigid system like the current object types but
for scalars too? I think decision on this RFC should include also
"their" saying too.

It's complex because we can't force anyone to participate but I think
above all these are the most important audience here because they know
what they want and they know what their users want. I say this because
usage of object types in PHP is almost non-existent (or, there are just
too few cases) compared to the architecture of some of the
framework/library systems out there.

Hmm.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hints

[Markus Fischer]

Hello Sebastian,

On 01.01.15 09:28, Sebastian Bergmann wrote:
> Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
>> Parameter type hints for PHP’s scalar types
> 
>  Please use the term "type declaration for arguments" (or "type
>  declaration for parameters") instead of "type hints". If it's used
>  then it's not a hint.

Thanks for bringing this up.

Interestingly, from the RFC I had another issue with it: what it
technically does it neither "hinting" nor "declaration" but it tries
conversion and seem to have multiple action how it may continue:
- continue, everything as expected
- catchable error
- notices thrown

To Andrea:

As much as I'd like to see such a language feature like this, I think:

1. the naming of the RFC thus the intent is confusing

What it really does is it tries its best to convert, e.g. the RFC reads
as it tries to work like this:

function foo(int $bar) {
  $bar = (int)$bar;
}

>From your description I understand that, technically, it doesn't do that
exactly; I was merely trying to make a point how it "looks it works";
see my next point.


2. Casting and Validation Rules

"While this RFC merely follows PHP's existing rules for scalar
parameters, used by extension functions, these rules may not be familiar
to all readers of this RFC."

Very good job in pointing this out! Which brings me to this question:
are these different rules than the general casting rules (as I exampled
above) ? If yes, wouldn't this increase the burden on PHP developers
even more to learn new rules (and, those rules are already to many to
sanely remember).


3. "Non-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice. "

That behavior, IMHO, is very bad for this kind of feature.

What's the point of continuing the code when developer asked for "int"
and code logic continues with "something not quite an int"?

Doesn't that defeat the whole purpose of the use of this RFC?

I know that this can be fixed using an error handler, throwing an
exception to abort code execution but that should really be an error
anyway, IMHO, on par with a gross mismatch of types.


I'm not in favor of these soft rules.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

[Markus Fischer]

On 16.12.14 09:34, Stanislav Malyshev wrote:
> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey

Am I right this only covers the transformation into the array. Once it's
in it's essential a array compatible key entity (string/integer) so when
you var_dump($array) you only get the values of a hash.

In other words: it would not be possible to actually get the object from
the key, just this string/integer which is supposed to reference it?

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE][RFC] Unicode Codepoint Escape Syntax

[Markus Fischer]

On 09.12.14 00:51, Andrea Faulds wrote:
> Good evening,
> 
> I’m opening voting on the Unicode Codepoint Escape Syntax RFC. There’s been 
> some discussion in the last two weeks since I introduced the RFC, but there’s 
> nothing left which I feel needs changing. For the character name syntax 
> suggestion (i.e. something like \N{arabic letter alef}), if that’s desired, 
> it could be done later in a different RFC.
> 
> Please read through the RFC and cast your vote if you wish to do so:
> 
> https://wiki.php.net/rfc/unicode_escape
> 
> Voting starts today (2014-12-08) and ends in 10 days’ time (2014-12-18).

The RFC is really a good writeup, very much appreciated.

I've voted no because I'm not entirely convinced the current approach
suits PHP long-term. I absolutely appreciate the hard work going into
it, no doubt, and I rather have a solution yesterday than tomorrow.

But I think a proper Unicode implementation in PHP must not rely on
puzzle pieces put together without a clear goal where's we're overall
heading.

I know that the latter has been tried and failed (multiple times) but
that's how I feel about the situation.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

[Markus Fischer]

On 24.11.14 23:09, Andrea Faulds wrote:
> Good evening,
> 
> Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape

I think the choice of \u{xx} is interesting, i.e. using '{' and '}'.

Afaik, one of the current best practices is to use json_decode(), like so:

$ cat test.php
http://www.php.net/unsub.php

Re: [PHP-DEV] Reflection-API

[Markus Fischer]

Hi Chris,

On 20.10.14 12:10, Chris Wright wrote:
[...] in depth summary of future idea ReflectionType

Thanks a lot for the clarification and regarding the future expansion of
the use of ReflectionType I now better understand most points and why
they're currently are that way.

I don't think I've anything more of value to add (except thanks to the
hard work to all) but I guess I would prefer to see my point 5) being
addressed.

thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Reflection-API (was: Re: [PHP-DEV] RFC: Return Types Update)

[Markus Fischer]

On 16.10.14 06:39, Levi Morrison wrote:
>   - The design and accompanying section of reflection[3] has been
> rewritten entirely.
> 
>   [3]: https://wiki.php.net/rfc/returntypehinting#reflection

I've some comments about the Reflection API addition/changes:

1. > "Note that getReturnType will always return a ReflectionType
object, even if there is no return type declared."

That feels weird, TBH. Other parts of the Reflection-API don't do that,
they simply return false if I would call e.g. getParentClass() when
there's none.


2. > "This API was designed so you could use ReflectionType::getKind()
in a switch statement to cover all cases, rather than be forced to use
an if/else structure that calls isArray(), isCallable, etc like the
ReflectionParameter API does."

I don't like the deviation from the existing Reflection API. I'm not
saying it's perfect, but I fear a "haystack,needle vs. needle,haystack"
thing here and would prefer the existing convention for is*() methods.

I wouldn't see a conflict it providing both as I see the usefulness.


3. The new class is called "ReflectionType", shouldn't it be
"ReflectionReturnType" ?


4. Other reflection classes, e.g. ReflectionParameter provides "missing
link" methods, specifically I'm missing:

public ReflectionClass getDeclaringClass ( void );
public ReflectionFunctionAbstract getDeclaringFunction ( void );


5. I think, also like in ReflectionParameter, there should a direct
shortcut to the class, if provided (and not just the string name):

public ReflectionClass getClass ( void );


thanks,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Exceptions in the engine

[Markus Fischer]

On 07.10.2014 14:15, Ferenc Kovacs wrote:
> yes, this was also suggested before, but that will be also a BC break for
> those people already using the name of the new parent class (
> https://github.com/search?l=php&q=EngineException&type=Code&utf8=%E2%9C%93
> for example).
> which can be still an ok decision, I'm just stating/repeating the pro/cons
> as this was all discussed before.

It should be considered that most of the results of this links are using
namespaces, the minority doesn't. And those ask for trouble anyway,
IMHO, if they don't use any kind of namespacing (be it old PEAR
conventions or using real namespaces).

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency

[Markus Fischer]

On 25.09.14 09:42, Dmitry Stogov wrote:
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency

Voted +1 for disabling.

I think string handling needs more thorough designing and planning for
edge case and such; i.e. the string handling alternative seems to rushed
to me thus I err on the cautious side.

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure

[Markus Fischer]

Hello Dmitry,

On 20.08.2014 12:08, Dmitry Stogov wrote:
> To have a robust way to detect resource leaks I propose a new
> function -
> get_resources() that returns an array of all registered resources or
> an
> array of registered resources of particular type. See patch:
>
> https://gist.github.com/dstogov/f96c04f5979e726909ab

my only concern would be the naming? Is there a policy for introducing
new global symbols in PHP? Looking at "get_resources" it doesn't look
far way from "get_header" or similar related stuff.

A quick search on github should only some very very few results so it's
probably statistically irrelevant. I was just wondering in general how
introducing global symbols without documented patterns (like __...
methods) works?

thank you,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] '

[Markus Fischer]

On 06.03.2012 00:08, Lester Caine wrote:

The ISP hosting these sites has not got back to me yet, but it would
seem that when they updated from 5.3.9 to 5.3.10 they also switched off
short_open_tag when previously it had been on.


I've learned it also the hard way the ISPs or Hosters did change INI 
settings. I've started to document their INIs for every new version and 
compare them immediately once they upgraded to spot the differences. 
Worked well for me (as long as I had to be dependent on such companies), 
YMMV.


- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scary note for gettype() in docs

[Markus Fischer]

On 01.03.2010 21:35, Stan Vassilev wrote:
> The gettype() documentation warns people that the returned string is "subject 
> to change". Why is there a function that's subject to change in the API?

Probably because of the unicode stuff, might suddenly return "unicode"
(still true? don't know) or "binary" what was "string" before .. but
this is untested theory right now, but that's the kind of scenario they
mean here.

HTH

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Replacing errors with Exceptions

[Markus Fischer]

Hannes Magnusson wrote:
> On Thu, Jul 30, 2009 at 20:28, Joey Smith wrote:
>> However, now that it's come up, I'm wondering what the costs/risks are
>> of setting libxml_use_internal_errors() on by default?
> 
> I don't think thats a good idea.
> People are used to getting a warning when stuff fails, and suppressing
> them all of the sudden is not cool and people will waste a good chunk
> of time figuring out what is wrong with the script they are developing
> and eventually find out libxml_use_internal_errors() is enabled by
> default and they'll start flaming the list about how much we all suck.

Observing the thread, I totally agree to that. In my case I've "been
there, done that" and although I flamed at the beginning why I can't
catch the error properly (until I found the said function :) ), you can
bring the counter example too: give no libxml_use_internal_errors() and
throwing an exception instead, you don't have to worry about some
special function to flip error handling. You just know how to cope with
Exceptions, not some esoteric function to be called to get some
information out.

- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Replacing errors with Exceptions

[Markus Fischer]

Hello,

u...@domain.invalid wrote:
> I published a (work in progress) RFC today about replacing certain
> errors with exceptions. I know that there already was something similiar
> on the php6dev blog, but this is not completly the same, so awating your
> comments:
> 
> http://wiki.php.net/rfc/errors_as_exceptions

One of the headlines reads "Proposal and Patch", but I can't find the patch?

regards,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ini value of On = 1 and Off = "" ? (Re: [PHP-DEV] RFC for new INI's)

[Markus Fischer]

Sorry to hijack, but ...

Christopher Jones wrote:
> oci8.events and oci8.old_oci_close_semantics are boolean, so we can
> take this opportunity to change the 1 and 0 to On and Off.

... I've never understood why writing On/Off is a good idea, when it is
not intuitive that the value returned from ini_get() is of a different
content (not meaning, however).

Or has this changed in more recent versions?

mar...@dev01:~$ php -dregister_globals=Off -r
'var_dump(ini_get("register_globals"));'
string(0) ""
mar...@dev01:~$ php -dregister_globals=On -r
'var_dump(ini_get("register_globals"));'
string(1) "1"
mar...@dev01:~$ php -dregister_globals=0 -r
'var_dump(ini_get("register_globals"));'
string(1) "0"
mar...@dev01:~$ php -dregister_globals=1 -r
'var_dump(ini_get("register_globals"));'
string(1) "1"
mar...@dev01:~$ php -v
PHP 5.2.5-3+lenny1 with Suhosin-Patch 0.9.6.2 (cli) (built: May 27 2008
21:47:08)

regards,
- Markus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php