[PHP-DEV] [Vote] make Reflection*#setAccessible() no-op

: https://externals.io/message/114841 Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know :D Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Proposal: clamp

Hey Kim On Wed, Jun 23, 2021, 02:25 Kim Hallberg wrote: > This function is very easy to implement, has no side effects or backward > compatibility issues, unless a userland implementation already has the > function declared, > I like the function, the name, and its simplicity. The problem is

[PHP-DEV] Re: [RFC] make Reflection*#setAccessible() no-op

Hey folks, On Sun, Jun 13, 2021 at 6:44 PM Marco Pivetta wrote: > Hey folks, > > I'm posting here to introduce a new simplification, as well as > quality-of-life-improving RFC: > > https://wiki.php.net/rfc/make-reflection-setaccessible-no-op > > The RFC is quite minima

Re: [PHP-DEV] [VOTE] ImmutableIterable (immutable, rewindable, allows any key keys)

tents of it, and there's no point in implementing them * `__set_state` should also not be implemented: `var_export()` like any other object and it should be fine * `jsonSerialize` also depends on the contents, and shouldn't be exposed All of this is not part of what should be in a reusable

Re: [PHP-DEV] Allow objects in define()

source types to objects. > Makes perfect sense, thanks! Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Allow objects in define()

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. > >

Re: [PHP-DEV] [RFC] is_literal

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') { > >

