Re: [PHP-DEV] Namespaces in Core

[Remi Collet]

Le 06/02/2017 à 18:21, Fleshgrinder a écrit :
> Hey guys! :)
> 
> First: I like namespaces in Core but here me out!
> 
> https://wiki.php.net/rfc/libsodium

I think the Sodium RFC vote is not about namespace but rather about
breaking everything which already use the pecl extension.

This extension exists for some time now,
and I don't think we have to break it.



Remi.




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Namespaces in Core

[Stanislav Malyshev]

Hi!

> New classes within 7.2 (e.g. \HashContext) to be moved without concern
> for BC (e.g. \php\Hash\HashContext)
> 
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works In general, I
don't see a point. New exts/features - sure.

> "Aliasing" could be potentially accomplished in a few ways:
> 1. Literally just class_alias().  Put another copy of the
> zend_class_entry into the EG(class_table) under a different name.
> 2. "Auto-use": Compile-time analysis of classname: "Is it in this list
> of BC classes? Implicitly map it."
> 3. ...?
> 
> I like #2 because we can raise compile-time deprecation warnings and
> we don't introduce any runtime overhead for most cases.
> 
> Obviously, no removal of support for non-namespaced names until AT LEAST PHP 
> 8.0
> 
> This two big unanswered questions for me before I'd put this into an RFC are:
> 1. How to achieve BC in the best way
> 2. What to do about functions/constants? Instinct says move 'em just
> like classes.

I don't really want \PHP\Core\Constants\E_NOTICE. This looks like
annoying parts of Java too much. I mean, namespaces are great, I use
them every day, they are super-helpful - but that doesn't mean we should
put everything in deep namespaces - especially things that are already
quite fine without them.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Namespaces in Core

[Stanislav Malyshev]

Hi!

> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.

Agree. If we ever need namespace for mongodb extension, it should be
mongodb (choose capitalization to your liking), not php\mongodb - php\
should be things that are really php core or specifically deal with
aspects of php as a language - tokenizer, syntax, etc.

And having different NS for extensions in core vs. PECL makes no sense
to me either - especially given that for any user of distros this
distinction is completely immaterial.
-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2017-02-06

[lp_benchmark_robot]

Results for project PHP master, build date 2017-02-06 14:02:42-08:00
commit: 31332d0
previous commit:795a4c1
revision date:  2017-02-06 01:47:09+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.18% -0.52% -0.31%  
  7.40%
:-|   Drupal 7.36 cgi -T1  0.17% -0.42%  0.00%  
  4.42%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16% -0.16%  1.01%  
  2.93%
:-|   bench.php cgi -T100  0.01%  0.15% 38.13%  
 -7.08%
:-)  micro_bench.php cgi -T10  0.01%  1.28% 15.59%  
  0.69%
:-)  mandelbrot.php cgi -T100  0.01%  4.08% 33.59%  
 -0.98%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2017-02-06/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Namespaces in Core

[Sara Golemon]

On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov  wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.
>
Okay, I'm pickin' up what yer layin' down.  Perhaps the question then
should be asked in the other direction:

Given PHP's long history and fanatical dedication to BC, should all
bundled/core classes/functions/constants ALWAYS remain in the root
namespace with a strong advisory to userspace libraries and
applications to use vendor namespacing (which by and large, is
precisely the status quo).

If that makes sense, then that's another reason not to bring Sodium in
as a namespaced library of functions.

-Sara

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

Re: [PHP-DEV] Namespaces in Core

[Michał Brzuchalski]

Idea with PHP prefix is quite interesting, but as Nikita said only for PHP
related features.
There is one missing thing in those proposals.
Let's make PHP great again! Let it be `PHP\` prefix :)
To be camel or not to be? - solved!

2017-02-06 22:01 GMT+01:00 Fleshgrinder :

