I would like to make a wild proposal.
## Proposal
Similar to spl_autoload_register(), we would provide a function that
allows to register a callback to provide the declares / edition /
compatibility information for a given file, before this file is
loaded.
To address performance concerns:
- The
śr., 14 sie 2019 o 12:17 Michał Brzuchalski
napisał(a):
>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>> > from src/Foo.php or src/__nsmeta.php if th
On 14/08/2019 11:17, Michał Brzuchalski wrote:
Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?
/composer.json
/src/Foo.php
/src/Foo/ <- all package classes should go here?
That would be one pl
śr., 14 sie 2019 o 12:11 Rowan Collins napisał(a):
> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't. It would include src/Foo.php, a
On 14/08/2019 11:07, Michał Brzuchalski wrote:
Exactly so how would it know from string name either it should load class
from src/Foo.php or src/__nsmeta.php if there is no information?
It wouldn't. It would include src/Foo.php, and that would have the
definition of something with the name "F
śr., 14 sie 2019 o 11:49 Rowan Collins napisał(a):
> > You suggest that it would trigger autoload to load "MyVendor\MyPackage"
> > but current autoload machinery is able to load only classes,
> > not even functions or consts! cause it gets the only class name now.
> > It would need to be changed
On 14/08/2019 10:27, Michał Brzuchalski wrote:
But that's conflicting with you above idea for package definition like
that:
That's not what I'm suggesting; perhaps my example could have been
clearer. I envisage two new keywords:
- To put some code in a package, you would write "package Foo
śr., 14 sie 2019 o 11:01 Rowan Collins napisał(a):
> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference.
On 14/08/2019 07:45, Michał Brzuchalski wrote:
It doesn't have to be a new syntax if we agree to put package definiction
in sort of separate configuration file.
With the exception of INI files, all your examples are new syntax, as
far as the internal mechanisms in PHP are concerned. They have
On 13/08/2019 23:28, Mark Randall wrote:
On 13/08/2019 21:26, Rowan Collins wrote:
Ah, that makes sense. Does that necessarily mean we need a dummy
class, though? The autoloading logic in the engine knows that it
called the autoload callback expecting a package definition, so can
count as succ
Hi Rowan,
wt., 13 sie 2019 o 22:26 Rowan Collins napisał(a):
> On 13/08/2019 18:45, Mark Randall wrote:
> > I thought about this as my first consideration, however it effectively
> > requires that the PHP code within the package class is fully parsed
> > and executed in order for it to retrieve
On 13/08/2019 21:26, Rowan Collins wrote:
Ah, that makes sense. Does that necessarily mean we need a dummy class,
though? The autoloading logic in the engine knows that it called the
autoload callback expecting a package definition, so can count as
success that the package is now defined.
In
On 13/08/2019 18:40, Liam Hammett wrote:
This already works (except for the "encoding" declare, which would make
little sense halfway down a file).
spl_autoload_register(function ($className) {
declare(strict_types=1) {
include $className . '.php';
}
});
This, howeve
On 13/08/2019 18:45, Mark Randall wrote:
I thought about this as my first consideration, however it effectively
requires that the PHP code within the package class is fully parsed
and executed in order for it to retrieve the data.
Consider pre-loading where the code is compiled, but not run, i
> On 14 Aug 2019, at 00:05, Rowan Collins wrote:
>
>> On 13/08/2019 12:01, Mark Randall wrote:
>>> On 13/08/2019 10:02, Rowan Collins wrote:
>>> I really like this approach. It allows a package definition file to exist,
>>> without either the language or the header of each file having to defi
On 13/08/2019 18:05, Rowan Collins wrote:
This seems to be more complicated than Nicolas's version, and involve
much more special magic, like the name __nsmeta, and the class that does
nothing. I'm also not clear on how you're picturing the relationship
between namespaces and packages.
I was
On 13/08/2019 12:01, Mark Randall wrote:
On 13/08/2019 10:02, Rowan Collins wrote:
I really like this approach. It allows a package definition file to
exist, without either the language or the header of each file having
to define its location.
#
# File: /lib/company/project1/a/b/MyClass.php
#
On 13/08/2019 10:02, Rowan Collins wrote:
I really like this approach. It allows a package definition file to
exist, without either the language or the header of each file having to
define its location.
#
# File: /lib/company/project1/a/b/MyClass.php
#
Caveat would be for situations that do n
On 12/08/2019 09:17, Nicolas Grekas wrote:
Individual files could declare their package using this style:
I really like this approach. It allows a package definition file to
exist, without either the language or the header of each file having to
define its location.
Importantly, although i
Hi Larry,
pon., 12 sie 2019 o 15:45 Larry Garfield
napisał(a):
>
> Has anyone done in-depth research into how other languages handle
> packages, and what advantages packages would have over just our existing
> nested namespaces? I feel like there's ample prior art here that we should
> not igno
On 12/08/2019 14:45, Larry Garfield wrote:
I don't think declaring the package in each file is necessarily bad. Every
language I've worked in either has you declare a package explicitly or implies
it off of the file system and you don't get any say in the matter. Of the two,
I prefer the for
On Mon, Aug 12, 2019, at 3:26 AM, Nikita Popov wrote:
> On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
> > I've read discussions about the notion of a "package" and the way we
> > should define its boundaries.
> > What about the following?
> >
> > Individu
Hi,
Am 12.08.19 um 10:26 schrieb Nikita Popov:
On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
Le lun. 11 déc. 2017 à 14:44, Nikita Popov a
écrit :
Some time ago I introduced the following proposal for namespace-scoped
declares:
https://wiki.php.
> On 12 Aug 2019, at 15:26, Nikita Popov wrote:
>
> On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>> Le lun. 11 déc. 2017 à 14:44, Nikita Popov a
>> écrit :
>>
>>> Some time ago I introduced the following proposal for namespace-scoped
>>> declares
Hi Nicolas,
pon., 12 sie 2019 o 10:17 Nicolas Grekas
napisał(a):
> Le lun. 11 déc. 2017 à 14:44, Nikita Popov a écrit
> :
>
> > Some time ago I introduced the following proposal for namespace-scoped
> > declares:
> >
> > https://wiki.php.net/rfc/namespace_scoped_declares
> >
> > The idea is
On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Le lun. 11 déc. 2017 à 14:44, Nikita Popov a
> écrit :
>
>> Some time ago I introduced the following proposal for namespace-scoped
>> declares:
>>
>> https://wiki.php.net/rfc/namespace_scoped_declares
>>
Le lun. 11 déc. 2017 à 14:44, Nikita Popov a écrit :
> 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 13/12/2017 07:12, Michał Brzuchalski wrote:
Andreas, we're touching namespaces which is a hard subject, but if I could
fly away with my thoughts
I'd propose to introduce something called for eg. a package
My thoughts were actually going along the same lines: basically, the
current implemen
""Michal Brzuchalski"" wrote in message
news:cabdc3wrz8qu_hgsbtjgbwwct8yplxgchonee9nijkwcderu...@mail.gmail.com...
13.12.2017 11:44 "Tony Marston" napisal(a):
""Michal Brzuchalski"" wrote in message news:CABdc3WpomNLz+vX_m0B0wQ3u
cimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com...
2017-12-13 1:1
13.12.2017 11:44 "Tony Marston" napisał(a):
""Michal Brzuchalski"" wrote in message news:CABdc3WpomNLz+vX_m0B0wQ3u
cimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com...
> 2017-12-13 1:16 GMT+01:00 Andreas Hennings :
>
>
> Why? Because users use PSR-4 so then they're src folder looks more like:
>
?
""Michal Brzuchalski"" wrote in message
news:cabdc3wpomnlz+vx_m0b0wq3ucimiw8xw4ea_sgd-ptdgfv-...@mail.gmail.com...
2017-12-13 1:16 GMT+01:00 Andreas Hennings :
Why? Because users use PSR-4 so then they're src folder looks more like:
?
You are assuming that everybody is using PSR-4. That
"Andreas Hennings" wrote in message
news:CAH0Uv3FnYf_c7in4_6AmDO5pUZHsgU0m5scjU5oRz2kTAJ=+b...@mail.gmail.com...
I agree with all of Stanislav's emails in this thread so far.
On 12 December 2017 at 14:43, Nikita Popov wrote:
On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev
wrote:
PH
2017-12-13 6:04 GMT+01:00 Michał Brzuchalski :
>
>
> 2017-12-13 5:38 GMT+01:00 Michał Brzuchalski :
>
>>
>>
>> 2017-12-13 5:24 GMT+01:00 Andreas Hennings :
>>
>>> On 13 December 2017 at 05:04, Michał Brzuchalski
>>> wrote:
>>> >
>>> > If we're going to introduce someday a namespace file, then IMO
On 11.12.17 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:
namespace_declare('Vendo
2017-12-13 5:38 GMT+01:00 Michał Brzuchalski :
>
>
> 2017-12-13 5:24 GMT+01:00 Andreas Hennings :
>
>> On 13 December 2017 at 05:04, Michał Brzuchalski
>> wrote:
>> >
>> > If we're going to introduce someday a namespace file, then IMO it
>> should not
>> > be putted outside namespace folder.
>> >
2017-12-13 5:24 GMT+01:00 Andreas Hennings :
> On 13 December 2017 at 05:04, Michał Brzuchalski
> wrote:
> >
> > If we're going to introduce someday a namespace file, then IMO it should
> not
> > be putted outside namespace folder.
> > For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php shoul
On 13 December 2017 at 05:04, Michał Brzuchalski wrote:
>
> If we're going to introduce someday a namespace file, then IMO it should not
> be putted outside namespace folder.
> For eg class Acme\Animal\Cat in src/Acme/Animal/Cat.php should have
> namespace file in src/Acme/Aniimal/namespace.php
>
2017-12-13 1:16 GMT+01:00 Andreas Hennings :
> I agree with all of Stanislav's emails in this thread so far.
>
> On 12 December 2017 at 14:43, Nikita Popov wrote:
> > On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev >
> > wrote:
> >
> >> Hi!
> >>
> >> > The idea is to allow specifying declare
I agree with all of Stanislav's emails in this thread so far.
On 12 December 2017 at 14:43, Nikita Popov wrote:
> On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>> > The idea is to allow specifying declare directives for a whole library or
>> > project using:
>> >
>> >
Hi!
> There is no dependence on loading order. The implementation is careful
> to ensure that the used declare state is consistent. It's not possible
> to call namespace_declare() twice on the same namespace. It's not
> possible to first load some files from a namespace, do the
> namespace_declare
On Tue, Dec 12, 2017 at 8:46 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > The idea is to allow specifying declare directives for a whole library or
> > project using:
> >
> > namespace_declare('Vendor\Lib', ['strict_types' => 1]);
>
> I am not sure I like this. Namespace is a prefix to a class n
Hi!
> The idea is to allow specifying declare directives for a whole library or
> project using:
>
> namespace_declare('Vendor\Lib', ['strict_types' => 1]);
I am not sure I like this. Namespace is a prefix to a class name.
Anybody can declare a class with any name, and the side-effect that t
On Mon, Dec 11, 2017 at 4:46 PM, Sara Golemon wrote:
> On Mon, Dec 11, 2017 at 8:43 AM, 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 speci
On Mon, Dec 11, 2017 at 8:43 AM, 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:
>
>
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
project using:
namespace_declare('Vendor\Lib', ['strict_types' => 1
On 23/09/2016 12:41, Nikita Popov wrote:
Hi internals!
I'd like to propose the ability of specifying declare directives like
"strict_types" at the namespace level.
The broader context of this proposal is to provide a simple and usable
mechanism that will allow developers to opt-in to stricter l
Hi Stas,
I agree with you on all of this.
Stanislav Malyshev wrote:
Hi!
The broader context of this proposal is to provide a simple and usable
mechanism that will allow developers to opt-in to stricter language
semantics on a per-library (or more specifically, per-namespace) basis,
thus allev
Hi!
> If you are concerned about libraries modifying how code is run, the
> same theoretical problem exists with libraries that register
> autoloaders - 'omg they can totally change what code is even going to
> be run, let alone the precise semantic behaviour'.
Autoloaders do not change language
On Fri, Sep 23, 2016 at 11:58 PM, Dan Ackroyd
wrote:
> On 23 September 2016 at 20:45, Stanislav Malyshev
> wrote:
>
> > Imagine how
> > fun it is if somebody's action in different code module wouldn't just
> > mess up some data - it would actually break your code by changing
> > language semanti
On 23 September 2016 at 20:45, Stanislav Malyshev wrote:
> Imagine how
> fun it is if somebody's action in different code module wouldn't just
> mess up some data - it would actually break your code by changing
> language semantics for your code!
If you are concerned about libraries modifying ho
On Friday, September 23, 2016, Nikita Popov wrote:
> Hi internals!
>
> I'd like to propose the ability of specifying declare directives like
> "strict_types" at the namespace level.
>
> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers t
>From the RFC:
> it might be beneficial to add a supports_declare() function, which allows you
> to determine whether a certain declare directive is supported, without
> resorting to a PHP version check
Even if we don't have any directives that need to be checked yet, I
think that would be a go
On Fri, Sep 23, 2016 at 9:45 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > The broader context of this proposal is to provide a simple and usable
> > mechanism that will allow developers to opt-in to stricter language
> > semantics on a per-library (or more specifically, per-namespace) basis,
> > thu
Hi!
> keep in mind those 20 bits that are different in every file!". But after
> delocalizing it, all hope is lost - you never know what the code in the
> file actually means - because somebody could write code in completely
> different file, maybe even JSON composer configuration or some other
>
Hi!
> The broader context of this proposal is to provide a simple and usable
> mechanism that will allow developers to opt-in to stricter language
> semantics on a per-library (or more specifically, per-namespace) basis,
> thus alleviating backwards compatibility and library interoperability
> con
Hi internals!
I'd like to propose the ability of specifying declare directives like
"strict_types" at the namespace level.
The broader context of this proposal is to provide a simple and usable
mechanism that will allow developers to opt-in to stricter language
semantics on a per-library (or more
56 matches
Mail list logo