Re: [PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

Hey Larry, On Sun, Jun 13, 2021, 20:46 Larry Garfield wrote: > I'm generally OK with it. The change makes sense. > > What I'm unclear on is why it's not including the actual deprecation. Not > doing that yet and having it just become a noop first seems fine, but it's > also clear that having

[PHP-DEV] [RFC] make Reflection*#setAccessible() no-op

friendly NikiC poked me to see if this long-standing patch of mine was still relevant. Should be short/sweet, but I'm looking forward to your feedback. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Consensus Gathering: is_initialized

On Thu, May 27, 2021 at 1:29 PM Pierre wrote: > why not having it ? > More API, similar-but-not-exactly-like `ReflectionProperty#isInitialized()` Minimalims should really be valued more :D Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

ote about technical limitations at the bottom > of the repo README: > > Due to technical limitations, it is not possible to create mutable APIs > for primitive types. Modifying $self within the methods is not possible (or > rather, will have no effect, as you'd just be changing a cop

Re: [PHP-DEV] Consensus Gathering: is_initialized

nds > > However is_initialized has a narrower scope than the reflector version, as > mentioned in the PR, it specifically can only work on typed (accessible > from calling scope) properties. > Sounds weird? Why would a narrower version be needed at all? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ >

Re: [PHP-DEV] Consensus Gathering: is_initialized

tion caching works just fine (and a new API would need a lot of meaningful benchmarks to be warranted). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

icely this reads: > > $array->map($fn)->filter($fn2) > > Compared to array_filter(array_map($fn, $array), $fn2) > > I see no BC concerns here because in any previous PHP versions this is a > fatal error. I do not see any syntax ambiguity either but here I am > probably ju

Re: [PHP-DEV] Could we drop the bottom-posting rule?

And readable On Tue, May 11, 2021, 18:42 Kamil Tekiela wrote: > I completely agree with Good Guy. Top posting is just way more convenient. >

Re: [PHP-DEV] Could we drop the bottom-posting rule?

Sure, why not: email clients are decent enough to hide quoted sections anyway  Heck, even my phone can read top-posts, and the rest of the folks (reddit, mostly) use https://externals.io/ anyway 路 Feel free to call me out for top-posting this  On Mon, May 10, 2021, 23:52 Kamil Tekiela wrote:

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

more of an optimization pass for OpCache at that point. Adding AST always comes with major complexity for all the ecosystem: since there is AST isomorphic to the proposal, and it's literally one character in difference, I don't see a clear advantage. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

t finished adopting it on many of my libraries). If this is relevant to you right now, add an exclusion to your `phpcs.xml.dist` instead: easier and less painful than expanding the language for such a tiny detail. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

Hey Matīss, This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM Is the change in AST really necessary, considering that? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, May 10, 2021 at 10:29 AM Matīss Treinis wrote: > Hi everyone, > &

Re: [PHP-DEV] [RFC] Property accessors

Hey NikiC, <http://ocramius.github.com/> On Tue, May 4, 2021 at 4:21 PM Nikita Popov wrote: > On Tue, May 4, 2021 at 12:58 PM Marco Pivetta wrote: > >> Hey NikiC, >> >> On Tue, May 4, 2021, 12:34 Nikita Popov wrote: >> >>> Hi internals, &g

Re: [PHP-DEV] [RFC] Property accessors

Hey NikiC, On Tue, May 4, 2021, 12:34 Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

On Sat, Apr 24, 2021, 21:44 Olle Härstedt wrote: > 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : > >> Doesn't this violate the principle: It should be possible to add new > >> features without touching old code? > > > > This depends on which syntax is picked, both `for` and attribute syntax >

Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods

Hey Tyson, On Sat, Apr 24, 2021, 19:24 tyson andre wrote: > Hi Marco Pivetta, > > > In fact, if reflection were to switch to the actual runtime return types > of > > those methods, I don't see a reason why downstream consumers would break > > (stubbing tools, cod

Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods

ation (hence no need for a new API). Examples: * https://phpstan.org/r/530583f0-fab5-4f46-af6b-332e67b862cf * https://psalm.dev/r/7f987b25a3 In fact, a lot of tooling treats `Reflection*#isInternal()` as a huge red flag that means "here be dragons", which is more than sufficient

Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods

ies in types earlier, giving people more runway to fix their subtypes for the upcoming 9.0 change. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods

Hey Máté, On Thu, Apr 22, 2021, 09:42 Máté Kocsis wrote: > Hi Internals, > > I've just opened the vote about > https://wiki.php.net/rfc/internal_method_return_types > and I will close it on 2021-05-06. > > For prior discussion, please see https://externals.io/message/113413 Overall OK with

Re: [PHP-DEV] Unable to log in to wiki.php.net

On Mon, Apr 19, 2021, 16:56 Aleksander Machniak wrote: > I was about to log in to vote on some RFCs, but I cannot log in. I reset > the password twice, the new passwords didn't work either. > > My username is 'alec'. Could someone verify that? > Similar issues here ✋

Re: [PHP-DEV] Path forward for class_exists with different targeted PHP version implementations

Hey Jesse, On Tue, Apr 6, 2021, 03:00 Jesse Rushlow wrote: > Sure thing - > > In Symfony's MakeBundle we have a command "php bin/console make:command". > This ultimately generates a "App\Console\XyzUserlandCommand::class" that > allows the developer to customize in order to perform some task

Re: [PHP-DEV] Raising the precedence of the new operator

On Mon, Apr 5, 2021, 22:51 Marco Pivetta wrote: > > > On Mon, Apr 5, 2021, 19:42 Mike Schinkel wrote: > >> >> > On Apr 5, 2021, at 12:47 PM, Ben Ramsey wrote: >> > >> >> On Apr 5, 2021, at 11:40, André Hänsel wrote: >> >> >>

Re: [PHP-DEV] Raising the precedence of the new operator

On Mon, Apr 5, 2021, 19:42 Mike Schinkel wrote: > > > On Apr 5, 2021, at 12:47 PM, Ben Ramsey wrote: > > > >> On Apr 5, 2021, at 11:40, André Hänsel wrote: > >> > >> I was wondering... PHP is the only language I know of where you have to > >> write `(new Foo())->bar()` instead of > >> `new

Re: [PHP-DEV] [VOTE] Object scoped RNG implementation

On Fri, Apr 2, 2021, 23:56 Kamil Tekiela wrote: > Hi Go Kudo, > > First, let me say that I believe we need such implementation in PHP and I > would like to see object scoped RNG as part of the standard. However, I > have voted no for a number of reasons. Let me list them from the > perspective

Re: [PHP-DEV] [RFC] Pure intersection types

ctionType` will likely be the most interesting part of it, potentially hardcoding `ReflectionIntersectionType#allowsNull()` as `false` for now? (analogous to https://www.php.net/manual/en/class.reflectionuniontype.php ) Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

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

Hey Nikita, On Fri, Mar 19, 2021, 14:35 Nikita Popov wrote: > > Is it allowed to declare a noreturn function that returns by reference? > > function (): noreturn {} > Given that `noreturn` means it should throw, loop forever or exit, how would a by-ref usage be applied/useful? Or is it a hint

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

pe (instead of their original one), and the system is still sound from a type perspective. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] fsync function

Het Nikita, On Thu, Feb 25, 2021 at 1:04 PM Nikita Popov wrote: > > Throwing a warning in such a case is consistent with how functions for > other optional stream operations work. > I understand that, and I'm OK with being **against** it. Marco Pivetta http://twitter.com/Oc

Re: [PHP-DEV] [VOTE] fsync function

more E_WARNING raised by the language. We have better approaches for that: * exceptions * union types * Maybe/Either types I don't see a reason to introduce a warning here, and it makes the function unusable unless some poor soul implements a library that gets rid of the warning. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Inline conditional that returns null if falsy

Hey David, On Fri, Feb 12, 2021, 20:24 David Rodrigues wrote: > Hello! > > It is just a suggestion to be discussed. > > A lot of places on my projects I have codes like: > > $companies = $user->companies->count() > ? new Collection($user->companies) > : null; > Even upfront, this looks

Re: [PHP-DEV] password_verify() and unknown algos

increasing the complexity of a pre-existing symbol. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] __repr() magic method (was Re: Proposal: short_var_export($value, bool $return=false, int $flags=0))

