> Could you expand on what you mean by "ambiguous" / "unambiguous" here?
I started the thread "Autoloading functions/consts without a performance impact"
for any other discussion on autoloading. It clarifies what "ambiguous" means.
In my earlier comments, I didn't realize https://wiki.php.net/rfc/
After a quick search, it turns out I've mostly reinvented
https://wiki.php.net/rfc/autofunc which I hadn't remembered.
The `spl_autoload_*()` changes it mentions is what I had in mind
There's been changes to php since then, it's been 7 years,
and this adds thoughts on some implementation details.
> On Jan 2, 2020, at 7:09 PM, tyson andre wrote:
>
>> The problem with using constants is that the value is still hardcoded
>> and if we later want to change to pulling the data from a config file
>> we have to change all the code that uses those constants.
>
> It's possible to work around thi
> The problem with using constants is that the value is still hardcoded
> and if we later want to change to pulling the data from a config file
> we have to change all the code that uses those constants.
It's possible to work around this by using a unique constant name
and define('unique_name',
> On Jan 2, 2020, at 6:14 PM, Bruce Weirdan wrote:
>
> There's also a fourth approach that does not involve any changes to
> PHP: autoload + eval.
> When PHP is looking for your class, in your autoload you load the
> values from config, generate the class source and eval() it.
Yes, I guess that
There's also a fourth approach that does not involve any changes to
PHP: autoload + eval.
When PHP is looking for your class, in your autoload you load the
values from config, generate the class source and eval() it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
> We might eventually benefit from versioned "libraries" of functions that can
>be imported in one command
> which would solve many-a-future-problem by itself.
I'd be in favor of a module system, I just can't think of a good way to migrate
to that with existing limitations.
I'd imagine there wou
Happy New Year Internals!
One of the areas I have been agonizing over in 2019 has been constants —
especially class constants — and Mark Randall's following comment from the
other thread cause me to remember that I had been planned to ask the list to
discuss for a while.
> Begin forwarded mess
> On Jan 1, 2020, at 11:31 PM, Mark Randall wrote:
> In future, I think the optimal solution is opt-in deprecating fallback to the
> root namespace using a declare. We might eventually benefit from versioned
> "libraries" of functions that can be imported in one command which would
> solve many
On Thu, 2 Jan 2020 at 05:37, tyson andre wrote:
> Out of scope of this RFC: I had a thought today about autoloading.
> I'd rather improve function / const autoloading instead of moving to
> classes.
> What if an ambiguous function_name() or const outside the global
> namespace would attempt to au
On Wed, Dec 18, 2019 at 9:47 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on the WeakMap proposal:
> https://wiki.php.net/rfc/weak_maps
>
The WeakMap proposal has been accepted unanimously with 25 votes in favor.
Regards,
Nikita
11 matches
Mail list logo
