Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On Mon, Aug 12, 2019 at 2:56 PM Arnold Daniels 
wrote:

> I've added a list of concerns to the FAQ. These are both taken from the
> discussion as well as concerns I have myself.
>

Along the lines of the 'counterpoint' to short tags, I moved the concerns
into a separate page here:  http://wiki.php.net/pplusplus/concerns
It's linked from the same spot, as well as from the top of the document.

Zeev

Re: [PHP-DEV] P++: FAQ

[Thomas Hruska]

On 8/12/2019 2:06 AM, Benjamin Eberlei wrote:

What would be the plan to boost or change the reputation? How are you going
to find P++ in Google? How are users searching for things with PHP and P++?
What's the documentation going to look like for two languages that share so
much? Specifically from a marketing POV splitting up the language into two
makes no sense at all. Given PHP has no unified marketing message or a
dedicated department it is much better to use the existing brand, with all
its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely
a marketing, teaching and persistence issue. As you say the language is
already the fastest dynamic language with the best runtime. But "starting
over" with 0 brand name and perception is much harder problem than changing
the existing brand, and its not at all technical challenge.


Well it looks like Reddit has already started a reputation for P++:

https://www.reddit.com/r/programming/comments/cor8lv/p_a_strongtyped_php/

The discussion's about as mature as you'd expect the average Reddit 
thread to be.  As a bonus, that link showed up near the top of Google 
Search results for me.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Call for participation: Annotating internal function argument and return types

[Dik Takken]

Hi,

I'd be happy to donate some time to this effort as well. If you just
assign me a file or directory (not too much at once please) I can create
a PR that covers that part of the code base.

Would that work for you?

Regards,
Dik

On 10-08-19 12:56, Nikita Popov wrote:
> Hi,
> 
> Lack of type information for internal functions in Reflection is a
> long-standing issue. In PHP 8 we finally have all the necessary technical
> groundwork done to support argument and return type annotations on internal
> functions at scale.
> 
> The only thing left is to actually add those type annotations ... to many
> hundreds of functions. This is something everyone can help with, as it does
> not need expertise in C.
> 
> I've opened a sample PR to show the process:
> https://github.com/php/php-src/pull/4499
> 
> Here, we take some existing arginfo structures in basic_functions.c and
> convert them into stubs in basic_functions.stub.php. We can take the
> argument names from the existing arginfo. To figure out the types, we need
> to look at the implementation (the php.net documentation tends to lie about
> details).
> 
> For example, the first function, set_time_limit is defined in
> https://github.com/php/php-src/blob/172c71980df0fe4c9d62c3365f0a2cdb139e3e86/main/main.c#L1501.
> We see that it accepts an "l" parameter, which is an int. We see that it
> uses RETVAL_TRUE and RETVAL_FALSE, which means the return value is a bool.
> 
> Once this is done, we need to auto-generate new arginfo data. If you have a
> development setup, this is done automatically when running "make".
> Otherwise, it's possible to manually run "php scripts/dev/gen_stub.php
> ext/standard/basic_functions.stub.php".
> 
> Any help would be appreciated :)
> 
> Regards,
> Nikita
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

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 ignore.
>

I did some writings on that
https://brzuchal.com/posts/packages-in-programming-languages/ was a little
hurry
but tried my best to grasp key aspects of package / module concept in other
languages.

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Mark Randall]

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 former.


I concur with this, I would much rather specify a reference to external 
metadata once-per-file than have it controlled by invisible external state.


If I send an individual file to a co-worker, IMO it should be 
immediately obvious at the top of that file that it belongs to  
package and may depend on that package definition to control its 
behaviour (especially if it gets loaded up with declares or editions).


