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