ce, > like `Stringable`? https://wiki.php.net/rfc/stringable > Ooof, can we just avoid more magic methods overall? :| Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] #[Deprecated] Attribute

things into compile-time rather than runtime, as runtime in PHP is already quite the nightmare of things to keep in mind. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] #[Deprecated] Attribute

is easily introspectible via tools like phpstan, psalm, phan, and does not need to lead to more problematic runtime issues. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Allow object keys in arrays

Separate response for this one, sorry for the noise: On Tue, Jan 12, 2021, 17:35 Ilija Tovilo wrote: > Note that even minor PHP versions have historically not followed strict > semantic versioning. If we did, most PHP features would have to be pushed > back years given PHPs relatively slow

Re: [PHP-DEV] [RFC] Allow object keys in arrays

Hey Ilija, On Tue, Jan 12, 2021, 17:35 Ilija Tovilo wrote: > > Definitely disagree here. Your existing code will continue to work fine > without changes. > Code written to deal with `array` in a generic way will no longer work when invoked through code paths that produce object keys: this is a

Re: [PHP-DEV] [RFC] Allow object keys in arrays

Hi Nikita, On Mon, Jan 11, 2021, 15:29 Nikita Popov wrote: > Hi internals, > > I would like to present a draft RFC for allowing object keys in arrays: > https://wiki.php.net/rfc/object_keys_in_arrays > > The specification in the RFC is incomplete, and primarily focussed on what > impact this

Re: [PHP-DEV] [RFC] Bundling ext/simdjson into core

precise field testing over the next few years. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

Hey Tyson, I know I'm being stubborn, but we have namespaces, but also an "old guard" that doesn't understand its own programming language 路‍♀️ On Sat, Dec 19, 2020, 21:24 tyson andre wrote: > Hi internals, > > I've created a straw poll for the naming pattern to use for `*any()` and > `*all()`

Re: [PHP-DEV] [RFC] Short-match

bout why it should be > considered as such. > > Kind regards, > Doug Nelson > > On Mon, 14 Dec 2020 at 18:14, Marco Pivetta wrote: > >> Hey Larry, >> >> On Mon, Dec 14, 2020 at 6:34 PM Larry Garfield >> wrote: >> >> > I present to Intern

Re: [PHP-DEV] [RFC] Short-match

for these rare cases. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Strict switch

On Tue, Dec 1, 2020, 19:57 Larry Garfield wrote: > > > Disagree. switch is a procedural logic flow control. match is an > evaluation expression. Things like fallthrough do not belong there, as it > mushes expressions together in weird ways. match is lovely because its > logic flow is simple

Re: [PHP-DEV] PHP releases, OPcache + Jit bugs, and communication

be a comma separated list of things such as: > > jit - the JIT > opcache - opcache > php - the core engine with/without JIT or OPcache. > security - known security flaws that of a severity that justify an > urgent upgrade > An rss/atom feed with affected version ranges (can be added via XSD, I suppose) would be fantastic: I'd factor it into `roave/security-advisories` ASAP, if there was a way to have such a thing :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Union `&` operator

rsection types since a few years. As for when to allow them: as others have suggested in this thread, keep it simple for now, and only allow intersection of class/interface references. If you want to raise an RFC, special care has to be taken for the variance in inheritance semantics. Greets, M

