On 13-03-2024 17:06, Remi Collet wrote:
I think padding should be optional (on by default to keep BC)
Of course in user land, simple to write
$enc = trim(base64_encode('foo'), '=');
This proposal allow to simply use
$enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
And also expose
On 14-02-2024 19:47, Sara Golemon wrote:
Good afternoon folks, I'd like to open discussion on adding OOP APIs to the
cURL extension.
https://wiki.php.net/rfc/curl-oop
This has been a long standing bug-bear of mine, and I think its time has
come.
try {
(new \CurlHandle)->setOpt(YOUR_VOTE,
On 23-10-2023 22:07, Jordan LeDoux wrote:
I don't quite follow. The interface would cause the engine to use the
result of an `equals()` function on the object if it implements an
interface as part of `zend_compare`? Internally there is no `==` function,
there is only the equivalent of `<=>`. To
On 23-10-2023 18:34, Larry Garfield wrote:
Jordan's RFC explained in detail why interfaces are not viable, which is why we
have to use magic methods (with or without a special keyword) instead:
https://wiki.php.net/rfc/user_defined_operator_overloads#why_not_interfaces
(Seriously, it has an
On 18-10-2023 14:50, someniatko wrote:
This approach allows combining
- no BC break - `~=` is a new syntax which is unavailable in older PHP
versions
- explicitly showing an intent that objects are compared using a custom
comparison, rather than standard PHP one
- allow to skip writing
On 08-05-2023 23:38, Larry Garfield wrote:
Ilija Tovilo and I would like to offer another RFC for your consideration.
It's been a while in coming, and we've evolved the design quite a bit just in
the last week so if you saw an earlier draft of it in the past few months, I
would encourage
TypeError | TypeError | coerced
internal | 0 | coerced| Deprecated | coerced
Is this correct?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ome a lot easier to
write "internal" functions in PHP rather than C. Not only will that make
developing the standard library easier, it may also make the optimizer
and JIT compiler more effective. The more consistency the better.
Approaches 2 and 3 from the RFC are a step in the right direc
:
$a = [...$b];
Perhaps these oddities / inconsistencies are good candidates for
addressing in PHP 9.0?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
this creative use of operator
overloading in the current RFC. It may however be useful to consider if
this use case could be supported by a future RFC in a backward
compatible way. Perhaps the RFC could mention it as a possible future
extension.
Kind regards,
Dik Takken
--
PHP Internals - PHP R
ession, which
gets passed to the filter() method.
So basically, this would allow for writing expressions in plain PHP and
have them translated into other languages under the hood.
The use case does require that operator overloads are allowed to return
any kind of value they wish.
Regards,
Dik
work authors.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
in
which it is used. Elevating some user input to the same level of
security as literals is not ideal.
On the other hand, as Craig pointed out to me (thanks!), a feature that
is too much of a hassle to use may not be widely adopted and the goal of
the proposal (improving security) may not be met.
Regar
nt on the name ‘is_hard_coded’, if we allow integers,
> that means that it’s no longer strictly hard coded, and might get confusing.
>
Ah, I was assuming that you were still strictly referring to integer
literals, not variables containing integers. Then indeed the name would
be confus
`is_constrained()`, as
> the value has limited sources. But I'd also welcome more suggestions, and
> am happy to set up a poll (thanks Dharman for the strawpoll.com suggestion).
Throwing in another idea: is_hard_coded().
> I've also updated the RFC Future Scope to note how this could be a
>
ew type match the name of the function that checks for
it. In case the existing 'string' type would be paired with a new
'lstring' type the existing is_string() would pair nicely with a new
is_lstring() function.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
dural APIs where it makes sense sounds like a great
step into the right direction. Historical oddities in the OO APIs could
be dealt with later.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
base class basically contains default
implementations of magic methods like __init__().
So the use of "new" in initializers would require extending this base
class and call the parent constructor. Maybe forgetting to do so could
throw, preventing initializers from silently not working.
e a huge win for the engine and the language long-term.
Would killing it imply that the following example from the RFC:
$test->prop[] = 42;
behaves differently depending on 'prop' being either a regular class
property or a property with associated get accessor?
Regards,
Dik Takken
--
PHP
in general.
The complexity may very well be worth it when fully considering the
impact it could have on how the language is used.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ce would be to have a separate commit method or a method
parameter to explicitly allow committing without an active transaction.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
orator. While this is not nice, it is expected because a Python
decorator actually replaces the original function at run time. A PHP
implementation would probably not do that, so maybe it could actually
work like in scenario 2?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailin
e the __repr() method would be confusing. So I would
like to suggest not to use that name.
As the intent of the resulting string is to obtain PHP code that will
construct the variable, another option might be: var_constructor().
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailin
languages, how they set up their sandbox environments.
> If we need hosting for that, I work for a hosting company and we're happy to
> help.
I think we all highly appreciate that offer.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
h the exact PHP version and configuration that
can run it reliably.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
us
more time to think this through in stead of deciding in a hurry.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 29-09-2020 14:17, Remi Collet wrote:
> I think parameter names (public API) still can change in next RC
> as named parameters are not yet widely used.
How about warning promotions? My own impression is that we are 99% there
but not quite 100%.
Regards,
Dik Takken
--
PHP Internals
hidden variable
in stead of the programmer explicitly creating a visible one.
Ok, now just say "That's nonsense" and I will shut up. :)
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
use cases: foreach, destructuring and function parameters.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
analysis tools, which helps us catch more bugs
earlier.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 02-09-2020 21:31, Dik Takken wrote:
> Even if we decide that it is not worth the trouble for foreach loops,
> there are other cases where this new syntax can work well. Array
> destructuring has already been mentioned.
Replying to myself: It just occurred to me that array destructurin
ion foo($arg, void) {}
This indicates that the second parameter is intentionally left unused.
Perhaps it is a good idea to generalize the RFC to the general concept
of "using void to intentionally ignore a variable". Maybe pick just one
use case for actual implementation and extend later using
we are talking about using underscore in places where a variable
name is expected, there may not be any problem at all. But we should be
aware of all cases in which ambiguous syntax could emerge and identify
any issues. So thanks a lot for pointing out this possible trouble maker!
Regards,
Dik Tak
efer '_' over 'void' because of consistency with other
languages. However, we should also consider that:
1. It is currently a valid constant name (BC break)
2. It might be ambiguous in some contexts in which we may want to use it
in the future. We should carefully consider other possible use cases
lik
use a comprehension
here. Maybe the following will be possible in PHP at some point:
any(foreach $itemMap as $enabled => $itemId yield $enabled &&
meetsAdditionalCondition($itemId))
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nctions gradually
replace the good old array functions in the future. When that happens, I
would rather not have the iter_ prefixes.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
the
general problem of lacking iterable support in PHP. Perhaps that could
be the subject of a followup RFC.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 22-07-2020 18:51, Derick Rethans wrote:
> This is something that STV is specifically designed to solve. You rank
> in order by preference. And @@, <<>>, and #[] were all three options.
>
> In your example, these people would have marked @@ as first, <<>> as
> second, and #[] as third.
Ah,
; >> the result could turn out differently. The
only way to know is to take another vote.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
://github.com/php/php-src/pull/5867
Please have a look.
Thanks,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 05-07-2020 09:35, Michał Marcin Brzuchalski wrote:
> The proposal is to allow two statements to skip parentheses so they don't
> look like expressions.
I like small improvements like this one. They may not look like much but
they do add up to arrive at a cleaner language in the long run.
sing the existing mechanism of declaring the accessor
method as protected or private.
So perhaps an attribute-based approach provides a nice alternative path
for gradually improving object ergonomics.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
d be a major step. It could be
extended in subsequent 8.x releases.
We should not hijack this thread to discuss this though. Larry, since
you got this started again, I guess the honor is yours to write an
opening post and start a new thread? ;)
Regards,
Dik Takken
--
PHP Internals - PHP Run
ase
> of "write-once" properties.
Indeed. For that purpose I would prefer a keyword for marking a public
property as read-only.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
would be that an 'enclosure' construct along the lines of
array_map({i18n_translate}, $array)
array_map({$object->method}, $array)
has better chances of succeeding but you never know what happens.
Perhaps you could team up with Michał and use the feedback from this
thread to produce an RFC.
Reg
these would need to become reserved class constant names
just like 'class'. Otherwise foo::fn or foo::function is ambiguous when
both a function and a class named 'foo' are in scope.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:/
me before: Seeing the scope resolution
operator being used on something that is not a class or object looks
strange to me. Especially given the resemblance with the built-in
'class' constant that classes have, this looks like functions being used
as if they are classes...
Regards,
Dik Takken
--
refer getting rid of these awkward array constructs altogether
though and just write $synonymSuggester->analyze in stead. This requires
a context that only accepts methods, which is what $() or {} could provide.
As a side note, I would love to have a name for these closure producing
constructs we are talking about. Maybe: 'enclosure'?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nfusing in my opinion, the two class constants are
too similar. I would rather prefer:
foo::function — Returns name of function
foo::closure — Returns closure for function
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
h almost identical name
(https://wiki.php.net/rfc/short_closures). Has it not been discussed before?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11-02-2020 20:20, Dan Ackroyd wrote:
> On Tue, 11 Feb 2020 at 19:08, Dik Takken wrote:
>
>> $($obj->Fot);
>> However, wrapped inside $(), which only accepts
>> functions and methods
>
> I don't think I meant that. I think it still should accept varia
to reference function names; it's really ugly
to do functional code in PHP otherwise, or even just dynamic function
logic within a namespace. If I never have to write $fn = __NAMESPACE__
. '\a_func' again, it will be too soon. :-)
Perhaps Larry can convince us all to go for something like $() by
pos
then, deprecations warnings and notices can be accumulated in 7.5
as part of the PHP 8 development process. RFCs that target PHP 8 can
include changes to 7.5 to sketch a viable migration path.
Thoughts?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
g about sequential request
handling in a single shared memory environment.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nd is available in the next.
This would allow retaining the current shared-nothing architecture while
offering the means to break the rules in a well defined way.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ame type, but NOT $this.
> So, a promise that we really get a new object which we can modify without
> changing the original object.
>
> I don't know how we would express this. Perhaps ": clone", but this would
> be too specific imo, because whether it is a clone is an implementation
> detail.
Maybe ": new" ?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e architecture related things.
I would have expected that much - if not all - of the output of
phpinfo() would be included in the hash for example. Better be safe than
sorry. Would that be a sane thing to do? Are there any reasons why this
is currently not done?
Thanks,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
minary results when you're ready to share them.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think we can expect the
cost to decrease while the gain increases. Or am I too optimistic here?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 30-10-19 22:22, Mark Randall wrote:
> I don't know if this post has been accidentally sitting in an outbox for
> a bit too long and has just sent, but the vote has been underway for a
> while now.
Thanks, I simply missed that. :)
--
PHP Internals - PHP Runtime Development Mailing List
To
a little before starting the vote to
show the cost going down as more optimization work is done. Just to
build confidence with those who are hesitant to give it their approval.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Type checking opcodes are actually removed by opcache when its
static analysis can prove that the type check will always pass. It has
some limitations but the functionality is all there.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n by using the following inspection hint:
/* @noinspection PhpUnhandledExceptionInspection */
Since exceptions should mostly be used for situations where it is best
to run for the emergency exit, wrapping a function call in a try / catch
is not expected to be something done frequently.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that wraps any function
calls that need it in a try() to retain old behavior. Backporting try()
to PHP 5.x would allow the same code to run on both PHP 5 and 8.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
parison. Still, my code is not
cluttered with exception handling.
So, converting a ton of warnings to exceptions in PHP does not worry me
at all. I would welcome it, but not as a bulk operation. I agree that we
need to ask the question for each case. I would still prefer the answers
to bias towards
functions that are expected to cause bigger BC issues which could be
fixed using an automatic fixer. Yet another RFC for functions that would
require manual fixing of BC issues. Some of these functions might
require an RFC of their own. A step at a time.
Regards,
Dik Takken
--
PHP Internals - PH
On 15-09-19 22:53, Gabriel Caruso wrote:
>
>
> The main problem with Docker and php-src is that we need to touch the OS in
> order to make sure the new features and bugfixes will be compatible.
>
> Docker create a layer on top of that, right?
>
Correct. Honestly I was not considering the use
on Github and Docker Hub. This image could even have the
command to run the tests baked into the image itself. Then, anyone can
just run
docker run php-tests:7.4
to build the sources and run the tests. For development you can mount
your local git clone in the container.
Regards,
Dik Takken
ody is working on yet and I will see what I can do.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I'd be happy to donate some time to this effort as well. If you just
assign me a file or directory (not too much at once please) I can create
a PR that covers that part of the code base.
Would that work for you?
Regards,
Dik
On 10-08-19 12:56, Nikita Popov wrote:
> Hi,
>
> Lack of type
used in regular text, IHMO. The PHP standard
library already has a number of methods that are named that way, like
str_word_count(). So, I would favor to have str_starts_with().
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e switch
statement: Array keys are compared using the === operator.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
argue that it is a case of implicit use of an operator.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23-05-19 21:18, Nikita Popov wrote:
> On Thu, May 23, 2019 at 9:02 PM Dik Takken wrote:
>
>> For array_intersect(), I was actually considering to allow zero
>> arguments. The use case I have in mind is to determine the common
>> elements in a set of z
in PHP 8
3. Allow passing zero arrays to array_map() in PHP 8
Do these changes require an RFC?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21-05-19 10:29, Nikita Popov wrote:
> This one makes sense in theory, because array_map(null, ...$arrays) is a
> way to perform a zip operation in PHP. Unfortunately there is an ugly
> special case if there is only a single array, which makes this not actually
> usable in practice, unless you
On 17-05-19 22:52, G. P. B. wrote:
>
> So as a side note aren't there maybe some other array functions which
> behave like this?
>
Good point. I did a quick scan of the source code and came up with a
list of possible candidates for a similar treatment:
array_map()
array_diff() & friends
to proceed.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21-03-19 16:22, Larry Garfield wrote:
> OTOH, if we just have the one syntax:
>
> [foreach $foo as $bar yield $bar*2] // gives a generator
>
> And include a nicer "fast-forward" operator than interator_to_array(), then
> we automatically get:
>
> ...[foreach $foo as $bar yield $bar*2] //
as $user) yield $user->firstName])
Just thinking out loud here...
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ns fit in anywhere.
Then there are the cases where you want to access the output of the
comprehension multiple times. This may be expensive when a comprehension
is a generator.
So I still think that using a comprehension to create an array isn't an
off chance but a common use case.
Regards,
Dik Takken
--
P
r it's not always easy to quickly figure out which
> part belongs where. Delimiting it would make it easier IMHO, and also
> allows again to carry over the intuition of how foreach() and if() work
> from already known constructs.
Only, the intuition of how "foreach" and "if" works does not fully apply
due to the limited syntax of comprehensions. For example, you can't pair
the "if" with an "else" in the current proposal. Maybe that could be
supported as well, but that is not my point. If comprehensions start
looking like familiar foreach loops but do not work the same way, would
that not be confusing?
Kind regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
82 matches
Mail list logo