> On 2/6/2017 9:47 PM, Nikita Popov wrote:
> > I'm strongly against use of the PHP namespace as a blanket namespace
> >  for bundled PHP extensions. The PHP namespace should be used only
> > for functionality that is actually in some way related to PHP. For
> > example, the php-ast extension could reasonably be namespaced as
> > php\ast, as it provides an AST for PHP specifically. Similarly the
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> >
> > Extensions which are not of this type should not live in the PHP
> > namespace, because they don't have anything specifically to do with
> > php, apart from the circumstance that they happen to be bundled at
> > the current point in time. Remember that extension may move from
> > being bundled to being in PECL and vice versa. If we decide to bundle
> > the MongoDB extension with php, would we rename the currently used
> > MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> > PECL, would the namespace go back to just MongoDB? Or would it stay
> > PHP\MongoDB, despite not being part of PHP anymore? Should all new
> > extensions be written with a PHP namespace to account for the
> > possibility of the extension being bundled with PHP at a later point
> >  in time (even if there are no concrete plans to do so)?
> >
> > I would answer No to these questions. The namespace MongoDB is not,
> > as you say, "random", it is *meaningful*. The namespace PHP is (with
> >  the exceptions in the first paragraph notwithstanding) meaningless
> > and an artifact of the distribution mechanism, a mechanism which may
> >  change over time.
> >
> > Regards, Nikita
> >
>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since we would never require to even look at the auto-loader if
> the namespace starts with php.
>
> Obviously this could be solved for C extensions by allowing them to
> register another prefix that should not be auto-loaded: Sodium, MongoDB,
> ...
>
> Another solution could be to use pecl as their prefix. Although this
> couples it to the packaging system which might not be so nice.
>
> Any name that is tied to a company name or something else that makes
> things impossible for users to claim (Oracle, MongoDB, ...) is not a
> problem. In case of sodium that would probably be Paragon but Sodium
> might be fine too.
>
> I am not the judge here, the only thing I want is to ensure that this
> does not go unseen and that the potential of breaking something is real
> if we choose a random route like some others do. Not saying that we
> cannot do it, big ecosystems live without problems doing the same.
> However, it should be a very conscious choice and none that is taken
> lightly: meaning rules!
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

On 2/6/2017 9:47 PM, Nikita Popov wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace
>  for bundled PHP extensions. The PHP namespace should be used only
> for functionality that is actually in some way related to PHP. For 
> example, the php-ast extension could reasonably be namespaced as 
> php\ast, as it provides an AST for PHP specifically. Similarly the 
> tokenizer extension could reasonably be namespaced as php\tokenizer.
> 
> Extensions which are not of this type should not live in the PHP 
> namespace, because they don't have anything specifically to do with 
> php, apart from the circumstance that they happen to be bundled at 
> the current point in time. Remember that extension may move from 
> being bundled to being in PECL and vice versa. If we decide to bundle
> the MongoDB extension with php, would we rename the currently used
> MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> PECL, would the namespace go back to just MongoDB? Or would it stay
> PHP\MongoDB, despite not being part of PHP anymore? Should all new
> extensions be written with a PHP namespace to account for the 
> possibility of the extension being bundled with PHP at a later point
>  in time (even if there are no concrete plans to do so)?
> 
> I would answer No to these questions. The namespace MongoDB is not, 
> as you say, "random", it is *meaningful*. The namespace PHP is (with
>  the exceptions in the first paragraph notwithstanding) meaningless 
> and an artifact of the distribution mechanism, a mechanism which may
>  change over time.
> 
> Regards, Nikita
> 

I thought about this too. I hope you understood that the main reasoning
for me to choose a well known namespace prefix is related to
auto-loading and when to trigger it. The lack of function and constant
auto-loading is a pain and having well known prefixes could solve the
issue since we would never require to even look at the auto-loader if
the namespace starts with php.

Obviously this could be solved for C extensions by allowing them to
register another prefix that should not be auto-loaded: Sodium, MongoDB, ...

Another solution could be to use pecl as their prefix. Although this
couples it to the packaging system which might not be so nice.

Any name that is tied to a company name or something else that makes
things impossible for users to claim (Oracle, MongoDB, ...) is not a
problem. In case of sodium that would probably be Paragon but Sodium
might be fine too.

I am not the judge here, the only thing I want is to ensure that this
does not go unseen and that the potential of breaking something is real
if we choose a random route like some others do. Not saying that we
cannot do it, big ecosystems live without problems doing the same.
However, it should be a very conscious choice and none that is taken
lightly: meaning rules!

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

