> > Not sure about specific use cases, for me the important aspect here is to
> > avoid arbitrary restrictions. For example, define() accepts resources,
> and
> > this is used for some core constants like STDIN, STDOUT, STDERR.
> >
>
> Per the documentation [1], defining resource constants is suppo
>
> Not sure about specific use cases, for me the important aspect here is to
> avoid arbitrary restrictions. For example, define() accepts resources, and
> this is used for some core constants like STDIN, STDOUT, STDERR.
>
Per the documentation [1], defining resource constants is supposed to
On Mon, Jun 14, 2021 at 7:47 PM Larry Garfield
wrote:
> On Mon, Jun 14, 2021, at 9:35 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > With the introduction of enums, it's now possible for constants to hold
> > objects. However, this works only when using the `const X = Y` syntax,
> not
> > when
> Le 12 juin 2021 à 19:00, Craig Francis a écrit :
> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
Hi,
I’ve found an interesting bug in the implementation:
https://3v4l.org/JfSHX/rfc#rfc.literals
—Claude
I've just added support for a `literal-string` type to Psalm:
https://psalm.dev/r/9440908f39
This will remain whether or not the RFC passes, but if it passes the
is_literal check will be used to inform Psalm in a similar fashion to how
array_is_list (coming in 8.1) will inform Psalm's list array t
Hi Craig,
> On Jun 14, 2021, at 5:36 AM, Craig Francis wrote:
>
> On Mon, 14 Jun 2021 at 09:07, Pierre wrote:
>
>> Le 14/06/2021 à 02:41, Mike Schinkel a écrit :
>>> A big*NO* on warnings. Full stop.
>>
>> [...] Any warning raised by the low level functions would be too
>> restrictive.
>
>
On Mon, Jun 14, 2021, at 9:35 AM, Nikita Popov wrote:
> Hi internals,
>
> With the introduction of enums, it's now possible for constants to hold
> objects. However, this works only when using the `const X = Y` syntax, not
> when using `define('X', Y)`, which still excludes objects.
>
> I've subm
Hi Dan,
On 14/06/2021 13:29, Dan Ackroyd wrote:
While I think the idea behind this RFC is great, the current
implementation is terrible, as it will cause some fatal errors in
production.
I think you have raised a legitimate concern here, but agree with
Matthew Brown that calling the impleme
On Mon, Jun 14, 2021 at 5:02 PM Nikita Popov wrote:
> In the future, we're going to switch these resources to be objects, so
> allowing them in constants would be necessary at that point at least.
> Actually, we already encountered this as a BC issue when switching some
> other resource types to
On Mon, 14 Jun 2021 at 11:53, Dik Takken wrote:
> That sounds like a great future extension. Then it would be nice to have
> the name of the new 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
On Mon, Jun 14, 2021 at 4:42 PM Marco Pivetta wrote:
> Hey NikiC,
>
> On Mon, Jun 14, 2021, 16:35 Nikita Popov wrote:
>
>> Hi internals,
>>
>> With the introduction of enums, it's now possible for constants to hold
>> objects. However, this works only when using the `const X = Y` syntax, not
>>
Hey NikiC,
On Mon, Jun 14, 2021, 16:35 Nikita Popov wrote:
> Hi internals,
>
> With the introduction of enums, it's now possible for constants to hold
> objects. However, this works only when using the `const X = Y` syntax, not
> when using `define('X', Y)`, which still excludes objects.
>
> I'v
Hi internals,
With the introduction of enums, it's now possible for constants to hold
objects. However, this works only when using the `const X = Y` syntax, not
when using `define('X', Y)`, which still excludes objects.
I've submitted https://github.com/php/php-src/pull/7149 to relax the
restrict
On Mon, 14 Jun 2021 at 13:30, Dan Ackroyd wrote:
> [...] it will cause some fatal errors in production.
>
No, the only way fatal errors can occur is if you choose to make them fatal
(in userland code).
I have included examples of the literal_concat() and literal_implode()
functions in the RFC,
Hey Thomas,
On Mon, Jun 14, 2021, 15:27 Thomas Nunninger wrote:
> Hi!
>
> > class UserPreferences {
> > private DB $db;
> >
> > function getColor(): string {
> > $preferredColor = $this->db->getColor();
> >
> > if ($preferredColor === 'light') {
> > retur
Hi!
class UserPreferences {
private DB $db;
function getColor(): string {
$preferredColor = $this->db->getColor();
if ($preferredColor === 'light') {
return '#fff';
}
if ($preferredColor === 'dark') {
return '#000';
On Mon, 14 Jun 2021 at 08:30, Dan Ackroyd wrote:
> Hi Craig, Joe,
>
> While I think the idea behind this RFC is great, the current
> implementation is terrible, as it will cause some fatal errors in
> production.
>
>
I'm not sure it's productive to call the implementation terrible. With
Someniatk
Hi Craig, Joe,
While I think the idea behind this RFC is great, the current
implementation is terrible, as it will cause some fatal errors in
production.
# The problem
Imagine we have this code:
function getInfoPanel(UserPreferences $up): string
{
$html = "";
$html .= // more html here
On 13-06-2021 21:46, someniatko wrote:
> Hi!
>
> From what I understood reading the RFC, this looks like a new type,
> "literal string", specifically a subtype of "string". Have you
> considered instead of forcing library authors to use `is_literal()`
> check everywhere on their input boundary and
On Mon, 14 Jun 2021 at 09:07, Pierre wrote:
> Le 14/06/2021 à 02:41, Mike Schinkel a écrit :
> > A big*NO* on warnings. Full stop.
>
> [...] Any warning raised by the low level functions would be too
> restrictive.
>
Hi Pierre, I'll be talking to Mike on Zoom later today (5pm UK time), which
y
On Mon, 14 Jun 2021 at 08:34, someniatko wrote:
> I am sure even without a dedicated type it is still a valuable addition to
> the engine [...] IMO it's okay to ship the feature without it for now.
Thanks someniatko, it's certainly something I'm interested in (8.2?), as I
think a dedicated typ
> Indeed, the current implementation appears to have several problems. So,
> how about the following implementation?
>
> ```php
> interface RandomNumberGenerator
> {
> public function generate(): int;
> }
>
> final class Random
> {
> private RandomNumberGenerator $rng;
> public function
Le 14/06/2021 à 02:41, Mike Schinkel a écrit :
A big*NO* on warnings. Full stop.
Hello,
I agree. A lot of DBAL / ORM / query builders tools exist and use the
mysqli_, pgsql_ or PDO libraries as simple arbitrary SQL executor, and
handle the security aspect at a higher level. Any warning rais
Nevertheless, I am sure even without a dedicated type it is still a
valuable addition to the engine. Just to clarify, I understand that if
this would require too much additional work to implement the type, IMO
it's okay to ship the feature without it for now. I was just replying
to other arguments,
> And I agree, there would be value in having a `literal-string` type,
> especially when working with IDE's and Static Analysers; but it brings a
> couple of issues that the is_literal() function solves:
Yeah, those are valid arguments why we should have a dedicated
`is_literal()` function, and
25 matches
Mail list logo