Re: [PHP-DEV] [RFC] Support for ::function syntax

Hey Michael, On Sun, Nov 8, 2020 at 9:38 AM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > Hi, > > what about resolving directly to Closure? > > strtoupper::function === \Closure::fromCallable('strtoupper'). > > $this->method::function ===

Re: [PHP-DEV] Nullsafe

Hey, On Wed, Nov 4, 2020, 20:39 Eugene Sidelnyk wrote: > Yeah... Creating null was a huge mistake. > Now it is probably too late to fix that (maybe some new language can > introduce that). > > Y'all confusing Java's `null` (billion dollar mistake) with PHP's `null`. * In Java, `null|object`

Re: [PHP-DEV] Nullsafe

Heya, On Tue, Nov 3, 2020, 17:38 Eugene Sidelnyk wrote: > Hello, internals! > I am wondering why don't we use ordinary `->` operator with safe null > handling? Programmers will be more prone to return null values. And thus, > in most of cases `?->` will replace `->`. > Why do we need another

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

will need to get some RFC karma - my wiki > account is nunomaduro. > Overall, seems like unnecessary added syntax for something that already works just fine. Pros: * unclear Cons: * more scope leak * +1 way to do what we already do just fine * more lexer/ast complexity for downstream projects If you want to make an RFC about it, it really needs a compelling "pros" section, because there aren't any, so far :-\ Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Attributes on property groups

Probably easier/simpler to deprecate (then remove) property declaration groups, no? On Tue, Sep 22, 2020, 14:51 Nikita Popov wrote: > Hi internals, > > Currently, placing an attribute on property (or constant) groups is not > allowed: > > class Foo { > #[NonNegative] > public int $x,

Re: [PHP-DEV] __isset() and null value

gicAndTerriblyUgly::class))->hasProperty('baz')); ``` https://3v4l.org/pVC4j Checking if a **public** property exists at runtime is done via `array_key_exists()`, not via `isset()`: ```php https://3v4l.org/ZLSjq Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

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

sounds like the best approach: optimizing the `foreach (\array_keys($input) as $key) {` structure, when detected. That would make it zero impact from an RFC/userland perspective, and the OP by John is in fact about a performance concern, while we already have a very expressive way to do key iter

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

On Tue, Sep 1, 2020, 09:31 Nikita Popov wrote: > > To be in line with naming conventions, I would suggest calling these > iter_any() and iter_all(), using iter_* as the prefix for our future > additions to the "functions that work on arbitrary iterables" space. > iterable_any() and

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

he standard library provided it, then polyfills would as well, > making cleaner code easier to write. > > Thanks, > - Tyson > Would it make sense, instead of having a third boolean parameter (causing two parameters to be coupled together - already quite messy with existing array functions) for `any()` and `all()` to just detect if the given callback requires >1 parameter? That would make this much simpler. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Import of variables

Hey Manuel, On Sun, Aug 9, 2020, 11:02 Manuel Canga wrote: > Hi Internals, > > I'd like to open up a discussion around the implementation of a new > functionality: 'import of variables'. > > This functionality would allow to create a new 'use vars' keyword in > order to can use( or cannot

Re: [PHP-DEV] Null-safe property access in interpolated strings

On Sun, Aug 9, 2020, 00:17 Sara Golemon wrote: > Do we expect this to work? > > $foo = new stdClass; > $foo->bar = "Hello"; > echo "$foo?->bar world\n"; > > Because at the moment it doesn't: https://3v4l.org/nLv3l > > -Sara > Ooof, people still interpolate strings that way? Good riddance if it

Re: [PHP-DEV] Feature Request: dependencies container

Re-writing with the internals ML in CC On Mon, Aug 3, 2020, 06:16 3u93n3 wrote: > > 2. Setter injection (as well as property injection, and also the > proposed `__inject`) leads to temporal coupling smells. Explained > otherwise, your object instances are not "functioning" right after >

Re: [PHP-DEV] Feature Request: dependencies container

Heya, On Mon, Aug 3, 2020, 05:32 3u93n3 wrote: > The main idea is to take control over objects creation and injecting > dependencies. > > 1. Some of them are provided through constructor (those, which could only > be retrieved right before instantiating our object). > 2. Others are provided

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