On 2/6/2017 9:27 PM, Sara Golemon wrote:
> I've been having this same thought lately since looking at the sodium
> RFC.  Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
> 
> New classes within 7.2 (e.g. \HashContext) to be moved without 
> concern for BC (e.g. \php\Hash\HashContext)
> 
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND 
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
> 
> "Aliasing" could be potentially accomplished in a few ways: 1. 
> Literally just class_alias().  Put another copy of the 
> zend_class_entry into the EG(class_table) under a different name. 2. 
> "Auto-use": Compile-time analysis of classname: "Is it in this list 
> of BC classes? Implicitly map it." 3. ...?
> 
> I like #2 because we can raise compile-time deprecation warnings and
>  we don't introduce any runtime overhead for most cases.
> 
> Obviously, no removal of support for non-namespaced names until AT 
> LEAST PHP 8.0
> 
> This two big unanswered questions for me before I'd put this into an 
> RFC are: 1. How to achieve BC in the best way 2. What to do about 
> functions/constants? Instinct says move 'em just like classes.
> 
> -Sara
> 
> P.S. - wrt libsodium, I think THIS issue is enough for me to come 
> down on the side of voting non-namespaced to avoid it being an 
> odd-duck.
> 

0. Discuss what kind of casing we would like to have. The community has
pretty much settled with CamelCase, however, no need to us to adopt
that. Having `Php` is weird but mixing `php\SPL` is weird too. ;)

Most languages simply use lowercase in their namespace and CamelCase for
class names, e.g.:

php\Integer
php\String
php\Utf8String
php\io\Path
php\io\File
php\io\Directory
php\intl\Locale
php\time\DateTime
php\spl\iterators\RecursiveIteratorIterator

Obviously the same is possible with other rules:

PHP\Integer
PHP\String
PHP\UTF8String
PHP\IO\Path
PHP\IO\File
PHP\IO\Directory
PHP\Intl\Locale
PHP\Time\DateTime
PHP\SPL\Iterators\RecursiveIteratorIterator

I really don't care but lets create a sane standard that is easy to
follow. Let's do this right if at all!

I would start emitting deprecations is PHP 8 and consider removal in PHP
9 only after having a close look at the community how they adopt these
changes.

I would not simply move everything. I would consider every API and try
to clean it up before moving it to namespaces. This is a HUGE junk of
work but unlike PHP 6 and UTF-8 it could be done incrementally without
any concerns about BC or anything. Obviously any API that is considered
fine can be moved and aliased.

This would also be the perfect moment to get nikic's scalar object stuff
in (already illustrated in the example list above). There are many other
things in the pipelines that could help us creating a better Core for
the community, specifically Generics and Enums.

Potential is endless but requires very good planning and alignment and
not a secondary vote due to PECL BC concerns.

On 2/6/2017 9:29 PM, Paul Jones wrote:
> I would not have noted this if you had not said something. Thank you 
> for doing so.
> 

I had this fear and expressed it in the libsodium RFC discussion as
well. That is why I created this discussion. This is an epic decision
for the PHP ecosystem and cannot go unnoticed.

I actually would block that second vote to be honest.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Nikita Popov]

On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>

I'm strongly against use of the PHP namespace as a blanket namespace for
bundled PHP extensions. The PHP namespace should be used only for
functionality that is actually in some way related to PHP. For example, the
php-ast extension could reasonably be namespaced as php\ast, as it provides
an AST for PHP specifically. Similarly the tokenizer extension could
reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP namespace,
because they don't have anything specifically to do with php, apart from
the circumstance that they happen to be bundled at the current point in
time. Remember that extension may move from being bundled to being in PECL
and vice versa. If we decide to bundle the MongoDB extension with php,
would we rename the currently used MongoDB namespace to PHP\MongoDB? If we
decided to move it back to PECL, would the namespace go back to just
MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
anymore? Should all new extensions be written with a PHP namespace to
account for the possibility of the extension being bundled with PHP at a
later point in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not, as you
say, "random", it is *meaningful*. The namespace PHP is (with the
exceptions in the first paragraph notwithstanding) meaningless and an
artifact of the distribution mechanism, a mechanism which may change over
time.

Regards,
Nikita

Re: [PHP-DEV] Namespaces in Core

[Paul Jones]

> On Feb 6, 2017, at 13:50, Peter Cowburn  wrote:
> 
> a vote which essentially is about adopting
> namespaces in core, via new library RFC, is not the way to go about
> changing our coding standards.  In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (which it should be
> :)) only to have someone ask, "what about the 'php' top-level namespace?"
> and we all shrug and mutter, "too late" under our breaths.

I would not have noted this if you had not said something. Thank you for doing 
so.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

Re: [PHP-DEV] Namespaces in Core