I'll simply be replacing my ubiquitous strict-types declare with 
whatever was used to reference this package.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Larry Garfield]

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?
> >
> > Individual files could declare their package using this style:
> >  >
> > That would be enough to group a set of files together and make them share
> > eg some private classes, some optional PHP behaviors, etc.
> >
> > The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
> > autoload as a regular class. The corresponding class would then be the
> > place where ppl would declare the engine behavior they want for their
> > package (strict types, etc). To enforce this, the engine could require that
> > the "MyPackage" class implements some interface/extend some base abstract
> > class.
> >
> > Of course, one could hijack a package and declare an unrelated file as
> > part of it, but I don't think that's an issue: the situation is the same as
> > for namespaces, where one can hijack a third party vendor namespace. In
> > practice, it proved not being an issue, and the original author's intent is
> > clear: "this is my namespace/package, if you mess with it, fine, but you're
> > on your own".
> >
> > Nicolas
> >
> 
> FTR I've created a draft-implementation for a package system here:
> https://github.com/php/php-src/pull/4490
> 
> It uses a slightly different approach in that it keeps the package name a
> string (that should usually match the Composer package name) and uses a
> function to register the package.
> 
> The main annoyance is that this requires declaring the package in every
> file, something I would like to avoid. An alternative I played with is to
> allow specifying the package at include time, which would allow the
> autoloader to specify which package a file is part. However, while this is
> more ergonomic for the user, I'm afraid that this will make static analysis
> & IDE scenarios problematic, because they will not be able to easily know
> what the package is in cases that fall outside convention. So in the end,
> an explicit per-file package declaration may be the best we can do.
> 
> Nikita

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 former.

My concern with using a function call is that it introduces/increases the 
potential for a file to say it uses a namespace that isn't yet defined.  What 
happens then?  Fatal?  Autoload trigger?  The code ends up un-packaged 
silently?  (Please not the last one.)

I don't feel like "it's Composer's problem" is a good answer here.  Making the 
package name be a class name at least makes autoloading a natural and well 
understood way to handle the lookup.  There may be other benefits to using a 
class/methods to define a package, or possibly even downsides;  I'm not sure 
there.  More research needed.  Same for avoiding package name collisions; "it's 
FIG's problem" may be an answer, but it seems like a poor one.

In practice I'd expect package definitions to be the obvious example of the 
preloader, but there will always be cases where the preloader is not available 
or cannot be used so we need to consider the performance impact of registering 
packages in every request.

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 ignore.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Thomas Nunninger]

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.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]);

I've finally gotten around to implementing this proposal (
https://github.com/php/php-src/pull/2972) and would like to move forward
with it.

The reason why I'm picking it up again is some feedback I received for the
explicit call-time send-by-ref proposal. The main objection seems to be
that the feature has limited usefulness if it's optional rather than
required, because you still can't be sure that something is a by-value
pass, just because no & is present. At the same time, we can't make this
required anytime soon due to the large BC impact.

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(). There would be no BC impact, while at the
same time projects could benefit from the additional clarity and
performance improvements immediately.



I've read discussions about the notion of a "package" and the way we
should define its boundaries.
What about the following?

Individual files could declare their package using this style:


FTR I've created a draft-implementation for a package system here:
https://github.com/php/php-src/pull/4490

It uses a slightly different approach in that it keeps the package name a
string (that should usually match the Composer package name) and uses a
function to register the package.

The main annoyance is that this requires declaring the package in every
file, something I would like to avoid. An alternative I played with is to
allow specifying the package at include time, which would allow the
autoloader to specify which package a file is part. However, while this is
more ergonomic for the user, I'm afraid that this will make static analysis
& IDE scenarios problematic, because they will not be able to easily know
what the package is in cases that fall outside convention. So in the end,
an explicit per-file package declaration may be the best we can do.



I'm not sure if this was discussed/proposed before:

Why not have a concept similar to autoloaders that resolves a given 
class name to some declare statements.


That way you could implement a composer based resolver that takes a 
class name, (internally) resolves it to a package (based on the 
autoloader configuration in composer.json), and returns an array of the 
specified declare statements.


