On Tue, Jul 30, 2019 at 4:08 PM Nikita Popov wrote:
> Thanks everyone for your responses!
>
> I think the discussion resolves around two primary concerns, so let me
> address them in turn.
>
> The first is the general approach of using declares as a
> language-evolution mechanism. The concern
Hi!
> I strongly doubt that there is anything that people could say that
> would alleviate your concern.
There's a lot of things people could say - for example, a proposal that
does not have the same flaws. If you are fixed on having this proposal
unmodified, then yes, my concerns are not
On Sun, 28 Jul 2019 at 20:21, Stanislav Malyshev wrote:
>
> Did you actually try to read my argument, of just
> decided to strawman it from the start?
I strongly doubt that there is anything that people could say that
would alleviate your concern.
I could say how nicely my IDE gives me a
Hi!
> If we want to evolve the language without breaking backwards compatibility,
> we need to provide a way for gradual migration of the ecosystem: A library
> should be able to opt-in to breaking changes, while remaining usable by
> downstream consumers. Conversely, an application should be
On Tue, 30 Jul 2019 at 17:27, Mark Randall wrote:
> At the point we're talking about composer integrating callbacks,
> preloading lists etc, isn't it about time that an spl_autoload_list was
> added that accepted the standard composer classmap [class_id => path]
> and forewent most autoload
On 30/07/2019 15:55, Rowan Collins wrote:
Yes, I was thinking of something more like Composer packages, rather than
like JS modules: code would mostly work as presently, but with some notion
of being "owned" by a particular package. This doesn't mean all the
functions of Composer would be
On Tue, 30 Jul 2019 at 15:08, Nikita Popov wrote:
> 5. Introduce a first-class module/package concept and support per-package
> declares. This is arguably the closest fit for what is needed, but also the
> most complex solution. This is a fairly big problem space and I personally
> do not want
Thanks everyone for your responses!
I think the discussion resolves around two primary concerns, so let me
address them in turn.
The first is the general approach of using declares as a language-evolution
mechanism. The concern here is that each additional declare fragments the
language and
Hi Rowan,
wt., 30 lip 2019 o 10:48 Rowan Collins napisał(a):
> I think there's some confusion here, because establishing the concept of a
> package as separate from a namespace is exactly what I proposed.
>
> Here's a previous message (technically in the same thread, but from 18
> months ago)
On Tue, 30 Jul 2019 at 09:12, Michał Brzuchalski
wrote:
> 1) Packages should be non-hierarchical. Perhaps most simply a package name
>> could have exactly two parts, like in composer, so it's clear that there is
>> no implied relationship between two packages.
>>
>
> IMO this would create a lot
On Tue, Jul 30, 2019 at 10:12 AM Michał Brzuchalski
wrote:
> IMO this would create a lot of problems cause name in Composer Package
> doesn't reflect used namespace declared in autoload, for eg.
>
> Composer package name => used namespace
> ---
> ocramius/package-version => PackageVersions\
>
Hi Rowan,
niedz., 28 lip 2019 o 12:15 Rowan Collins
napisał(a):
> 1) Packages should be non-hierarchical. Perhaps most simply a package name
> could have exactly two parts, like in composer, so it's clear that there is
> no implied relationship between two packages.
>
IMO this would create a
Hi,
niedz., 28 lip 2019 o 05:17 Stanislav Malyshev
napisał(a):
> > Based on the received feedback, I plan to change this proposal from being
> > "namespace-scoped" to being "directory-scoped" instead. This should both
>
> I don't think it improves much, in my opinion, and it also introduces
>
Hi!
>> I look at the success of how strict types was brought in, in a way
> It was a classic compromise that neither side of the debate hated,
> but neither really loved either, and the subtleties of how each mode
> works are likely to be sources of confusion for years to come. I am
> far from
On 28 July 2019 18:56:24 BST, Dan Ackroyd wrote:
>I look at the success of how strict types was brought in, in a way
>that allowed for zero breaking changes for existing code, and think it
>was a massively successful way of improving the language without
>causing problems.
I think it's a) very
Hi!
> As we've seen with the declare for strict types, libraries that want
> to have strict mode, and libraries that want to have more type
> juggling, are perfectly fine to live alongside each other, and can be
> used just fine.
You are assuming all the code is neatly organized in "libraries"
On Sun, 28 Jul 2019 at 04:17, Stanislav Malyshev wrote:
>
> We've decided not to do INI options to change language behavior,...
> because they are - especially when applying to more than local
> file - essentially low-grade INI options
I don't agree. What's being proposed are not low-grade INI
On 25 July 2019 14:34:07 BST, Nikita Popov wrote:
>Based on the received feedback, I plan to change this proposal from
>being
>"namespace-scoped" to being "directory-scoped" instead. This should
>both
>resolve some of the concerns and make the proposal more flexible: Not
>all
>code sharing the
nday, July 28, 2019 6:54 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
>
> On 27/07/2019 09:33, Rasmus Schultz wrote:
> > On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote:
> >> Based on the received feedback,
Hi!
> I plan to pick up this proposal again. I think the motivation here has
> become more pressing in the meantime. The strict_operators proposal is
> under discussion, and Rowan's "locked classes" essentially concluded with
> "doing this with a declare is better". I also think that this
On 27/07/2019 09:33, Rasmus Schultz wrote:
On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote:
Based on the received feedback, I plan to change this proposal from being
"namespace-scoped" to being "directory-scoped" instead
Personally I'm not a huge fan of using implicit hierarchical
On Thu, Jul 25, 2019 at 3:34 PM Nikita Popov wrote:
...
> Based on the received feedback, I plan to change this proposal from being
> "namespace-scoped" to being "directory-scoped" instead
...
I think that's a better approach.
But please consider doing this without adding another global
On Mon, Dec 11, 2017 at 2:43 PM Nikita Popov wrote:
> Hi internals!
>
> Some time ago I introduced the following proposal for namespace-scoped
> declares:
>
> https://wiki.php.net/rfc/namespace_scoped_declares
>
> The idea is to allow specifying declare directives for a whole library or
>
On 11.12.2017 at 14:43, Nikita Popov wrote:
> Some time ago I introduced the following proposal for namespace-scoped
> declares:
>
> https://wiki.php.net/rfc/namespace_scoped_declares
>
> The idea is to allow specifying declare directives for a whole library or
> project using:
>
>
On 11/12/2017 13:43, Nikita Popov wrote:
Namespace-scoped declares are perfectly suited to resolve this problem. We
can introduce a require_explicit_send_by_ref declare directive to make the
call-site annotation required, and libraries/projects can easily opt-in to
it using namespace_declare().
25 matches
Mail list logo