liarity of some folks with java annotations, but it is clear that rust-ish annotations with a clear delimiter have technical advantages in parsing and future scope/support. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

, instead of expanding this too... I don't really care about `declare(strict_types=0), since I don't use it anymore, nor plan to use it anymore in any foreseeable future, but the two points above really feel wrong, and I'm conflicted about what to vote. Marco Pivetta http://twitter.com/Ocramius h

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

<http://ocramius.github.com/>Hey Larry, On Wed, Jul 15, 2020 at 7:15 PM Larry Garfield wrote: > On Wed, Jul 15, 2020, at 11:59 AM, Marco Pivetta wrote: > > Hey Larry, > > <http://ocramius.github.com/> > > > > > > On Wed, Jul 15, 2020 at 6:55 PM La

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

se psalm or phpstan, a program that doesn't use `>>=`, or forgets to check for `null` on `?T` does not type-check anyway, and can be rejected before even writing any runtime tests: that's sound. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

ar advantage over previous logic: as it stands, I don't see why I would ever prefer `(bool) $object` over `$object !== null`, or `$object->valid()` (which I believe to be an anti-pattern) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1

I consider the problem problem of singleton enforcement to be solved elegantly in userland, such as in https://github.com/marc-mabe/php-enum/blob/v4.3.0/src/Enum.php Considering that, what does a language-level construct bring in? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] Named arguments

Hey Rowan, <http://ocramius.github.com/> On Fri, Jul 10, 2020 at 12:11 PM Rowan Tommins wrote: > On Fri, 10 Jul 2020 at 10:21, Marco Pivetta wrote: > > > I kept my "NO" stance here, as per discussion in > > https://externals.io/message/110004#110005, where I

Re: [PHP-DEV] [VOTE] Named arguments

erspective. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov wrote: > Hi internals, > > I have opened voting on the named arguments RFC: > https://wiki.php.net/rfc/named_params > > Voting will clos

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

rankly this is something subject to personal opinions and will change > over time according to community shifts. > > Not sure what's "subject to personal opinions" in the objective bug exposed in the snippet above? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

examples at https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jul 6, 2020 at 4:17 PM Josh Bruce wrote: > Apologies, first time, still learning and h

Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive

lti-dimensional arrays: perhaps it should error if the array structure differs? The rest of the proposal makes a lot of sense to me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels wrote: > Hi all, > > I'd like to s

Re: [PHP-DEV] [RFC] Property write visibility

Hey Rowan, On Mon, Jun 29, 2020, 18:19 Rowan Tommins wrote: > On Mon, 29 Jun 2020 at 16:44, Marco Pivetta wrote: > > > property accessors seem to perpetuate the bad practice > > of getters and setters > > > > > Outside of access restrictions, a commo

Re: [PHP-DEV] [RFC] Property write visibility

annoyances around cloning, that would be a more sensible way forward, while property accessors seem to perpetuate the bad practice of getters and setters, which are the main cause for me having to fire up a debugger in any environment. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com

Re: [PHP-DEV] Make `always true` SPL methods return void

or > so, would be a better strategy. > Perhaps this is a good chance to fix the quirks around the `false` type, as well as introducing the `true` type (and using it for these specific functions)? See https://3v4l.org/ZnWmc/rfc#output See https://3v4l.org/MqsvC/rfc#output Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature checks on private methods

within a subtype, which is indeed a bit of a problem: https://3v4l.org/qupHR Maybe the magic methods would indeed all need to respect `final`, and we haven't considered all scenarios? These considerations were part of the previous discussion on the RFC - maybe should be added to its notes? Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Reserve keywords in PHP 8

packagist.org/packages/myclabs/php-enum/stats Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

Hey Pedro, On Mon, Jun 8, 2020 at 5:59 PM Pedro Magalhães wrote: > On Wed, May 27, 2020 at 12:07 AM Pedro Magalhães wrote: > >> On Tue, May 26, 2020 at 3:46 PM Marco Pivetta wrote: >> >>> Considering that, as far as I know, only the constructor remains >&

Re: [PHP-DEV] [VOTE] Attribute Amendments

gt; I'm mostly worried that people will do a mess like with grouped use statements, but hopefully we can fix that via CS rules :-) Overall, good improvement! Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] Opcache optimization without any caching