Developers do not need to specify a package or any declare statements in 
PHP files at all, as PHP (or static analyzers) would be able to ask the 
class-name-to-declare-statements resolver which declare statements a PHP 
file defines.


Alternatively, you could introduce the concept of a 
Package(Specification) class as proposed by Nicolas (but without the 
need to extend and implement it in each package). That way the resolver 
does not return the array of declare statements but an instance of the 
Package(Specification) class that was constructed by the composer-based 
resolver dynamically with the declare statements as defined in 
composer.json.


Not sure: Perhaps you even do not need a new concept of a resolver but 
could extend the concept of autoloaders?


Regards
Thomas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Arnold Daniels]

I've added a list of concerns to the FAQ. These are both taken from the 
discussion as well as concerns I have myself.

https://wiki.php.net/pplusplus/faq#what_are_the_general_concerns

Arnold

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=43s7s)
[43s7s]

On August 12, 2019 at 9:14 GMT, Andrey Hristov  wrote:

Re: [PHP-DEV] P++: FAQ

[Andrey Hristov]

On 12.08.19 г. 12:06 ч., Benjamin Eberlei wrote:

On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans  wrote:


I must admit that the first time I read Zeev’s email I got anxious... but
it is frustrating that PHP has a WAY better runtime than Python and most
other dynamic languages yet is falling out of fashion. It’s strange given
how much better it actually runs (really being unbiased here). One reason
is security perception (which is BS but perception matters) and the second
is arguably some of the historic baggage which makes some folks feel PHP is
hard to master without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify
it and do a cleanup?”. I actually don’t think we lack many features but
rather lots of stuff I would dump like references, array(), global
namespace for functions(?), type juggling in areas where we should be
stricter, etc... I actually think that having a p++ is risky but it is an
opportunity. I think it’s mostly be an opportunity if we’d be careful about
feature bloat and try and be really aggressive about removing things and
cleaning up. We potentially would get the significant benefits of our
runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
maybe not... I actually do think there’s value of a different brand just
because of the BS perception issues...



Its extremely hard imho to be in fashion all the time and it takes
anticipation to get next years fashion right. Or you can just wait to get
in fashion again with the good things you already have and incrementally
improve them.

Nothing a PHP / P++ fork will do changes the fact that PHP is a C-style
language, and Python gets praise for its easy to read and understand
syntax. Nothing will change the fact that PHP architecture is primarily
shared nothing, and the current hype is "shared everything" with Node.js
(yes i know about Swoole et al). But why bother? A language can't be
everything.


This is the old hype. The new hype is shared nothing, as per lambdas. 
Next time you hit a lambda you don't know whether it will be the same 
instance. Also, Node.js can't show it's superiority with lambdas, as the 
runtime environment takes the work of Node. Also paying per wall clock 
CPU not by cycles it doesn't matter if you use async a lot, as long as 
you are not syndicating. This way lambda is again the old style 
serialized programming where Python and PHP excel.


But this is just my view why PHP will beat JS in the serverless era (it 
just needs a little more love to be well supported).


Cheers,
Andrey

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Stephen Reay]

