Re: [PHP-DEV] [RFC] Default expression
On Mon, Aug 26, 2024 at 5:36 AM, Jakob Givoni <[ja...@givoni.dk](mailto:On Mon, Aug 26, 2024 at 5:36 AM, Jakob Givoni < wrote > "default" should not evaluate to a value before sending it as an argument to > the function or method. I have no dog in this fight, but I agree with the above. Plus, having thunks like that also opens up the gateway to hell^w^w^w^wmany other possibilities such as Scala-style lazy arguments, futures, who knows what else… —c
Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)
> On Jul 4, 2024, at 12:02 PM, Mike Schinkel wrote:
>
> Your definitions are language-specific. For example, in Go the definitions
> for those terms are the opposite of how you defined them.
>
> The point being that PHP is free to choose how they are defined with respect
> to PHP.
>
> To which I will add "as long as the terms are used consistently.”
Okay, some languages may swap the terms, others like JS glom the concepts
together, and in Perl 5 “package Foo” defines a module. I’d say most PHP devs
are more familiar with the terms as they’re used in JS, but whatever makes
sense for PHP is what’s best. I suppose I do have a dog in the fight, but I
don’t much care how it’s groomed.
Then there’s GHC Haskell which has `import “package-name”
ModuleName.{Foo,Bar,Baz}`, which seems to cover all the bases. Decent ideas
from the syntax, but I don’t think I want to replicate backpack :)
—c
Re: [PHP-DEV] [PHP-Dev] Versioned Packagers (Iteration IV)
> On Jul 3, 2024, at 6:16 PM, Michael Morris wrote: > > Hello all. Hitting reset again as the primary problem at hand has become > clear. Let's recap it. > > Autoloading is great for loading packages, but it can't load different > versions of the same package at the same time. Why would you want to do that? > > When you don't have full control of the code. > > For example, consider Drupal. It is running Twig at some version of 3 at the > moment. Suppose Twig 4 is introduced with significant backward compatibility > breaks (Not saying the authors would do such a thing) but also wonderful > features. > …[snip]... > This is why I advocate a new keyword for this - import. Import’s behavior is > most similar to require_once, but it doesn't have to be the same. Since it > is a new entrypoint into the engine the way the engine considers the code can > be different - whether slightly different or radically different is a debate > for another time. I'm going to stick with only those changes that make sense > in the context of package links. I’m seeing a lot of conflation of ‘module’ and ‘package’ in these discussions, and to me they mean different things: * A module is a sort of “first class namespace” that can export symbols and import others. Think ES5 or python modules. If you don’t want it 1-1 with files, think Perl modules. * A package is an “installable” unit that provides modules, among other things. Packages have metadata, the most important piece of which is a machine-readable version. Certainly there’s overlap between the two, but the first is a more low-level thing that doesn’t need worry itself about versioning let alone multiple simultaneous versions. I just don’t want to see the possibility of having basic “import” and “export” functionality crushed under the bikeshed while all the fine semantics of versioning are worked out. —c
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
> On Jun 27, 2024, at 11:26 AM, Tim Düsterhus wrote: > > Hi > > On 6/27/24 19:09, Chuck Adams wrote: >> Personally I say let strtok be and just admit in the documentation that it’s >> weird because C. > > strtok() is not weird because C. It does not rely on the libc strtok() > function and did not since at least 1999 (and likely never did): > https://github.com/php/php-src/commit/257de2baded9330ff392f33fd5a7cc0ba271e18d#diff-fcf8a2a38ee4a0e3e2cb7c47251c9920ba8c5886d85969f676f9ddbee7aba503R332 Okay, how about “weird because POSIX”? The API gets the blame then, not any implementation. > strtok() is weird, because someone believed that relying on global state > was good API design. I find that excusable, because it happened more > than a quarter of a century ago. Oh I think strtok is awful, but it also looks like it beats the pants off the alternatives performance-wise. I imagine it’s also completely ignorant about unicode, so yeah… I guess it should at least be deprecated until being replaced by a userspace version with similar performance. —c
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
> On Jun 27, 2024, at 2:22 AM, Stephen Reay wrote: > > I do appreciate that strtok has a kind of bizarre signature/use pattern and > potential for confusion due to how subsequent calls work, but to me that > sounds like a better result for uses that need the repeated call > functionality, would be to introduce a builtin `StringTokenizer` class that > wraps the underlying strtok_r C call and uses internal state to keep track of > the string being tokenized. strtok is weird, but it’s not actually dangerous. An OO wrapper doesn’t sound worth it unless it comes with compelling extra features or at least a reusable abstraction in the form of a concrete `StrTokTokenizer` (or hopefully a less ugly name) implementing a StringTokenizer interface. Personally I say let strtok be and just admit in the documentation that it’s weird because C. [Resent to the list. Sorry for any previously cc'd dups, macOS Mail keeps guessing the wrong sender address.] —c (weird just because)
Re: [PHP-DEV] [RFC] Static class
> On Jun 26, 2024, at 5:49 PM, Derick Rethans wrote: > > There has been some work done on function autoloading too: > https://wiki.php.net/rfc/core-autoloading Fantastic! I still want modules and/or companion objects of course... I wonder whether the autoloading machinery could be bent to such a purpose, or am I smoking the bad stuff again? —c
Re: [PHP-DEV] [Early Feedback] Pattern matching
> On Jun 26, 2024, at 1:50 PM, Morgan wrote: > So the issue has nothing to do with this hypothetical infinity of > unobservable nulls, and comes entirely down to the fact that with this > pattern a variable may pass > a) because it does not have a key named 'foo', or > b) because it has a key named 'foo' with a string value. Existing array shape implementations already distinguish optional and nullable, I can’t imagine a pattern syntax that doesn’t do that too, It’s just the case of binding with optional keys that seems to be a special case that means the type of whatever you So, possibly inventing a novel binding syntax here because I haven’t followed the syntax discussion and I don’t see bindings in array shapes in the RFC: [‘foo’ => $x is ?string] // just fine, $x is explicitly string|null [?‘foo’ => $x is ?string] // also fine, $x is explicitly string|null [?‘foo’ => $x is string] // $x is actually string|null There’s a precedent with function parameters: function foo(string $bar = null) // $bar is string|null There’s some difference though [] is [?’foo’ => $x is string] // matches, $x === null [‘foo’ => null] is [?’foo’ => $x is string] // match fails And sorry if my sample syntax is weird and ambiguous. I learned in the 90’s that it depends on what your definition of ‘is’ is ;) Cheers, chuck
Re: [PHP-DEV] [RFC] Static class
> On Jun 25, 2024, at 9:17 AM, Derick Rethans wrote: > > Having read this thread, and the previous one from half a year ago, I > will do so too. In short, we shouldn't be encouraging static classes as > a bag of static functions, that ought to be just namespaced functions. Which brings us back to the age-old problem that functions can’t be autoloaded. Me, I want first-class modules, but until we have those, I have to settle for classes in the meantime. Scala/Kotlin-like “companion objects” might be a good all-round substitute though. Cheers, chuck
Re: [PHP-DEV] [Early Feedback] Pattern matching
> On Jun 24, 2024, at 1:53 PM, Robert Landers wrote: > > $arr = ['a' => 'a string']; > $arr is ['a' => string, ?'b' => $value, ...]; > > This syntax implies that a non-existent key is a special case, and if > it passes as-is, it will be. If there is a binding and the key is > missing, what happens to that binding? Is it left in an undefined > state or is it assigned NULL? If it is assigned NULL, what is the > value of checking for non-existence; why not just check for NULL in > the value? If it is left "undefined", then you still have to handle it > as though it is a NULL value (perhaps more so because simply trying to > detect its value may cause the very warning you are trying to avoid -- > and will fatally error in PHP 9:https://3v4l.org/Rbadk. see > https://wiki.php.net/rfc/undefined_variable_error_promotion). > > Thus, this "key existence check" is inconsistent with the language and > possibly redundant, as you'd have to check that resulting value was > null anyway: > > $arr is ['a' => string, 'b' => ?string, ...]; > > Hope that clarifies things. I see what you mean: leaving $value undefined would be a high-caliber footgun for sure! I suppose binding to optional keys could just be verboten, but that kind of restriction would make for a lousy DX. Distinguishing between “optional and not nullable” and “not optional but nullable” still seems reasonable for array shapes in general, but optional and nullable pretty much have to become one once bindings are involved. So color me convinced :) Cheers, chuck
Re: [PHP-DEV] [Early Feedback] Pattern matching
> On Jun 24, 2024, at 3:31 AM, Robert Landers wrote: > > > There's no need to use `?` to check for existence on a key, so this: > > $arr is ['a' => string, ?'b' => string, ...]; > > should be this: > > $arr is ['a' => string, 'b' => ?string, ...]; > > because $arr['non-existent-key'] is NULL. > The first means b is an optional key, but if it’s there, can only be a string. The second says b is a required key, but it may be a string or null. If there were a binding involved, that determines the type of the binding in incompatible ways. I’m fine with requiring bindings to be nullable for optional keys, but it strikes me as strictly less flexible and not consistent with the rest of PHP’s behavior, at least not under E_ALL. (Sorry for any dups. juggling sender addresses to make the listserv happy, fixed an incomplete thought while I was at it) Cheers, chuck
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
On Wed, Dec 30, 2020 at 12:27 PM Larry Garfield wrote: > > If you clone the object, you don't duplicate 15+1 zvals. You duplicate just > the one zval for the object itself, which reuses the existing 15 internal > property entries. If in the new object you then update just the third one, > PHP then duplicates just that one internal zval and modifies the new one. So > you still are using only 18 zvals, not 36 zvals. (Engine people: Yes, I am > *very* over-simplifying. I know.) > I've pondered hacking in something like perl's bless() to turn arrays into value objects, but according to this it looks like an object with clone-on-write behavior would be better, as I'm assuming arrays do a full shallow copy: given an array of 15 entries, pass it to a function, change one member, now you're using 15 more zvals, as opposed to just one with an object. Am I reading that right? --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys
On Wed, Dec 2, 2020 at 10:46 AM G. P. B. wrote: > The reason why this has been deferred is because of which semantics should > be used for duplicate string keys. > > Do we use the addition between two arrays semantics or the array_merge() > semantics? See: https://3v4l.org/7QbWv array_merge is the only one that makes sense. Addition of positional arrays is nonsensical: [1,2,3] + [4,5,6] ===> [1,2,3] As for named keys, every other language with a similar construct (perl, python, javascript) uses array_merge semantics. Truth is I'm sorely disappointed that + works like it does, but there's no fixing it now. --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
On Sat, Jul 25, 2020 at 9:30 AM Chuck Adams wrote: > > Not a fan of special syntax for environment variables regardless of > the syntax. I think `$_ENV['foo'] ?? 'bar'` is fine as-is. Not so > much the superglobal, but there's also getenv(). I feel fairly silly, this being for just .ini files. Seems reasonable enough there, though now we're talking about .ini files no longer being static... --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
On Fri, Jul 24, 2020 at 2:54 PM Derek Bonner wrote:
> * memory_limit = ${PHP_MEMORY_LIMIT:-"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT::"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT:="default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT=="default value"}
Not a fan of special syntax for environment variables regardless of
the syntax. I think `$_ENV['foo'] ?? 'bar'` is fine as-is. Not so
much the superglobal, but there's also getenv().
--c
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Ternary associativity
On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote: > If anything, I would argue for making both of these into errors, if > that's possible. I think the biggest risk with this kind of change is > not existing code relying on the old behaviour, it is code relying on > the *new* behaviour which is accidentally run on older versions of PHP. I thought the proposal to turn unparenthesized use into a warning then waiting for PHP9 to use the proper precedence was the right idea. Nested ternaries with the proper precedence turn into lovely truth tables, which isn't even an uncommon idiom in C. I'd really not like to feed /r/lolphp ammo by requiring the parens in all cases and continuing to break the ternary operator in comparison with every other language that has it. --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
On Sat, Jul 11, 2020 at 8:56 AM Rowan Tommins wrote: > (and, funnily enough, PHP 4 did for objects). The funny thing about it for me is that this behavior caused me to throw such a fit when I discovered it -- more to say burned by it -- that I swore off PHP forever at the time. Now I actually want this behavior back, though as an opt-in. Maybe that would address some of the intent of this proposal. It'd be easier to know with some solid examples. --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
On Sat, Jul 11, 2020 at 8:06 AM Olle Härstedt wrote: > > Dear internals, > > I'd like to discuss the concept of ownership in PHP, from the point of > view of a new interface UniqueInterface (or SplUniqueInterface or > something), which will throw a UniqueException if refcount > 1. > > Use-case: Mutable objects that cannot be shared (without (deep) cloning). I don't think you want to do this on refcount, since that would prevent even passing it to another function or using it in any number of expressions. What would make more sense to me would be hooking into copy-on-write, which would also be a slightly less hot code path than reference counting (but still a pretty critical one). It almost sounds like a uniqueness type, something well beyond the capabilities of PHP's type system (and most others). --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Named arguments
> Then the question becomes, do we rename parameters a lot? I doubt it's a > large problem, and even then the variadics support makes it very easy to > handle in a backwards compatible way. In addition libraries are always open > to declare they don't consider named parameters as part of their API. Python supports the notion of "keyword-only arguments". If that was supported, and the renamed argument had a default, an API could rename parameters in a backward-compatible manner by introducing a kw-only arg with the same name. One could also consider an aliasing syntax such that more than one keyword could correspond to a named argument. Perhaps using an annotation? --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
I might suggest that we at least confine any renaming to things that are user-visible and not worry about the source code. Except they're going to need aliases for all time, that's just a fact. Although I'm all about addressing the injustices of the past and present, I think it would be a lot more productive to spend our effort on future naming. I have pretty different connotations for "blacklist" anyway, seeing it less as an exclude pattern and more of a "never allow this because it's really bad if you do". Like the blacklisted keys unix distros keep after that a critical security bug in ssh a ways back. Let's look forward AND backward, but mostly forward. And with my awesome rhetorical skills, I single handedly put this matter to bed, right? ;) --c On Mon, Jun 15, 2020 at 3:12 PM Daniel Rodrigues Lima wrote: > > Hi Larry, > > I appreciate your answer, thank you, but i would like to clarify some points: > > 1. I found 170 occurrences of the term blacklist - grep -rni "blacklist" > php-src/, i'm working to understand the impact of changes; > > 2. It’s not about politics, i believe it’s about learning how to be better > humans; > > 3. I fully agree; > > 4. Sometimes it's necessary "broken window policing"; > > 5. I truly recognize this, and respect above all. > > > However if the majority disagree with the changes it is not worth pursuing > this discussion, and I should not even write an RFC for that. > > -- > Cheers, > > Daniel Rodrigues > > https://twitter.com/geekcom2 > > De: Larry Garfield > Enviado: segunda-feira, 15 de junho de 2020 17:21 > Para: php internals > Assunto: Re: [PHP-DEV] About the use of the terms master/slave and blacklist, > proposal to replace. > > On Mon, Jun 15, 2020, at 2:11 PM, G. P. B. wrote: > > On Mon, 15 Jun 2020 at 20:05, Lynn wrote: > > > > > On Mon, Jun 15, 2020 at 7:46 PM Alain D D Williams > > > wrote: > > > > > > > It is very easy to take offence when none is meant at all. One needs to > > > > look at intent. > > > > > > > > > > Hi, > > > > > > I'm going to disagree here. It's not about intent, it's about impact. You > > > can have the best intentions with the worst results. > > > > > > When I read the replies here, it makes me sad. The comments come from a > > > place of white privilege and I'm sad to see that's how people think about > > > it. > > > > > > Regards, > > > Lynn > > > > > > > What saddens me is that these terms are non issues, and think they do > > something for "good" when it's just a pat on the back without doing any > > tangible change to the world. > > > > Case in point, from what I've seen mostly going around in the French > > community [1] is that the people who are actually concerned think it's > > woke and completely nonsensical. And I could argue the white-privelege > > here is to discuss these matters and imagine they would improve something. > > > > For blacklist/whitelist the benefit of changing it is that we can use more > > descriptive terminology such as deny/block/disallow and their opposite > > depending on context, which probably is more accessible to non-native > > English speakers. And if one wants to change it this should be the angle. > > > > However, I would argue that *if* when someone hears the word black the > > first thing which comes to their mind is race, then that makes them more > > of a racist and not the other people who use this with the well defined > > meaning. As such I would argue this is undermining the meaning of the > > word and pushing us towards an orwellian [2] state of the world. > > > > Moreover, black does not always mean something is "bad", see martial > > arts where a black belt is synonymous with experience and a white belt > > means that you are a novice. > > > > So instead of taking offence on behalf of a whole group and proposing > > changes which don't affect said group in any meaningful way while > > causing BC. Because if we decided to accept doing this, I shall start > > being offended about the usage of the word string as in French string > > means a thong and I imagine French women to be outraged that we > > (predominantly white males) casually talk about splitting or comparing > > strings. > > > > Best > > > > George P. Banyard > > > > [1] https://twitter.com/jesuisundev/status/1269260740894117890 > > [2] https://www.youtube.com/watch?v=oe64p-QzhNE > > I am so going to regret being in this thread, but... > > > Data point: My boss at work noted earlier that he'd reached out to some black > women he knows to get their take; their response to him was that > blacklist/whitelist did bother them, but "master branch" did not. > > Of course, with GitHub now deciding to change its standards that is going to > percolate to the rest of the industry sooner or later, regardless of whether > it's a good idea or a stupid waste of time. It's going to happen now. > > It should be noted that a person saying "I am offended" does not, in fact, > make something
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
Oh man, not this again, not here. Nothing intelligent ever comes out of this.
Looks like most instances in the PHP source refer to mysql constants,
which means the ball would be in mysql's court. Reality is you'd
still need the aliases that contain the offending word.
The other is in ext/standard/proc_open.c, referring to a "slave pty".
Seems pretty trivial to change.
But "trivial" is the operative word here. Go join a protest and/or
call your congressperson if you want to actually do something
constructive.
Heck, it's not a big list. How about nobody EVEN starts on the name
of the branch...
✔ ~/proj/php/php-src [master|✔]$ ag slave
ext/standard/tests/file/userstreams.phpt
17:to the game you stay a slave
ext/standard/proc_open.c
613:static int set_proc_descriptor_to_pty(descriptorspec_item *desc,
int *master_fd, int *slave_fd)
616: /* All FDs set to PTY in the child process will go to the slave
end of the same PTY.
620: * slave FDs. */
622: if (openpty(master_fd, slave_fd, NULL, NULL, NULL)) {
629: desc->childend = dup(*slave_fd);
761: int ndesc, int nindex, int *pty_master_fd, int *pty_slave_fd) {
803: /* Set descriptor to slave end of PTY */
804: retval = set_proc_descriptor_to_pty(&descriptors[ndesc],
pty_master_fd, pty_slave_fd);
925: int pty_master_fd = -1, pty_slave_fd = -1;
998: &pty_master_fd, &pty_slave_fd) == FAILURE) {
1220: if (pty_slave_fd != -1) {
1221: close(pty_slave_fd);
ext/mysqlnd/mysqlnd_enum_n_def.h
599: STAT_COM_REGISTER_SLAVE,
664: COM_REGISTER_SLAVE,
692:#define MYSQLND_REFRESH_SLAVE 64 /* Reset master info and restart slave */
ext/mysqlnd/mysqlnd_libmysql_compat.h
127:#define REFRESH_SLAVE MYSQLND_REFRESH_SLAVE
ext/mysqlnd/mysqlnd_wireprotocol.c
52: "TABLE_DUMP", "CONNECT_OUT", "REGISTER_SLAVE",
ext/mysqlnd/mysqlnd_statistics.c
181: { MYSQLND_STR_W_LEN("com_register_slave") },
ext/gd/libgd/gd_png.c
365: /* 2.0.12: Slaven Rezic: palette images are not the only images
ext/mysqli/tests/mysqli_constants.phpt
97:"MYSQLI_REFRESH_SLAVE" => true,
200:$expected_constants["MYSQLI_RPL_SLAVE"] = true;
ext/mysqli/tests/mysqli_get_client_stats.phpt
1250: ["com_register_slave"]=>
ext/mysqli/mysqli.c
818: REGISTER_LONG_CONSTANT("MYSQLI_REFRESH_SLAVE",
REFRESH_SLAVE, CONST_CS | CONST_PERSISTENT);
✔ ~/proj/php/php-src [master|✔]$
--c
On Mon, Jun 15, 2020 at 9:43 AM Daniel Rodrigues Lima
wrote:
>
> Hi internals,
>
> I think the time has come for the PHP internals to discuss the use of
> master/slave and blacklist terminologies.
> As everyone can see, we are going through times of change in the world, see
> #blackLivesMatter for example.
> Therefore, I propose that we discuss the non-use of terms master/slave,
> because the use of this can allude to the slavery and negative feelings about
> black people.
>
> Some projects that changed the terminology:
>
> *
> https://github.com/sebastianbergmann/phpunit/commit/8e9c76d33dab4095c9066072076f368193e4166d
> * https://go-review.googlesource.com/c/go/+/236857/
> * https://issues.apache.org/jira/browse/COUCHDB-2248
> * https://bugs.python.org/issue34605
>
> Greets,
>
> Daniel Rodrigues.
>
> geek...@php.net
> https://twitter.com/geekcom2
> https://www.linkedin.com/in/danielrodrigueslima/
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revisiting proposal for addition of `get_class_constants()`
> 1. It aligns with the addition of the functions referenced in the original post (`str_[contains|starts_with|ends_with]()`), and one their stated reasons of simplifying the API for userland developers. Two reactions to this: One, reflection isn't a facility for novices, so there's no need to cater to it. If novices end up needing such a method frequently, something else is wrong other than how accessible that method is. Two, reflection being all about reflecting over objects and classes, it seems reasonable to limit it to an OO API. Any existing global functions in that arena should just be considered legacy. ReflectionClass is not final, and I can see plenty of use cases for subclassing it. On Thu, Jun 11, 2020 at 10:32 PM Troy McCabe wrote: > > Hey Nikita, > > Thanks for the thoughts. > > > Could you please explain in more detail *why* we should duplicate existing > > reflection functionality into free-standing functions? > > In terms of the *why*, there were three main reasons: > 1. It aligns with the addition of the functions referenced in the > original post (`str_[contains|starts_with|ends_with]()`), and one > their stated reasons of simplifying the API for userland developers. > While `(new \ReflectionClass(MyClass::class))->getConstants()` isn't > the most difficult thing to grasp, it's not immediately clear to new > developers, and is more verbose than > `get_class_constants(MyClass::class)` > 2. `get_class_[methods|vars]()` existing as built-in functions, > creates a gap to retrieving class constants in the same way. If I > start down the path of class inspection using `get_class_*()`, but > find I can't retrieve constants in the same way, this is an > inconsistency. > 3. When using Reflection, accessibility is not respected as it is with > the `get_class` family of functions. In the event that a developer is > looking for constants which are accessible to the current context, > there's no way (that I'm seeing, anyway) to retrieve _only_ constants > accessible in the current context. > > > I believe the existence of functions like get_class_methods() is a > > historical artifact, because they were introduced before Reflection was a > > thing. Unless there is a strong reason to the contrary, I would prefer > > reflection functionality to stay inside Reflection... > > This is good background that I wasn't aware of (I knew the Reflection > API was newer than the built-in functions, but not that the > `get_class_*` functions were generally frowned upon). > > It does bring up 2 questions: > 1. Obviously this is a much larger discussion, but is there any > appetite to deprecate & remove the existing functions in favor of the > Reflection API? > 2. An alternative to adding `get_class_constants()` would be to > introduce `ReflectionConstant` as a return type from > `ReflectionClass::getConstants` to match `ReflectionMethod` & > `ReflectionProperty`, which would solve point 3 above. Would this be a > preferable approach? > > > You do mention performance as a benefit, but it's not immediately obvious > > to me which use-cases are bottlenecked by class constant reflection. > > Enum implementations are the big case for this. While the libs I've > looked at use an internal cache, these caches are per-request, so > reflection will need to be used as many times as there are enums in a > given system. Depending on the scale, this could be an appreciable > amount. Obviously external caches could be leveraged, but that then > requires additional development lift, instead of using battle-tested > enum libs. > > Thanks for the thoughts, and thank you for all your work on internals! > Thanks! > Troy McCabe > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
(Trying again without a plussed address, which is too much hassle for the ML. Sorry for dups.) Honestly, I'd rather PHP didn't barf raw lex tokens to the end user for its output. But until then, renaming it seems wise. Didn't someone come out and claim that the current token is misspelled Hebrew anyway? --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
