, I intended comments were intended to be viewed as "Yes, and..."
> On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote:
>>
>> IOW, given that all the current infrastructure really supports are
>> static pages — without a gargantuan effort to write and maintain a
&g
> On Oct 7, 2024, at 1:39 AM, Larry Garfield wrote:
>
> On Sun, Oct 6, 2024, at 2:33 PM, Mike Schinkel wrote:
>
>>> On Oct 5, 2024, at 10:25 PM, Larry Garfield wrote:
>>>
>>> A number of people are concerned that if we use any of the "Bi
and maintain websites — if it gets shot down by too many then no need to
discuss the details any further.
-Mike
[1] I am being deliberately hyperbolic here for hopefully humorous effect. :-)
uld introducing
`get_declared_symbols()` + `symbols_exists()` really require deprecating the
other functions?
It seems adding a `get_current_enums()` and `get_declared_symbols()` +
`symbols_exists()` functions would address all the same userland developer
needs as the proposed RFC (and more
t could be discussed and commented on as you can on a
Github repo.
Note I am not advocating fro a *specific* approach — e.g. WASM — I am advocated
to achieved the stated goal, e.g. an extension mechanism that can run at near
native speed for low-level string parsing and maths that realistically
> On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:
>> Yeah. That was the original goal.
>>
>> But to say WASM's domain is limited to browsers is not valid any longer:
>> [...]
>
>
ntime potentially redundant for
> most use cases.
Partial redundancy is not redundancy.
WASM's ability to run on a managed server – assuming it were built-in to PHP
core — is the critical non-redundant benefit. If you cannot run those "existing
mechanisms" then they fact they are redundant does not matter one iota.
-Mike
> On Sep 17, 2024, at 8:05 PM, Jordan LeDoux wrote:
> On Tue, Sep 17, 2024 at 3:44 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote:
>
> Almost everything you have said are things that I have talked about or been
> asked about for years. That is why I have been fair
> On Sep 17, 2024, at 6:04 AM, Andreas Leathley wrote:
>
> On 17.09.24 11:14, Mike Schinkel wrote:
>> How would a developer know if they are using an object that has operators,
>> unless they study all the source code or at least the docs (assuming there
>> are good
t; > few paragraphs prior, and where we could enhance functionality over time,
> >
> > 2. Constantly improving PHP the language, which is what you are solely
> > advocating for over extensibility,
> Hi Mike,
>
> I’m Adam, I'm building WordPress Playground [1] –
> On Sep 17, 2024, at 1:37 AM, Jordan LeDoux wrote:
> On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel wrote:
>
> Yes, if constraints of the nature I propose below are adopted.
>
> The biggest problem I have with operator overloads is that — once added — all
> code could pot
d not have their defaults exposed.
Similarly developers that do not write their code to enable operator overloads
should not be used with userland operator overloads unless they explicitly
allow it, especially as they may not have have tested code with operator
overloads.
Anyway, that is my two cents worth.
TL;DR? I argue that PHP should operator overloads but ONLY if there is a
mechanism that requires the user of expressions that call overloaded operators
to explicitly opt-in to their use.
-Mike
currently being
discussed where the ones 4[1] and 3[2] years ago were both declined.
So arguing with me about operator overloading is effectively just tilting at
windmills. If you really want userland operator overloading in PHP so badly,
propose another RFC and everyone who wants it will like
> On Sep 11, 2024, at 4:55 PM, Rowan Tommins [IMSoP]
> wrote:
> On 11 September 2024 20:12:53 BST, Mike Schinkel wrote:
>>> It also risks conflicting with a future language feature that overlaps, as
>>> happened with all native functions marked as accepting string
hat actually supports what I was saying; people would gravitate to
only doing in an extension what they cannot do in PHP itself, and over time if
PHP itself improves there is reason to migrate more code to PHP.
But there can still be reasons to not allow some thing in userland. Some things
Hi Rowan,
This message is in reply to https://externals.io/message/125455#125496 from the
thread "bikeshed: Typed Aliases"
> On Sep 10, 2024, at 5:35 PM, Rowan Tommins [IMSoP]
> wrote:
> On 10 September 2024 19:32:19 BST, Mike Schinkel wrote:
>> BTW, why has nobody
nts, and so
others can ignore it unless they really want to follow it.
-Mike
pe anything that passes an RFC is intuitive and well reasoned because
otherwise our governance model is flawed and maybe we need to address that
first, if so?
-Mike
[caveat] — I am aware there are likely numerous use-cases in financial,
scientific and/or related fields that could benefit from op
> On Sep 9, 2024, at 5:35 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On 09/09/2024 19:41, Mike Schinkel wrote:
>> In Go you cannot add or subtract on a typedef without casting to the
>> underlying type. I would definitely prefer that to be relaxed, but only
>> if
ng for or against any specific syntax, just pointing out that there
are other potential options.
-Mike
efs was the sort of "other stuff classes do" that I was
> trying to avoid getting into right now. :-) Mainly because I can totally see
> how it's tempting, but also have no idea what it would mean from a
> type-theoretic perspective. It would only make sense if we're talking type
> DEFs, not type ALIASes.
That latter sentence is spot-on.
-Mike
, no problem as LocalWidget === Widget
$w = new MyWidget;
doSomething($w); // This throws an error as MyWidget !== Widget
-Mike
> On Sep 6, 2024, at 4:47 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 6 Sep 2024, at 03:01, Mike Schinkel wrote:
>>> Block-scoping doesn't have to allow shadowing of names,
>>
>> How exactly would that work? Are you suggesting to restrict the use of
ou that said that.
Whatever the case, of the features that have been implemented in recent years I
find it hard to believe adding local constants would be nearly as hard as some
of those features. Certainly easier than aviz.
-Mike
this specific history to opine — do not apply: Java/Kotlin, Swift,
Go, C/C++, Zig, and Rust (while ignoring TypeScript given its roots in JS.)
Simply put the reason for local const is to declare an immutable variable, one
whose value we know cannot change. One key reason relevant to PHP is to ensure
its value is not changed by reference by a function you are calling, but also
so that you don't accidentally change it in the same function. And here are
some more reasons elaborated:
https://stackoverflow.com/questions/622664/what-is-immutability-and-why-should-i-worry-about-it
-Mike
> On Sep 2, 2024, at 11:20 PM, HwapX wrote:
> Hello internals!
>
> I was wondering, has there been any discussion about supporting local
> constants (variables that cannot be reassigned, perhaps even function
> parameters)?
+1 from me.
-Mike
gt;default` if `default` could be used in this
context.)
Anything declared to be a `datapair` type could be declared to have names that
are not valid identifiers and end with whitespace.
A declared `datapair` inner type would default to `string` but could be
declared otherwise if needed, see how I declared `Expires` as `int`. However,
it would be good if they could always just be `string` and never anything else.
By their nature, any dataset properties or variables would need to be accessed
with braces, e.g. `$this->{Content-Type}` and `${Content-Type}` or if without
quotes is not possible in the parser then by `$this->{'Content-Type'}` and
`${'Content-Type'}`
Given the above — assuming it were accepted and added as a feature to PHP — how
would this not address your use-case(s)?
Note I have no idea if the above would even be considered, but I am proposing
here to understand what alternatives may be to address your desired use-case(s).
> Good call, I should probably separate both proposals.
+1
-Mike
AnyChars%%!@#' is not included in the array returned by
`get_class_methods()` and/or `ReflectionClass::getMethod()` which is evidence
of why procedural magic methods are at best a bandaid compared with declarative
solutions.
-Mike
> On Sep 2, 2024, at 1:48 PM, Hammed Ajao wrote:
>
> Hello Mike,
>
> Thanks for reading and responding. While your enum does technically address
> some of the issues I am discussing, it does so in a very verbose and
> cumbersome way.
> - First you need the Default
> On Sep 2, 2024, at 12:42 PM, Christoph M. Becker wrote:
>
> On 02.09.2024 at 16:51, Mike Schinkel wrote:
>
>> Generally I am one who welcomes new feature ideas, but I fear that string
>> literals as object properties would break a valuable assumption that all
>&
would not address the issues you were trying to address?
Generally I am one who welcomes new feature ideas, but I fear that string
literals as object properties would break a valuable assumption that all
properties must be a valid identifier. Without that assumption I fear many
things that would become more complex.
Also there are chances such a change could break a lot of userland code that
makes that same assumption. I know from using MySQL where field names do not
need to be valid identifiers that such a "feature" complicates coding, makes
certain bugs easier to create, and often makes code less elegant (read
"uglier") that it would otherwise be.
So I am sympathetic to the desire to improve the language. However I fear this
specific change would create more pain than pleasure. Better IMO to look for
less disruptive solutions to achieve the same goals. For example, if the
Enum+Attributes approach meets your needs aside from having too much
boilerplate, maybe we could enhance PHP to have less of that boilerplate?
-Mike
P.S. I want to (again) thank those who brought us Enums as I think they are one
of the best new features PHP has added in the past decade. #fwiw
> On Sep 1, 2024, at 6:12 PM, Christoph M. Becker wrote:
>
> On 01.09.2024 at 09:16, Mike Schinkel wrote:
>
>> One of the benefits for users when software authors strictly follow SemVer
>> is that automated tooling can decide if an automatic upgrade should be safe.
>
e it is just too risky to use automated
tooling. Once bitten, twice shy.
One approach I have seen on other projects take is they retract the versions
with BC breakage and then release an update reversing the breakage.
Something to consider.
-Mike
aving
> them. I believe that would also be a better approach than traits that link
> to interfaces, which achieves not-quite the same result with more steps.
I too am all for revisiting Interface Default Methods.
Lack of interface default methods is one of the most painful missing featur
> On Aug 26, 2024, at 8:28 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>>> You ask how a library can provide access to that default, and the answer is
>>> generally pretty trivial: define a public constant, and ref
he implementation. As far as I read
> the RFC, using "default" when there is no default would lead to a
> runtime exception, but there is no way of finding out if there is a
> default if you do not already know. Being able to test that could be
> useful, although I am not sure about the syntax for that.
Great catch!
> On Aug 26, 2024, at 6:32 AM, Andreas Heigl wrote:
> I think I am missing something here. From my understanding we are *either*
> coding against the interface and then it should not be possible to use
> `default` at all as no default is set in the interface. So the fatal error is
> totally valid for me.
Maybe default value for method parameters in interfaces is something the RFC
should consider enabling?
-Mike
d change.
Where I would see this functionality to be most useful would be:
1. Modifying a default bitmapped argument to add or remove one or more bits.
2. Creating a class instance based on the default — with Wither methods() —
where I need to modify a few properties but want to keep all the rest of the
default value.
Not saying there are not other use-cases, but those other use-cases have not
(yet?) occurred to me.
-Mike
unction stuff($foo = 'bar', $baz = 'world');
>
>
>
> stuff(...[ ...($foo ? ['foo' => $foo] : []), ...($baz ? ['baz' => $baz] :
> [])]);
>
>
And you are one who complains about gotos!😲
-Mike
f making built-ins special and not
require them nor locals be prefixed, and instead require global userland
functions to be prefixed.
>
-Mike
g worthwhile.
Also, whereas only discussion happens on the list, in a repo you can actually
start writing a potential implementation and crafting an eventual RFC, so it
has the potential to be more productive. Finally, the list is the gatekeeper
anyway, so if things are already decided that the list disagrees with, it still
won't pass.
So, if you feel you are a stakeholder on this idea, I'd suggest celebrating the
idea of a repo and joining the discussion there.
-Mike
P.S. As for using Reddit, I'm not as big of that as its has its own culture
that can be just a difficult to incubate ideas as here on this list.
> On Aug 23, 2024, at 9:07 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 13:45, Mike Schinkel wrote:
>>> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
>>> wrote:
>>> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>&g
> On Aug 23, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 13:04:22 BST, Mike Schinkel wrote:
>> And how can it occur without an explicit `use
>> AcmeComponents\SplineReticulator\Utilities\Text\Text` statement, which I
>> proposed would
> On Aug 23, 2024, at 7:50 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Fri, 23 Aug 2024, at 12:29, Mike Schinkel wrote:
>> namespace \AcmeComponents\SplineReticulator\Utilities\Text
>>
>> function Foo():int {
>> return Text\strlen("Hello World
's 3rd option has wings. And along with
automatic `use` statements for each namespace might just be the best possible
solution.
-Mike
P.S. If PHP ever added a set of standard library functions written in PHP to
the core distribution, they should rightly IMO need to be namespaced, per this
Hi Rowan,
> On Aug 23, 2024, at 2:39 AM, Rowan Tommins [IMSoP]
> wrote:
> On 23 August 2024 00:15:19 BST, Mike Schinkel wrote:
>> Having to prefix with a name like Foo, e.g. Foo\strlen() is FAR PREFERABLE
>> to _\strlen() because at least it provides satiating informatio
n" by now; but "unqualified means
> global" feels much more achievable from where we are.
>
If I had a time machine I would campaign for real packages instead of what
namespaces turned out to me, and that used sigils that do not double as the
escape character for strings, but then both of us digress.
-Mike
> On Aug 20, 2024, at 9:44 AM, Arnaud Le Blanc wrote:
>
> Hi Mike,
>
> On Tue, Aug 20, 2024 at 2:45 AM Mike Schinkel wrote:
>> It seems Java-style Generics are viewed as the proper archetype for Generics
>> in PHP? I would challenge the wisdom of takin
ame. Type aliases are super useful in practice in other languages, with many
used for single-file scope in my experience.
-Mike
ut
a few `.php.config` files during CI/CD than to update all files.
Additionally PHP could use an environment variable as prescribed by 12 Factor
apps to identify the root config file. That way a hosting company could allow
someone to configure their production server to point to
`.php.productio
> On Aug 18, 2024, at 4:59 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On 18 August 2024 05:46:09 BST, Mike Schinkel wrote:
>> I know that those functions can be called as a function and return a value
>> like the following:
>>
>> $return_value = include($pat
dFiles[$className] = $path;
}
});
include($path);
spl_autoload_callback($prior_callback);
return self::$loadedClasses[$path];
}
>> This approach would be a less disruptive than my prior suggestion
> Not so sure about that considering the above ;-)
Well then I think a single new function would be very low on the disruption
scale, no?
> This probably needs some more bike shedding ;-)
Shedding of bike undertaken. :-)
-Mike
Hi Juliette,
> On Aug 16, 2024, at 9:25 PM, Juliette Reinders Folmer
> wrote:
>
> On 17-8-2024 2:00, Mike Schinkel wrote:
>> To everyone on this thread and thus nobody in specific (hence my top post):
>>
>> Given that get_declared_*() populates a new ZEND_HASH
> On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP]
> wrote:
> On 17 August 2024 00:25:13 BST, Mike Schinkel wrote:
>> I am not sure I agree with you that adding Unicode support is the wrong
>> angle, per se.
>>
>> A strong argument could be made that Unico
at get immediately
thrown away, and also cut down on memory fragmentation/garbage collector churn.
-Mike
[1]
https://github.com/php/php-src/blob/18d41502da0da1bb3928e60c41f1b821974c2c01/Zend/zend_builtin_functions.c#L1371
> On Aug 16, 2024, at 7:13 AM, Christoph M. Becker wrote:
>
st discussing on the list — enable comments
made in the forum a place to be captured and converted into text and
implementation visible for everyone to see, and really motivated people can
even submit PRs to your RFC in order to spread the load of writing a good RFC.
#jmtcw #fwiw
-Mike
> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP]
> wrote:
> On 16 August 2024 19:44:22 BST, Mike Schinkel wrote:
>> Let me see if I understand your argument correctly? You are asserting that
>> Unicode is "too complex" to be handled in the standard librar
> On Aug 12, 2024, at 4:25 PM, Rowan Tommins [IMSoP]
> wrote:
>
> On 12/08/2024 17:37, Mike Schinkel wrote:
>> A really standout paragraph from that link is:
>>
>> "IMO, the whole situation is a shame. Unicode should be
>> in the stdlib of every langu
ally like
> another class.
>
> When dealing with state, it's nice to have a human readable const to
> represent that state, but I always feel like they should be grouped
> together.
Yes, I would very much like that.
-Mike
P.S. See related: https://externals.io/message/107995
<https://externals.io/message/107995>
s for the response. It was exactly a (custom) autoloader situation which
> caused me to start wondering about this.
Seems Juliette's use-case may be at least somewhat similar to mine.
-Mike
> On Aug 14, 2024, at 5:27 PM, Lanre wrote:
>
>> On Wed, Aug 14, 2024 at 2:32 PM Mike Schinkel wrote:
>> > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks
>> > wrote:
>> > PHP has C as core and has allowed C++ for extensions. Expanding that
>> > su
a build working on their machine for
local development.
And finally, one other (IMO) HUGE benefit of switching to Zig would be that it
would likely be easier for new people to onboard to contributing to the PHP
codebase than if PHP sticks with C or especially if PHP were to instead move to
ere is this:
https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
-Mike
ternet! It’s not even new: we’ve been living
with Unicode for 20 years now."
I'll just leave that right here. :-)
-Mike
P.S. Channeling Larry and Derick:
https://wiki.php.net/rfc/unicode_text_processing
<https://wiki.php.net/rfc/unicode_text_processing>
ntial PHP core implementation, making it less than ideal for testing.
However, doing a userland implementation would be a good proof-of-concept,
allow others to try it, allow others to contribute to the exact syntax and
semantics, and finally a userland implementation could reveal any potential
y used. It becomes self-reinforcing.
Well that would be an easy fix: Provide special treatment for the preferred
algorithms, i.e. their own specific function(s).
-Mike
function. Deciding which are the 20% can be
determined by statistical analysis of public code bases, or where there is no
existing evidence for new functionality, by voters opinions.
-Mike
P.S. BTW, I do acknowledge your earlier point about more functions == more
documentation — the first I'v
gt; and did exactly that. Yes, I am using MD5 as a message digest algorithm.
But just because they were historical artifacts doesn't mean that they should
be frowned on, or removed. `echo` is also a historical artifact, but no one is
arguing we should get rid of this:
echo "Hello World";
And then require developers to use this instead:
fprintf(STDOUT, "Hello World");
¯\_(ツ)_/¯
-Mike
drive
eyeballs, lots of developer websites would be motivated to write articles about
how and why people should remediate those functions.
Something to consider?
-Mike
P.S. Frankly, I really would not want to see md5() nor sha1() removed because
there are valid use-cases for them. I would at least
about standalone functions for
> both, and then when SHA4 comes along (as it inevitably will) another
> standalone function for one of its variants?
Yes. Yes, And Yes.
And ideally within a `\PHP` namespace.
-Mike
P.S. But as we know a standardized `\PHP` namespace is apparently n
against the current to
use it, and no one else would write code that way.
Still, the reason for my comment was to ask we consider a first-class args type
which would enable being able to pass parameters like `{foo: 1, bar: 2}`
instead of `new QueryArgs(foo: 1, bar: 2)`, not to discuss autoloaders.
-Mike
> On Jul 26, 2024, at 9:11 PM, Mike Schinkel wrote:
>
> Kudos to Tim Düsterhus for identifying
> https://www.phptutorial.net/php-tutorial/php-csrf/ and
> https://www.php-einfach.de/php-tutorial/die-wichtigsten-php-funktionen/ but
> his takeaway for an action item was l
y are not willing to
pursue an initiative that proactively seeks to help users remediate and educate
users about security concerns then I would argue *they* do not really care
about security of PHP users but instead are only willing to paying lip service
to it. #fwiw
TLDR;? Use a carrot, not a stick.
-Mike
m is based on
a class:
args QueryArgs {
public ?int $limit = 100;
public ?int $offset = 0;
}
2. Declare a function to use those args, using your `default` keyword when they
are optional:
function myQuery(string $sql, QueryArgs $args = default) {
query($sql, $args);
}
3. And finally, allow a streamlined syntax to pass args:
myQuery("SELECT * FROM table;", {offset:100});
(I do not think we can or even should try to tackle the PSR-4 "every symbol in
its own file" problem here, so I am going to leave that for other potential
RFCs.)
-Mike
>
>
If those _were_ added, I would bikeshed their names to make sure their intent
was 100% clear:
>
insecure_hash() // not secure, makes UIDs quickly
secure_oneway_hash() // uses best practice one-way hash algo
secure_reversible_hash() // uses best practice reversible encryption.
-Mike
ons, even though they do
> the same thing, helps new developers "fall into the pit of success".
>
>
Yes!1000% *THIS*.
-Mike
>
>
> The hash() function isn't quite as confusing as crypt(), but according to
> the manual, it curr
how
Rust, Haskell, and Swift use them.
Unlike for types where we have `mixed`, there is no current globally consistent
alternate to using a blank variable in PHP. The only option is to use an
arbitrary name that other developers won't know the intention of unless the
developer adds comments to the effect.
In summary, although I don't have strong feelings about deprecating classes
named `_`, I do not think the arguments made for disallowing them actually have
any analog in any other languages so I question if there is valid justification
for the deprecation. #jmtcw #fwiw
-Mike
://${handle}") namespaces simply do not have the necessary
visibility scoping features and thus are not an option.
I am currently working on a PoC for packages in userland that uses static
classes exactly in this way. I will hopefully be able to share working code for
that soon.
-Mike
> On Jul 11, 2024, at 10:32 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Thu, 11 Jul 2024, at 12:26, Mike Schinkel wrote:
>> Let me use an analogy. Envision two people on a city council of a small
>> town. One proposes the city should
>> implement a water, powe
t how to use multiple symbol tables in PHP core. And as I
have never modified php-src before, that is going to take some learning.
However, below are responses to Rowan and Larry.
> On Jul 10, 2024, at 8:33 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Wed, 10 Jul 2024, at 07:38, Mi
> On Jul 10, 2024, at 5:50 AM, Jordi Boggiano wrote:
>
> On 2024-07-09 05:24, Mike Schinkel wrote:
>>
>>
>> And this sentence is why I chose to reply to your message. That assumption
>> itself blocks the needs of user-managed apps.
>>
>> (Did
> On Jul 10, 2024, at 2:56 AM, Jordan LeDoux wrote:
>
> On Tue, Jul 9, 2024 at 11:42 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote:
> [snip]
> My one useful takeaway from your email — except that I already knew that —
> was the need to figure out how PHP
> On Jul 9, 2024, at 1:15 PM, Larry Garfield wrote:
> On Sat, Jul 6, 2024, at 1:12 AM, Mike Schinkel wrote:
>> WordPress differs from the apps many *(most?)* developers on PHP
>> Internals work with in the following way:
>>
>> WordPress = *User-managed app*
>
return $tokenGenerator?->send($string) ?? false;
> }
Hi Alexandru,
Great attempt.
Unfortunately, however, it seems around 4.5 slower than strtok():
https://3v4l.org/7lXlM#v8.3.9 <https://3v4l.org/7lXlM#v8.3.9>
> On Jul 8, 2024, at 2:23 PM, Claude Pache wrote:
>> Le 6 ju
is and I have been trying to address.
An autoloader map schema that has enough information for PHP to understand how
to manage the conflicting names, and for the user-managed apps and Composer to
be able to tell PHP what names are conflicting is in fact a solid way forward.
-Mike
file into PHP's page load process provides enough
improvement vs. simply `include()`ing "setup" php files in the first few lines
of `index.php`? I think there would need to be more types of things such a
file could standardize and improve performance for would need to get buy-in and
support for such a change.
To figure that out what those types of things might be would IMO requiring
looking at widely-used PHP apps — both user and developer managed apps — to see
what things could see an actual benefit by defining them in a file like this.
For example, could a database connection be kept alive between page loads on a
high-traffic site? (I have zero idea if this latter would increase performance
or even be a good idea, it is just the first thing that came to mind.)
-Mike
ry of the key semantics of the feature.
>
> Furthermore, the 1.3 (presumed) final version of the RFC is now published at
> <https://wiki.php.net/rfc/static_class>.
Congrats on getting it to this point.
I support this in all but the RFC's restriction on `abstract`, a
am too tired for that.)
And lastly, because WordPress would need to generate this and having a web app
write to a file is a modern security no-no, then `spl_autoload_map()` should
accept multiple different valid values:
spl_autoload_map( string|array|\PHP\AutoloadMap $map);
1. String would be the `.ini` file path
2. Array would be the format returned by parse_ini_file() for parsing an
applicable `.ini` file
3. \PHP\AutoloadMap could be a new class containing the required values in
object format. (Hopefully adding such a class as a third option would not be
controversial to the list members who criticize those developers still wanting
to use arrays as hash maps?)
And that is about it for my feedback today.
-Mike
I was curious to see if I could improve its performance by avoiding the
generator, but that just made it slightly worse, e.g. taking — on rough average
— ~2.75 times as long to run as `strtok()`:
https://3v4l.org/ZVS5Md#v8.3.9 <https://3v4l.org/ZVS5Md#v8.3.9>
#fwiw
-Mike
> On Jul 4, 2024, at 9:16 PM, Michael Morris wrote:
> On Wed, Jul 3, 2024 at 11:11 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote:
> So I've had more time to mull this over, and some research, and I think I
> have an approach.
>
> First, instead of
> On Jul 4, 2024, at 3:05 PM, Chuck Adams wrote:
>
>> On Jul 4, 2024, at 12:02 PM, Mike Schinkel wrote:
>>
>> 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 ter
ant piece of which is a
> machine-readable version.
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."
-Mike
> On Jul 3, 2024, at 10:31 PM, Michael Morris wrote:
>
> On Wed, Jul 3, 2024 at 9:56 PM Mike Schinkel wrote:
>
> There are ~6300 uses of the keyword `import` on GitHub:
>
> https://github.com/search?q=import+language%3APHP+symbol%3A%2F%5Eimport%24%2F&type=cod
mposer.lock` and developers deploy them? Will
that be performant and secure enough?
What about libraries and packages that do not use Composer? How will WordPress
handle this with plugin dependencies?
-Mike
> On Jul 3, 2024, at 8:24 PM, Michael Morris wrote:
> On Wed, Jul 3, 2024 at 7:52 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote:
> Me personally, the opinions that I do not like are the one-symbol-per file
> assumption, which is also a key issue I have with PSR-4.
> On Jul 3, 2024, at 7:17 AM, Stephen Reay wrote:
>
> Sent from my iPhone
>
>> On 1 Jul 2024, at 23:33, Mike Schinkel wrote:
>>
>> Autoloading runs userland code. This means it has the potential conflict
>> between different packages with different auto
> On Jul 1, 2024, at 5:07 PM, Rob Landers wrote:
>
> On Mon, Jul 1, 2024, at 18:22, Mike Schinkel wrote:
>> > On Jul 1, 2024, at 7:57 AM, Arvids Godjuks > > <mailto:arvids.godj...@gmail.com>> wrote:
>> >
>> > TL;DR: As a userland developer,
> On Jul 1, 2024, at 4:54 PM, Jordan LeDoux wrote:
> On Mon, Jul 1, 2024 at 11:09 AM Mike Schinkel <mailto:m...@newclarity.net>> wrote:
>
> > and I'm fairly certain after keeping up with the thread that it is almost
> > universally not what people want. M
> On Jul 1, 2024, at 1:07 PM, Dusk wrote:
>
> On Jul 1, 2024, at 09:22, Mike Schinkel wrote:
>> 2. Autoloading effectively necessitates that every symbol be in its own
>> separate file.
>
> How so? While Composer "recommends" PSR4 autoloading with one cl
vate email, or elsewhere if not appropriate for here.
-Mike
> HARD REMINDER about Python 2 => Python 3 and how that went and is still
> somewhat ongoing.
Totally agree on that.
-Mike
1 - 100 of 926 matches
Mail list logo