> 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:
>>> 
>>>   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]);
>>> 
>>> I've finally gotten around to implementing this proposal (
>>> https://github.com/php/php-src/pull/2972) and would like to move forward
>>> with it.
>>> 
>>> The reason why I'm picking it up again is some feedback I received for the
>>> explicit call-time send-by-ref proposal. The main objection seems to be
>>> that the feature has limited usefulness if it's optional rather than
>>> required, because you still can't be sure that something is a by-value
>>> pass, just because no & is present. At the same time, we can't make this
>>> required anytime soon due to the large BC impact.
>>> 
>>> 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(). There would be no BC impact, while at the
>>> same time projects could benefit from the additional clarity and
>>> performance improvements immediately.
>>> 
>> 
>> I've read discussions about the notion of a "package" and the way we
>> should define its boundaries.
>> What about the following?
>> 
>> Individual files could declare their package using this style:
>> > 
>> That would be enough to group a set of files together and make them share
>> eg some private classes, some optional PHP behaviors, etc.
>> 
>> The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
>> autoload as a regular class. The corresponding class would then be the
>> place where ppl would declare the engine behavior they want for their
>> package (strict types, etc). To enforce this, the engine could require that
>> the "MyPackage" class implements some interface/extend some base abstract
>> class.
>> 
>> Of course, one could hijack a package and declare an unrelated file as
>> part of it, but I don't think that's an issue: the situation is the same as
>> for namespaces, where one can hijack a third party vendor namespace. In
>> practice, it proved not being an issue, and the original author's intent is
>> clear: "this is my namespace/package, if you mess with it, fine, but you're
>> on your own".
>> 
>> Nicolas
>> 
> 
> FTR I've created a draft-implementation for a package system here:
> https://github.com/php/php-src/pull/4490
> 
> It uses a slightly different approach in that it keeps the package name a
> string (that should usually match the Composer package name) and uses a
> function to register the package.
> 
> The main annoyance is that this requires declaring the package in every
> file, something I would like to avoid. An alternative I played with is to
> allow specifying the package at include time, which would allow the
> autoloader to specify which package a file is part. However, while this is
> more ergonomic for the user, I'm afraid that this will make static analysis
> & IDE scenarios problematic, because they will not be able to easily know
> what the package is in cases that fall outside convention. So in the end,
> an explicit per-file package declaration may be the best we can do.
> 
> Nikita


Is there some specific benefit to passing an array with `name` and `declares` 
keys, over a signature like either

package_declare(‘nikic/php-parser’, strict_types=1, foo=bar); 

or even

package_declare('nikic/php-parser’, [‘strict_types’ => 1, ‘foo’ => bar]); 

I realise this is the epitome of bike shedding, it just seems like a 
non-obvious choice (to me at least) to accept a specifically structured array?

Cheers

Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] P++: FAQ

[Benjamin Eberlei]

On Sun, Aug 11, 2019 at 6:32 AM Andi Gutmans  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion. It’s strange given
> how much better it actually runs (really being unbiased here). One reason
> is security perception (which is BS but perception matters) and the second
> is arguably some of the historic baggage which makes some folks feel PHP is
> hard to master without a manual (we have the best manual).
>
> So many times I have thought “is it time to just take an axe and simplify
> it and do a cleanup?”. I actually don’t think we lack many features but
> rather lots of stuff I would dump like references, array(), global
> namespace for functions(?), type juggling in areas where we should be
> stricter, etc... I actually think that having a p++ is risky but it is an
> opportunity. I think it’s mostly be an opportunity if we’d be careful about
> feature bloat and try and be really aggressive about removing things and
> cleaning up. We potentially would get the significant benefits of our
> runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
> maybe not... I actually do think there’s value of a different brand just
> because of the BS perception issues...
>

Its extremely hard imho to be in fashion all the time and it takes
anticipation to get next years fashion right. Or you can just wait to get
in fashion again with the good things you already have and incrementally
improve them.

Nothing a PHP / P++ fork will do changes the fact that PHP is a C-style
language, and Python gets praise for its easy to read and understand
syntax. Nothing will change the fact that PHP architecture is primarily
shared nothing, and the current hype is "shared everything" with Node.js
(yes i know about Swoole et al). But why bother? A language can't be
everything.

A different brand might help get a different perception, BUT it also has no
reputation at all at the beginning. If you say "better PHP" (or the likes),
it gets PHPs "reputation" by affiliation automatically and you are at the
same point as before.

What would be the plan to boost or change the reputation? How are you going
to find P++ in Google? How are users searching for things with PHP and P++?
What's the documentation going to look like for two languages that share so
much? Specifically from a marketing POV splitting up the language into two
makes no sense at all. Given PHP has no unified marketing message or a
dedicated department it is much better to use the existing brand, with all
its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely
a marketing, teaching and persistence issue. As you say the language is
already the fastest dynamic language with the best runtime. But "starting
over" with 0 brand name and perception is much harder problem than changing
the existing brand, and its not at all technical challenge.

