ch information about this change (even finding about
|clear_env| is not that easy when search for "php fpm env var") so I
don't know if there is others reason than BC.
thank you
--
Mathieu Rochette
On 04/23/2015 05:11 PM, Dan Ackroyd wrote:
On 23 April 2015 at 12:13, Mathieu Rochette wrote:
I didn't find much information about this change (even finding about
|clear_env| is not that easy when search for "php fpm env var") so I don't
know if there is others reaso
efault behavior with apache mod_php, anyone can
think about security issues that could cause ?
On 04/23/2015 10:07 PM, Mathieu Rochette wrote:
On 04/23/2015 05:11 PM, Dan Ackroyd wrote:
On 23 April 2015 at 12:13, Mathieu Rochette wrote:
I didn't find much information about this change
hi,
On 16/11/2015 10:33, Lorenzo Fontana wrote:
I really like the concept of immutability, but I think that it should be
applicable at instance level rather than declaration.
I'm not sure about that, most PHP code assume mutable objects, I doubt
much existing classes would be usable as immutab
ake sure I didn't screw that
up", that would be lovely but sounds hard. :-)
--
Mathieu Rochette
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17/11/2015 13:26, Lester Caine wrote:
On 17/11/15 11:04, Rowan Collins wrote:
If you look at the PSR-7 implementation I linked to earlier [1], there's
no such boilerplate, just a single call to "clone $this", and PHP does
it all for you. But that doesn't work with a simplistic definition of
re expectations for most of
>> the
>>>> proposed language features:
>>>>
>>>>
>> https://github.com/orolyn/php-src/tree/generics-tests/Zend/tests/generics
>>>> We look forward to your comments, questions and (I'm sure) criticisms of
>>>> this proposal!
>>>>
>>>> Thank You,
>>>>
>>>> Regards,
>>>>Rasmus Schultz
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>> Nice work.
>>>
>>> I think you there's a typo in one of your examples:
>>>
>>> write(new Entry(1, 2)); // throws a TypeError
>>>
>>> Presumably this should be or something similar?
>> Ignore me, I didn't read the example properly.
>>
--
Mathieu Rochette
On 20/04/2016 00:22, Sara Golemon wrote:
On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote:
about the upper bounds, have you consider another way of describing the
constraints, eg:
class Box where T is Boxable
this would allow multiple constraints, eg:
class Collection where T is
gt; Aside from these top issues on our own list, however does everyone feel
> about the proposal in general?
> As the RFC is still in draft, we will continue to make changes to it as
> more popular idea pop up, so please continue.
>
> Thanks.
>
> PS: I wasn't properly subscribed to the mailing list, so I missed a few
> important messages that were mailed directly to internals, but hopefully
> I've managed to fix that now.
>
--
Mathieu Rochette
On 04/23/2016 08:34 PM, Marcio Almada wrote:
> hi!
>
> From: Mathieu Rochette
>> Date: 2016-04-23 12:44 GMT-04:00
>> Subject: Re: [PHP-DEV][RFC] Callable Types
>>
>>
>> On 04/22/2016 06:12 AM, Marcio Almada wrote:
>>
>> Hello everyone,
>&g
you my list"
>
> And inside the function:
>
> $list->add(3.1415);
> // "To the list of Numbers you gave me, I will add the Double 3.1415"
> // "Yay, it worked. :)"
>
>
> Contravariance always seems counterintuitive, but it turns out it
> really is the appropriate constraint in certain situations.
indeed, thank you for this very detailed explanation.
can this also be useful/makes sense for declaring a class? (eg: class
List {}) maybe an abstract class ? or is it just for
parameters ?
>
> Regards,
--
Mathieu Rochette
r '?' anywhere. function that already
accepts
null arguments (either because it's untyped or because there is '=
null') will
continue to accept without any changes
adding '?' will make the function more permissive. not adding it will
not make
any existing function more restrictive
>
--
Mathieu Rochette
tions()? Every time?
given they are context free, I suppose they would be executed on the
first call only
but what about this kind of annotation classes? :
class Counter {
private static $i = 0;
private $n;
function __construct() {
$this->n = self::$i++;
}
function get() { return $this->n; }
}
both the getAnnotations() calls order and whether or not annotations are
executed every time would make a difference
>
> Thanks,
>
--
Mathieu Rochette
Hi,
it's nice to see this going on again :)
while reading the rfc I was wondering, why do we need the "static" keyword,
couldn't static function be detected automatically ?
I guess this apply to the existing closure syntax as well so to get more on
this topic I'll share my preferences on th
Hi,
I’m writing a message here to receive feedback on a two ideas related to
class constructors before going more in details with an RFC. I hope this is
appropriate behavior for this list
With the Constructor Property Promotion accepted in PHP 8, there’s a lot
less of boilerplate when writi
"Lokrain" lokr...@gmail.com – August 17, 2020 7:14 PM
>
>
> On Mon, 17 Aug 2020 at 19:46, Mathieu Rochette
> wrote:
>
>
>> Hi,
>>
>>
>>
>> I’m writing a message here to receive feedback on a two ideas related
to
>> cla
$c1) {
// Implicit: parent::__construct($x, $y);
}
}
On Mon, 17 Aug 2020 at 18:46, Mathieu Rochette
wrote:
Hi,
I’m writing a message here to receive feedback on a two ideas
related to
class constructors before going more in details with an RFC. I
On 8/17/20 7:14 PM, Lokrain wrote:
On Mon, 17 Aug 2020 at 19:46, Mathieu Rochette
wrote:
Hi,
I’m writing a message here to receive feedback on a two ideas
related to
class constructors before going more in details with an RFC. I
hope this is
appropriate behavior
On 20/07/2016 21:55, Michael Vostrikov wrote:
escapeHtml($value); ?>
I don't see what is hard in using that syntax, plus it's not a global
registry.
if people aren't using templating and haven't written any of their own
wrappers to sanitize the output
They HAVE own wrappers. The problem is
On 22/07/2016 16:54, Michael Vostrikov wrote:
The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing
I might as well just write "function e($string, $mode='html') { }"
they will already have a method of doing this
Ye
Note that what is defined in the RFC currently is *not* similar to
> Twig/Smarty, because it views the parsing of the | as *internal* to
> the callback, not part of the escaping syntax itself. It allows you to
> define an escape callback that instead uses "," as the separator,
st cases cover the most stuff but not everything and could be
> extended. There are other things with the PR but I will check it out and
> create a PR against your branch with that so you can review it. (Might
> take a while so bare with me.)
>
> The RFC contains several g
thank you for the clarification, more questions inline :)
On 09/02/2016 04:23 AM, Michał Brzuchalski wrote:
> Firstly, thanks for your interest.
> My answers are inline.
>
> 2016-09-01 23:48 GMT+02:00 Mathieu Rochette :
>
>>
>> On 09/01/2016 09:12 PM, Fleshgrinder wro
On 07/09/2016 11:33, Lester Caine wrote:
On 07/09/16 09:10, Ferenc Kovacs wrote:
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addre
On 07/09/2016 11:28, Silvio Marijić wrote:
Hi Stephen,
Cloning is disabled at the moment in implementation because you would end
up with a object that you can not change, so you have no use of that. I'll
change that as soon as we find some good solution for handling that. Your
example is not r
On 07/09/2016 11:05, Stephen Reay wrote:
(Sorry for any dupes, sent from wrong address originally)
From a developer point of view, I would suggest that a feature should aim to be as
clear to understand with as little “magic" as possible.
If the goal of an immutable class is to allow public
a few remarks on mutator methods:
* It could be a nice way to solve the "create another one almost the
same" use case.
* I don't mind if $clone is an explicit parameter or magically available
* what happens if I call other function/methods with this $clone
before the end of the function
r the hood.
I don't know, it seems a bit strange to override $this . I can't have
the original object and the new one at the same time.
Or do you mean I also have the option to do "$clone = clone $this" ?
2016-09-07 14:53 GMT+02:00 Mathieu Rochette <mailto:math...@rochette.
On 08/09/2016 10:05, Tony Marston wrote:
"Pierre Joye" wrote in message
news:caezptu4twuap1xjx+z_n+sgj1ujptyn8pj5xuvmjei2dke0...@mail.gmail.com...
hi Tony,
On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston
wrote:
"Pierre Joye" wrote in message
news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=n1rjmspofm
On 09/09/2016 11:01, Tony Marston wrote:
Sent: Friday, September 09, 2016 12:55 AM
To: Tony Marston ; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle
Hi!
There should be a rule that nothing can be deprecated unless there is a
viable, st
should be forced to provide a viable alternative first. Otherwise they would
> be just like those stupid politicians who try to force commuters out of their
> private cars and into public transport without realising that the existing
> public transport system is NOT a viable replacement and is incapable of
> taking on the extra load.
again, nobody is trying killing PEAR/PECL. do we need to use strong
terms to make that clear ?
>
> --
> Tony Marston
>
--
Mathieu Rochette
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think that matters. Developers use PHP because they generally *don’t*
>> have to worry about the internal details of the engine.
>>
>> e.g.:
>> $d = new DateTimeImmutable();
>> $e = $d->add(new DateInterval('PT0S'));
>>
>> var_dump($d === $e);
Sent from my Alcatel Onetouch Idol 3 (4.7)
On Sep 14, 2016 7:08 PM, Fleshgrinder wrote:
>
> On 9/13/2016 11:38 PM, Mathieu Rochette wrote:
> > I agree that blocking clone seems unnecessary. I also don't see why it
> > is useful to have "clone" methods. Wh
On 20/11/2016 20:25, Rasmus Schultz wrote:
Reading through the RFC and the replies, I'm confused about this question.
Why would the comparison operators work any differently on immutable
objects?
If these were value objects, the question would make sense, but it doesn't
sound like that's what
ming this was intended for the list...
it was, thank you
>>
>> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
>>
>>> Currently the only "unlocked context" for an object is its
>>> constructor. As discussed previously, that is insufficient. For any
>
Hello internals,
I find that using the decorator pattern is very verbose and maybe
something could be done about that,
an article[1] I saw proposed a "decorates" keyword to solves this, here
is how it might look like in PHP:
interface Foo {
public bar();
public taz();
}
class EchoFooBar
On 29/12/2016 14:44, Alexander Lisachenko wrote:
2016-12-29 16:12 GMT+03:00 Mathieu Rochette <mailto:math...@rochette.cc>>:
I find that using the decorator pattern is very verbose and maybe
something could be done about that,
an article[1] I saw proposed a "decorat
On 29/12/2016 14:18, Marco Pivetta wrote:
On Thu, Dec 29, 2016 at 2:12 PM, Mathieu Rochette <mailto:math...@rochette.cc>> wrote:
Hello internals,
I find that using the decorator pattern is very verbose and maybe
something could be done about that,
an article
Sara Golemon – Thu, 14. June 2018 16:50
> On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov wrote:
> > I like the general idea here (switch with strict type comparison), but not
> > super fond of the particular syntax and implementation.
> >
> No arguments there. What's presented is "best I could
it though is that it may break automatic filtering rules of
people matching exactly `List-Id: internals.lists.php.net`.``
regards,
Mathieu Rochette
publickey - mathieu@rochette.cc - 0x8D30BA0E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
On Thursday, July 31st, 2025 at 18:13, Derick Rethans wrote:
> Hi Mathieu,
>
> Questions around this, are probably better directed at syst...@php.net,
> but it's here now, so I'll answer.
noted.
>
> On Thu, 31 Jul 2025,
>
> Mathieu Rochette
>
41 matches
Mail list logo