[Sara Golemon]

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder  wrote:
> First: I like namespaces in Core but here me out!
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
I've been having this same thought lately since looking at the sodium
RFC.  Here are my thoughts, centered on the goal of having classes
(and maybe functions?) in a \php\{extname}\ namespace hierarchy.

New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

"Aliasing" could be potentially accomplished in a few ways:
1. Literally just class_alias().  Put another copy of the
zend_class_entry into the EG(class_table) under a different name.
2. "Auto-use": Compile-time analysis of classname: "Is it in this list
of BC classes? Implicitly map it."
3. ...?

I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.

Obviously, no removal of support for non-namespaced names until AT LEAST PHP 8.0

This two big unanswered questions for me before I'd put this into an RFC are:
1. How to achieve BC in the best way
2. What to do about functions/constants? Instinct says move 'em just
like classes.

-Sara

P.S. - wrt libsodium, I think THIS issue is enough for me to come down
on the side of voting non-namespaced to avoid it being an odd-duck.

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

Re: [PHP-DEV] Namespaces in Core

[Peter Cowburn]

On 6 February 2017 at 17:21, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>

I don't often chime in on the internals list, so please excuse this
interruption.  Slinking in a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards.  In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.


>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] [RFC][VOTE] - list() reference assignment

[David Walker]

Hi all,

Having seen no further discussion I'd like to open the RFC[1] for voting.
Voting will be given just over 2 weeks ending Feb 22nd.  RFC has
implementation[2] and language spec change[3] for review.

Thanks!

--
Dave

[1] - https://wiki.php.net/rfc/list_reference_assignment
[2] - https://github.com/php/php-src/pull/2371
[3] - https://github.com/php/php-langspec/compare/master...bp1222:fix-7930

ps: my first change to the language spec, so if it's incomplete, or wrong,
advice is welcomed.

[PHP-DEV] Namespaces in Core

[Fleshgrinder]

Hey guys! :)

First: I like namespaces in Core but here me out!

https://wiki.php.net/rfc/libsodium

The second vote is clearly going to be that this new feature is added to
the core with a namespace. I already complained about this but it seems
to go unnoticed or others do not see the potential problems that might
be introduced by this.

Sodium (or insert possible future namespace in Core here) might be a
valid username and existing community standards use the first namespace
for the vendor. Using those first level vendor namespaces in Core always
comes a long with a potential problem for users with that name.

The PHP (case does not matter) would be the proper vendor name to put
Core stuff in, as far as I remember it is also reserved for PHP
functionality. There were also numerous discussions about providing a
cleaned up API there while maintaining backwards compatibility via
aliases and so forth in the non-namespaced Core stuff.