greetings
Benjamin


>
> Andi
>
> Get Outlook for iOS
>
> 
> From: Zeev Suraski 
> Sent: Friday, August 9, 2019 12:54 PM
> To: Internals
> Subject: [PHP-DEV] P++: FAQ
>
> During the discussion of the P++ proposal (
> https://externals.io/message/106453), it became painfully clear that this
> idea did little, so far, to bring peace to the galaxy.
>
> However, based on a lot of the feedback, both on internals@ and elsewhere
> -
> it seems that a lot of people simply didn't really understand what this
> idea was actually proposing to do. I'll take the blame for that - by not
> making the idea sufficiently clear.
>
> I went on and create an FAQ, that attempts to address many of the questions
> and common misconceptions that repeatedly came up.
>
> It's available here: https://wiki.php.net/pplusplus/faq
>
> Before you read it, I want to stress that this is an attempt to
> provide *everyone
> with a good deal, and nobody with a raw deal. *It doesn't mean it's
> successful at that (although I think it is) - but the motivation is clean
> and positive. If & when you read this FAQ, please try to read it without
> any preconceived notions.
>
> If there are additional questions that you think are missing, please let me
> know - or better yet, if you're up for constructively adding them - go
> ahead and do that.
>
> Thanks,
>
> Zeev
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Kris Craig]

On Fri, Aug 9, 2019 at 6:25 AM Robert Korulczyk  wrote:

> > Disabling short tags now is done with "an explicit directive" (there has
> to be a specific ini file with a specific setting 'short_open_tag = 0').
> > Isn't this the same "situation when you create a separate file with an
> explicit directive"?
>
> No, it's not. `php.ini` is outside of project responsibility - as a
> developer you don't really configure this in any way, your application does
> not
> have any explicit directive to disable/enable short open tags. You just
> accidentally using feature that could lead to code leak.
> In your example with `engine` directive you explicitly disable PHP engine
> by creating dedicated file for that purpose - there is no way do to this by
> accident and then does not notice it.
>
>
> > If a coder (or IDE) has written ' unless tested the effect (a part of code not being parsed/executed) will be
> > exactly the same if the feature suddenly disappeared (unless the
> additional checks in the 'v2 RFC' which on the other hand would make the
> engine a
> > tiny bit slower but probably have to be implemented to avoid such
> accidents).
>
> At least the this behavior will be consistent - you will not have cases
> when code works fine on one environment and leak on another.
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
So far, the RFC only has 55% support, which means it's not going to pass
this time, anyway, unless there's a vote shift in the next 8 days.

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

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 to allow specifying declare directives for a whole library or
> > project using:
> >
> > namespace_declare('Vendor\Lib', ['strict_types' => 1]);
> >
> > I've finally gotten around to implementing this proposal (
> > https://github.com/php/php-src/pull/2972) and would like to move forward
> > with it.
> >
> > The reason why I'm picking it up again is some feedback I received for
> the
> > explicit call-time send-by-ref proposal. The main objection seems to be
> > that the feature has limited usefulness if it's optional rather than
> > required, because you still can't be sure that something is a by-value
> > pass, just because no & is present. At the same time, we can't make this
> > required anytime soon due to the large BC impact.
> >
> > 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(). There would be no BC impact, while at the
> > same time projects could benefit from the additional clarity and
> > performance improvements immediately.
> >
>
> I've read discussions about the notion of a "package" and the way we should
> define its boundaries.
> What about the following?
>
> Individual files could declare their package using this style:
> 
> That would be enough to group a set of files together and make them share
> eg some private classes, some optional PHP behaviors, etc.
>
>
Why suggesting use of declare for that?
Wouldn't a new "package" keyword be more appropriate for that?
For eg.:
 The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