On Sat, May 30, 2020, 18:20 tyson andre wrote: > Hi Marco, > > > The naming is extremely wonky: allow_cache to allow_optimization? 樂 > > Nonetheless, this is extremely valuable for widely used binaries and > long running processes, so  > > I'm not fully clear on what you mean for

Re: [PHP-DEV] [VOTE] Opcache optimization without any caching

Hey Tyson, The naming is extremely wonky: allow_cache to allow_optimization? 樂 Nonetheless, this is extremely valuable for widely used binaries and long running processes, so  On Sat, May 30, 2020, 17:55 tyson andre wrote: > Hi internals, > > I have opened the voting for

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

Hey Pedro, On Tue, May 26, 2020, 16:34 Pedro Magalhães wrote: > Hi Marco, > > Thanks for the feedback. > > About the sealed type example, it is true that `final protected` wouldn't > achieve the same thing. But as an attempt to provide an alternative design, > wouldn't an union type of the

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

Hey Bruce, On Fri, May 22, 2020, 22:07 Bruce Weirdan wrote: > > On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote: > >> Overall, this RFC breaks some design capabilities that are within the >> language, specifically around `__`-prefixed methods in the language. > >

Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods

this RFC may be valid, and adding a further refinement to lift the restriction only on custom methods is a good idea. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2

the case here. Let me know if you don't agree. > > This looks exactly like the construct that I'd vote for: good work! :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Amendments to Attributes

RFC. Please let me know if it's not. > Do you hope to get nested attributes to 8.0, or is it something you'd prefer to happen at a later time? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] <> Attribute

Hey Benjamin, On Thu, May 7, 2020, 10:42 Benjamin Eberlei wrote: > > This attribute is "reflected" by the engine during compilation, userland > doesn't have to reflect it again itself. on a code level the engine > "patches" each function automatically, this would do the following at > compile

Re: [PHP-DEV] [RFC] Named arguments

On Tue, May 5, 2020 at 8:22 PM Nikita Popov wrote: > Builders and withers? Those are not, intrinsically, good code. They are > workarounds for lack of good object initialization support. I should not > have to implement a large amount of builder boilerplate to make the > construction of simple

Re: [PHP-DEV] [RFC] Named arguments

Hey Theodore, <http://ocramius.github.com/> On Tue, May 5, 2020 at 6:59 PM Theodore Brown wrote: > On Tue, May 5, 2020 at 9:11 AM Marco Pivetta wrote: > > > As mentioned some days ago, I see named parameters as an added liability, > > rather than values. > >

Re: [PHP-DEV] [RFC] Named arguments

pliance like with `foo($newParameterName, $parameterName = null)`, and I do not see which added value counters this massive amount of maintenance overload. We're chasing a non-existing problem (or feature requirement) by adding other problems that are far greater. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Named arguments

ending on use-case, which is still a much safer approach than delegating this responsibility to a caller. My example above uses a `::fromArray()` "factory" precisely for that purpose. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Named arguments

->toSequentialParameters() ); ``` For the few use-cases where this is needed, the userland solution seems to be sufficient, without introducing catastrophic BC boundary expansions. Unless I'm not seeing an incredible (hidden, to me) value from this functionality, this is a clear -1 f

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

mbols in the global namespace. Like many other things in life, just because you don't see something doesn't mean that it is certainly not there ;-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

ute` is certainly too generic, and will needlessly collide with code in the wild. I suggest circling back to the `PHP\` namespace discussion, and having `PHP\Attribute` if you really have a problem with current naming. Otherwise, we will indeed see more and more `the_php_way_` in future :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] match expression

; {}, > } > > There is a separate poll for specifying the reason for a "no" vote. > Let me know if there are any other reasons so I can add those to the > poll. > > A personal thank you goes out to Tyson for his guidance! > > Regards, > Ilija > Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

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

? > The only limitation right now is `resource`: `callable` is always either an `array`, a `string` or an `object` that implements `__invoke`, so `callable` is a subtype of the union type mentioned few posts above. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

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

Hey Dan, On Mon, Apr 20, 2020, 13:18 Dan Ackroyd wrote: > Hi Internals, > > Here is an RFC for adding a 'mixed' type to the language: > https://wiki.php.net/rfc/mixed_type_v2 > The RFC builds on an earlier draft by Michael Moravec. > > Part of the motivation for pursuing this RFC was my recent

<    1   2   3   4   5   6   7   >