Using the PHP vendor name as first level namespace would defeat problems
with userland namespaces and be a much safer choice. Hence,
`php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.

There is another issue regarding auto-loading. If we randomly introduce
first-level namespaces we de facto make it much harder for us to exclude
some pattern from the auto-loader. However, putting everything Core
related into `Php` would mean that we can always sidestep any
auto-loader calls since we know up front that this must be a C thing.

Most package and/or namespace system do that to avoid problems with
their users:

- Java: `java*`
- C#: `System*`
- C++: `::std*`
- Rust: `core::*` and `std::*` [1]
- Scala: `scala*`
- Kotlin: `kotlin*`
- Ceylon: `ceylon*`
- ...

Obviously there are some counter examples too:

- Go: random
- Python: random
- Javascript: random
- ...

But at least they go through an extensive standardization process where
the names are being discussed ad infinitum to ensure that they are super
generic and thus useful. It is very unlikely that `IO` or `OS` collides
with a username.

I personally would love to see namespaces but I definitely do not want
to see random namespaces. I hope we are not going down a road that is
hard to repair later, like with so many other things we have in Core today.

[1] Rust decided against vendor names for some reasons they explained
once in a blog post. I believe that this will become a problem for them
at some point in time since coming up with nice names over time for
users is very hard. We'll see if Rust persists and invalidates my concerns.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Fwd: Monotonic Time

[Fleshgrinder]

On 2/6/2017 1:33 PM, Anatol Belski wrote:
> With the names and API, probably some more clarity should be. AFM,
> the low level units should be exposed, rather than a concrete time.
> Also, the name hrtime() is probably not much speaking. Maybe these
> three?
> 
> sys_get_monotonic_ticks()
> sys_get_monotonic_freq() 
> sys_get_monotonic_nanotime() or even -
> sys_get_monotonic_time(int $unit = NANOSECOND)
> 
> Regarding to "sys_get_*" scheme with these. But in general, probably
> nanoseconds were enough for the general case and fast, the pure ticks
> were for the advanced usage.
> 
> In general, probably for the core it should be done a more robust
> way, some parts on the original lib should get more error checks and
> improved. It would be probably more handy to discuss the further on
> the PR page.
> 
> Regards
> 
> Anatol
> 

Hey guys! :)

Please do not introduce more functions that require flags, it makes code
hard to read. It's much better to have dedicated functions that provide
exactly what is requested. A good bad example is `microtime()` vs
`microtime(true)`. :(

`sys_get_monotonic_nanotime()` is rather long but at least descriptive.
Obviously providing a class could help with naming a lot and future
extension would be easy, e.g. `MonotonicTime::getNanoseconds()`.

-- 
Richard "Fleshgrinder" Fussenegger

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

[PHP-DEV] RE: [PHP-WIN] New PHP SDK for Windows

[Anatol Belski]

Hi,

> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Monday, October 31, 2016 6:02 PM
> To: 'PHP internals list' ; 'internals-win'
 w...@lists.php.net>; php-wind...@lists.php.net
> Subject: [PHP-WIN] New PHP SDK for Windows
> 
> Hi,
> 
> I'm working on the new Windows PHP SDK. So far, some usable alpha state is
> reached. It is compatible with PHP-7.0 and the current SDK and contains
> additional new features. The essential changes in the new SDK are
> 
> - starter scripts included, making the environment setup easier
> - updated tools, including bison 3.0.2
> - more tools including sed, awk and others based on MSYS2
> - new tool for dependency update automation
> 
> The current state is reachable under
> 
> https://github.com/OSTC/php-sdk-binary-tools/tree/new_binary_tools
> 
> I would like to call everyone interested to please check and provide
feedback
> and PRs. Other useful tools can be invented on the base of the new SDK.
> Production usage is not yet recommended, but the more feedback is there
> - the closer it'll be. The plan is to replace the current PHP SDK with the
new one
> in foreseable future for PHP 7 builds, maybe also to backport for the 5.x
tree.
> This also correlates with the upcoming AppVeyor integration, and both
tasks in
> general are directed to improve the QA and experience situation when
building
> PHP on Windows.
> 
> Please check more on the github README page. If some tool is missing or is
> worth it to be implemented, please create a ticket. A new
step-by-step-build wiki
> page will also need to be created, once the new SDK was considered stable.
I
> would also ask to migrate the linked repository to git.php.net, meanwhile
the PR
> can be accepted on the OSTC repository page.
> 
So far the point was reached, so then the current new binary tools SDK
implementation is close to stable. For about two months already, all the
AppVeyor builds use the new SDK, the current master snapshots use it as
well. Many people reported good experiences with it, some bugs were fixed
and more improvements was made. At this point, I've also started to adapt
the documentation
https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2 and the actual
plan for the next 2-3 weeks is

- move the further development into the master of php-sdk-binary-tools
- if someone from systems has time, still please add this repo to
git.php.net
- do a stable release of the binary tools 2.0.0
- make PHP 7.2 to require the new binary tools and solve
https://github.com/OSTC/php-sdk-binary-tools/issues/1

I'd appreciate any help with the wiki doc page. Some quite exhaustive
information is also available on the SDK's own readme page in the git repo,
which might make less sense to be duplicated on the wiki. Still, I could
miss something, so any review is useful. Any further tests on the SDK itself
were ofc welcome, too.

Regards

Anatol





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

RE: [PHP-DEV] Fwd: Monotonic Time

[Anatol Belski]

Hi Niklas,

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Sunday, February 5, 2017 8:19 PM
> To: Anatol Belski 
> Cc: Leigh ; Michael Wallner ; PHP Internals
> ; Bob Weinand ; Daniel Lowrey
> 
> Subject: Re: [PHP-DEV] Fwd: Monotonic Time
> 
> I have implemented a `hrtime()` function which allows access to the system's
> monotonic time in nanoseconds.
> 
Nice for the start.

> 
> https://github.com/php/php-src/compare/master...kelunik:hrtime
> 
> 
> Feedback is very welcome.
> 
> I'm not sure whether we should allow a parameter for the time unit or just let
> the user do the simple calculation.
> 
I'd see this integration a bit different, as the goal is to put it into the 
core.  Here some quick points to maybe think about

- on the m4 side, symbols need to be checked
- the PHP internal and user stuff should be integrated tight into the timer.c 
file, 
- a finer usage with the concrete platform should be taken care of, thus 
avoiding unnecessary function calls and conversions back/forth as you can use
- there might be a situation, where the monotonic API could be used internally 
before modules are initialized
- the symbols exported need to be renamed, probably prefix with 
php_monotonic_*, like php_monotonic_timer_current(), etc.
- but aso, probably not all the symbols should be exported

With the names and API, probably some more clarity should be. AFM, the low 
level units should be exposed, rather than a concrete time. Also, the name 
hrtime() is probably not much speaking. Maybe these three?

sys_get_monotonic_ticks()
sys_get_monotonic_freq()
sys_get_monotonic_nanotime() or even - sys_get_monotonic_time(int $unit = 
NANOSECOND)

Regarding to "sys_get_*" scheme with these. But in general, probably 
nanoseconds were enough for the general case and fast, the pure ticks were for 
the advanced usage.

In general, probably for the core it should be done a more robust way, some 
parts on the original lib should get more error checks and improved. It would 
be probably more handy to discuss the further on the PR page.

Regards

Anatol



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

Re: [PHP-DEV] [Discussion] FFI in PHP

[Michael Wallner]

On 05/02/17 23:25, Alex Bowers wrote:
> And here is the previous messaging without borked formatting. Sorry folks.
> 
> 
> FFI RFC
> ==
> 
> There are many languages that support an FFI implementation.
> 
> NodeJS
> Python
> C++
> Ruby
> 
> FFI allows you to call a native C function without requiring the
> boilerplate of an extension to be written.
> 
> There are several benefits to having FFI
> 
> - Performance
> - Shareability / Bundling
> - Common functionality between languages
> 
> Performance
> ===
> Although less pronounced than the 5.x versions, there is still a
> performance benefit to having native C code over PHP code. For
> example, you could utilise threading inside of your FFI methods, which
> PHP does not expose the ability to do.
> 
> Shareability
> ===
> 
> If you wish to implement some of your source code in C, the current
> way to share it is to build it as an extension. This is cumbersome,
> and restricts use-cases such as shared hosting, where the ability to
> install your own extensions is probably restricted. However, with FFI,
> the shared object can be loaded from any location, and so that
> restriction is no longer in place.
> 
> They could even be distributed via composer.
> 
> Common functionality between languages
> ===
> 
> If you have some complex logic that needs to be replicated in several
> languages for whatever reason; implementing it several times over
> would lead to uncertain bugs and technical debt increasing heavily. If
> you could share the same logic amongst them all using FFI, then this
> is no longer an issue.
> 
> Example
> ===
> 
> Take an example of a rust program that takes two numbers in and gives
> you the sum of them.
> 
> ```rust
> #[no_mangle]
> pub extern fn add(a: i32, b: i32) -> i32 {
> a + b
> }
> 
> ```
> 
> with the Cargo.toml file containing:
> 
> ```
> [package]
> name = "math"
> version = "0.1.0"
> authors = ["Alex Bowers "]
> 
> [dependencies]
> 
> [lib]
> name = "math"
> crate-type = ["dylib"]
> ```
> 
> `cargo build --release` will create `.so`, `.dylib`, or `.dll` files
> depending on your system.
> 
> These should be usable within PHP using the exposed functions.
> 
> ```php
> $math = ffi("/path/to/math.so");
> $result = $math->add(1, 5);
> 
> echo $result; // 6
> ```
> 
> With the implementation at its most basic level, calling the `add`
> method with incorrect parameters would likely cause a segfault.
> 
> A way around that could be that the methods are not immediately
> exposed, but have to be configured.
> 
> Something like:
> 
> ```php
> $math = ffi("/path/to/math.so");
> $math->add(1, 5); // Throws RuntimeException, method not configured
> 
> $math->configure('add', int $a, int $b);
> 
> $math->add(1, 5); // 6
> $math->add('a', 5); Fatal error: Uncaught TypeError: Argument 1 passed
> to add() must be of the type integer, string given
> ```
> 
> Prior art:
> ===
> https://pecl.php.net/package/ffi - Last release > 13
> yearshttps://github.com/mgdm/MFFI - Not stable, last commit > 1 year,
> no releases
> 

Trying to add answers later today, in the meantime, please have a look
at https://github.com/m6w6/ext-psi


-- 
Regards,
Mike



signature.asc
Description: OpenPGP digital signature