> autoload as a regular class. The corresponding class would then be the
> place where ppl would declare the engine behavior they want for their
> package (strict types, etc). To enforce this, the engine could require that
> the "MyPackage" class implements some interface/extend some base abstract
> class.
>
> Of course, one could hijack a package and declare an unrelated file as part
> of it, but I don't think that's an issue: the situation is the same as for
> namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent is
> clear: "this is my namespace/package, if you mess with it, fine, but you're
> on your own".
>
> Nicolas
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[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.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]);
>>
>> I've finally gotten around to implementing this proposal (
>> https://github.com/php/php-src/pull/2972) and would like to move forward
>> with it.
>>
>> The reason why I'm picking it up again is some feedback I received for the
>> explicit call-time send-by-ref proposal. The main objection seems to be
>> that the feature has limited usefulness if it's optional rather than
>> required, because you still can't be sure that something is a by-value
>> pass, just because no & is present. At the same time, we can't make this
>> required anytime soon due to the large BC impact.
>>
>> 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(). There would be no BC impact, while at the
>> same time projects could benefit from the additional clarity and
>> performance improvements immediately.
>>
>
> I've read discussions about the notion of a "package" and the way we
> should define its boundaries.
> What about the following?
>
> Individual files could declare their package using this style:
> 
> That would be enough to group a set of files together and make them share
> eg some private classes, some optional PHP behaviors, etc.
>
> The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
> autoload as a regular class. The corresponding class would then be the
> place where ppl would declare the engine behavior they want for their
> package (strict types, etc). To enforce this, the engine could require that
> the "MyPackage" class implements some interface/extend some base abstract
> class.
>
> Of course, one could hijack a package and declare an unrelated file as
> part of it, but I don't think that's an issue: the situation is the same as
> for namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent is
> clear: "this is my namespace/package, if you mess with it, fine, but you're
> on your own".
>
> Nicolas
>

FTR I've created a draft-implementation for a package system here:
https://github.com/php/php-src/pull/4490

It uses a slightly different approach in that it keeps the package name a
string (that should usually match the Composer package name) and uses a
function to register the package.

The main annoyance is that this requires declaring the package in every
file, something I would like to avoid. An alternative I played with is to
allow specifying the package at include time, which would allow the
autoloader to specify which package a file is part. However, while this is
more ergonomic for the user, I'm afraid that this will make static analysis
& IDE scenarios problematic, because they will not be able to easily know
what the package is in cases that fall outside convention. So in the end,
an explicit per-file package declaration may be the best we can do.

Nikita

Re: [PHP-DEV] P++: FAQ

[Peter Bowyer]

On Sun, 11 Aug 2019 at 05:32, Andi Gutmans  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion.


In the case of Python, it seems to be the numerical, scientific and linear
algebra libraries that's driving its popularity.

I agree PHP has a way better runtime and it is frustrating to see this
happen.


> It’s strange given how much better it actually runs (really being unbiased
> here).
>

If PHP doesn't have the libraries people want, and if PHP is perceived as a
web scripting language rather than a general-purpose dynamic language, then
the better runtime isn't going to convince a large audience that it's the
best tool for the job.

Peter

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Nicolas Grekas]

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:
>
> namespace_declare('Vendor\Lib', ['strict_types' => 1]);
>
> I've finally gotten around to implementing this proposal (
> https://github.com/php/php-src/pull/2972) and would like to move forward
> with it.
>
> The reason why I'm picking it up again is some feedback I received for the
> explicit call-time send-by-ref proposal. The main objection seems to be
> that the feature has limited usefulness if it's optional rather than
> required, because you still can't be sure that something is a by-value
> pass, just because no & is present. At the same time, we can't make this
> required anytime soon due to the large BC impact.
>
> 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(). There would be no BC impact, while at the
> same time projects could benefit from the additional clarity and
> performance improvements immediately.
>

I've read discussions about the notion of a "package" and the way we should
define its boundaries.
What about the following?

Individual files could declare their package using this style: