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 her
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 address
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 warning
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 able
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 callb
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 integra
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 to
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 incre
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) wh
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\
> doc
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 lo
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
> ha
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 co
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 ea
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" th
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 op
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 sam
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 proposal
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 director
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 funct
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
> pro
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:
>
> name
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
