Re: [PHP-DEV] intersection types and null for defaults, properties and return types

[azjezz]

Hello,

I personally don't consider a bug, but an expected behavior.

when writing:

```
T $x = null
```

it is the same as writing:

```
T|null $x = null
```

or

```
?T $x = null
```

however, when `T` is an intersection between `X` and `T` ( `X` ), `X $x = 
null` becomes `null|X $x = null`, which is a combination between union and 
intersection types, however, as the RFC stats, currently combination between 
union and intersection types is not support ( hence "pure" ).

for this to be allowed, PHP would need to support combining union and 
intersection types, preferable using parenthesis ( `X|(Y) $x = null` or 
`(X)|Z $x = null` ).

Regards,

Saif.

‐‐‐ Original Message ‐‐‐

On Monday, July 19th, 2021 at 9:41 AM, Nicolas Grekas 
 wrote:

> Hi all,
> 

> I want to bring your attention to a behavior that was mostly overlooked:
> 

> 1.  it is not possible to use an intersection type with an argument that
> 

> defaults to null
> 2.  it is not possible to use an intersection type with a nullable
> 

> property (nor to make it default to null)
> 3.  it is not possible to use an intersection type with a nullable return
> 

> type
> 

> Actually, 2. was possible until it was "closed" in
> 

> https://github.com/php/php-src/pull/7254
> 

> I reported these behavior and you might find some discussion about it in
> 

> https://bugs.php.net/81268
> 

> Looking at the past discussion on this list (
> 

> https://externals.io/message/113712) and at the rfc itself (
> 

> https://wiki.php.net/rfc/pure-intersection-types), this was mostly
> 

> overlooked.
> 

> That's why I'm posting this message. So that we can have that missing
> 

> discussion here.
> 

> To me, we are going to need (userland "we") these capabilities.
> 

> It's quite surprising to be "forced" to return something, or "forced" to
> 

> pass a value, when all other types in PHP allow "null". I know about the
> 

> null pattern, but it is quite uncommon in PHP, because "null" works just
> 

> great usually.
> 

> I feel like we "just" need to agree on a syntax to make this possible. It
> 

> was first suggested in the related PR to use "?A" (see
> 

> https://github.com/php/php-src/pull/6799#issuecomment-804761117)
> 

> This was rejected by the author with the reasoning that (?A) could mean
> 

> (?A) or ?(A) or even (?A)|B.
> 

> I personally don't think this ambiguity exists: (?A)|B is strictly the 
> same
> 

> as A, thus ?A cannot also mean A, and I don't get how one could take
> 

> ?A for (?A)|B.
> 

> Another argument is that ?A might collide with a future syntax. But I
> 

> fail to see how. For sure we create examples of such collisions, but they
> 

> all look constructed to me.
> 

> Shouldn't we allow ?A ? Intersection types look unfinished to me without
> 

> compat with nullables.
> 

> Cheers,
> 

> Nicolas

signature.asc
Description: OpenPGP digital signature

[PHP-DEV] [discussion] arraykey type

[azjezz]

Hello Internals,

As [Danack](https://github.com/Danack) has mentioned in the [PR 
comments](https://github.com/php/php-src/pull/4073#issuecomment-487186654), i 
want to discuss this here before writing an RFC.

What do you think about adding the `arraykey` type to PHP.

see :
- https://docs.hhvm.com/hack/types/arraykey
- https://github.com/php/php-src/pull/4073#issuecomment-487178779
-https://github.com/php/php-src/pull/2603#issuecomment-487122061
- https://twitter.com/azjezz/status/1121182765385433095
- https://www.facebook.com/groups/2204685680/?multi_permalinks=10157789745805681

GitHub pull request : https://github.com/php/php-src/pull/4073

---

### Weak typing
As Nikita [mentioned in the 
PR](https://github.com/php/php-src/pull/4073#issuecomment-487184224), this is 
an issue that we are facing even with union types.

assuming we have a function named `get` with the following signature :
```
function get(iterable $container, arraykey $index): mixed;
```
should passing a `float` or `bool` be allowed when `strict_types=0` ?
if so, should `get($arr, true);` act as `get($arr, 1);` or `get($arr, '1');` ?

---

### Naming
The `arraykey` naming comes from Hack, i found it familiar since i am used to 
Hack, but we have other options :

- `index`
- `key`
- `offset`

---

Best regards,

Saif Eddin Gmati.

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

Hello Andery.

yes that's possible, but would need a function for each type, or we can do : 
https://3v4l.org/6B3hA

but this is still not type-safe, as we won't be able to type hint it correctly 
without using generics + `typename` type that exists in Hack.


using generics + `typename` : `function check(mixed $var, typename 
$type): T`


Cheers,

- Saif

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 23, 2019 11:51 AM, Andrey Hristov  wrote:

> Hi,
> On 23.04.19 г. 13:44 ч., azjezz wrote:
>
> > Hello Dan,
> > I don' think this a problem relating to just one use case, some PHP builtin 
> > functions have weird union return types, where static analysis tools would 
> > warn you about the return type being `string|bool`, when you are expecting 
> > `string`.
> > using type constrain :
> >
> > $foo = substr($foo, 1, 3) as string;
> > // there's no need to check if `$foo` is false here.
> >
>
> this is easily solvable with the following (considering strict_types is
> enabled)
>
> function tostr(string $in) : string { return $in; }
>
> $foo = tostr($foo);
>
> Put it in a convenience namespace and that's it.
>
> Cheers,
> Andrey
>
> > Cheers,
> >
> > -   Saif
> >
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, April 23, 2019 11:33 AM, Dan Ackroyd dan...@basereality.com 
> > wrote:
> >
> > > HI Benjamin,
> > > Similar to the nullable casting idea, you're taking a problem caused
> > > by your own code/framework, and then thinking it should be solved in
> > > core, when a simple solution is available in user-land.
> > > If you changed what you currently have:
> > > $service = $diContainer->get('email.service');
> > > to also take the expected class:
> > > $service = $diContainer->get('email.service', EmailService::class);
> > > And then check inside your 'DI container' whether the expected type is
> > > returned, this solves the problem without needing new syntax.
> > > btw I'm sure you're already aware of it, but this is using a
> > > 'dependency injector' as a service locator. If your current DI library
> > > isn't powerful enough for you, rather than abusing it like this, I'd
> > > recommend looking at a different one, like
> > > https://github.com/rdlowrey/Auryn
> > > Also, similar:
> > >
> > > > By the way, this RFC is a special case of something that could be far
> > > > more generic. If it was possible to register callbacks to be used when
> > > > casting, ...
> > >
> > > Apparently this might not be possible as it's ambiguouswhich is a 
> > > shame.
> > > cheers
> > > Dan
> > > Ack
> > > On Mon, 22 Apr 2019 at 22:47, Benjamin Morel benjamin.mo...@gmail.com 
> > > wrote:
> > >
> > > > Hi internals,
> > > > I'd like to revive an old discussion https://externals.io/message/67131 
> > > > about
> > > > object type casting.
> > > > The idea would be to allow (ClassName) casting:
> > > >
> > > >  $service = (EmailService) $diContainer->get('email.service');
> > > >
> > > >
> > > > The above code would throw a TypeError if the value is not an instance 
> > > > of
> > > > the given class. I see the following advantages:
> > > >
> > > > -   Type safety: we can be sure that the value is of the correct type 
> > > > or that
> > > > we'll get an Error. This syntax allows to fail early if the variable
> > > > happens to not be of the expected type, and avoids much more 
> > > > verbose checks;
> > > >
> > > > -   Static analysis: IDEs and static code analysis tools can now 
> > > > understand
> > > > the type of the variable, without having to resort to `@var` 
> > > > annotations.
> > > >
> > > >
> > > > These combine into a third advantage: readability. Today's equivalent of
> > > > the above one-liner could be:
> > > >
> > > >  /** @var EmailService $service */
> > > >  $service = $diContainer->get('email.service');
> > > >  if (! $service instanceof EmailService) {
> > > >  throw new TypeError('Expected instance of EmailService, ...');
> > > >  }
> > > >
> > > >
> > > > Which is a lot of boilerplate code that could be ea

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

Hello Dan,

I don' think this a problem relating to just one use case, some PHP builtin 
functions have weird union return types, where static analysis tools would warn 
you about the return type being `string|bool`, when you are expecting `string`.

using type constrain :
```
$foo = substr($foo, 1, 3) as string;
// there's no need to check if `$foo` is false here.
```



Cheers,

- Saif


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 23, 2019 11:33 AM, Dan Ackroyd  wrote:

> HI Benjamin,
>
> Similar to the nullable casting idea, you're taking a problem caused
> by your own code/framework, and then thinking it should be solved in
> core, when a simple solution is available in user-land.
>
> If you changed what you currently have:
>
> $service = $diContainer->get('email.service');
>
> to also take the expected class:
>
> $service = $diContainer->get('email.service', EmailService::class);
>
> And then check inside your 'DI container' whether the expected type is
> returned, this solves the problem without needing new syntax.
>
> btw I'm sure you're already aware of it, but this is using a
> 'dependency injector' as a service locator. If your current DI library
> isn't powerful enough for you, rather than abusing it like this, I'd
> recommend looking at a different one, like
> https://github.com/rdlowrey/Auryn
>
> Also, similar:
>
> > By the way, this RFC is a special case of something that could be far
> > more generic. If it was possible to register callbacks to be used when
> > casting, ...
>
> Apparently this might not be possible as it's ambiguouswhich is a shame.
>
> cheers
> Dan
> Ack
>
> On Mon, 22 Apr 2019 at 22:47, Benjamin Morel benjamin.mo...@gmail.com wrote:
>
> > Hi internals,
> > I'd like to revive an old discussion https://externals.io/message/67131 
> > about
> > object type casting.
> > The idea would be to allow (ClassName) casting:
> >
> > $service = (EmailService) $diContainer->get('email.service');
> >
> >
> > The above code would throw a TypeError if the value is not an instance of
> > the given class. I see the following advantages:
> >
> > -   Type safety: we can be sure that the value is of the correct type or 
> > that
> > we'll get an Error. This syntax allows to fail early if the variable
> > happens to not be of the expected type, and avoids much more verbose 
> > checks;
> >
> > -   Static analysis: IDEs and static code analysis tools can now understand
> > the type of the variable, without having to resort to `@var` 
> > annotations.
> >
> >
> > These combine into a third advantage: readability. Today's equivalent of
> > the above one-liner could be:
> >
> > /** @var EmailService $service */
> > $service = $diContainer->get('email.service');
> > if (! $service instanceof EmailService) {
> > throw new TypeError('Expected instance of EmailService, ...');
> > }
> >
> >
> > Which is a lot of boilerplate code that could be easily avoided by
> > introducing this new syntax.
> > Before moving forward and working on a formal RFC, I'd like to hear your
> > thoughts: what's your early feeling about this? Did I miss other
> > discussions around this subject? Are there any technical issues that come
> > to mind? Could this feature help the upcoming JIT compiler produce more
> > efficient machine code by knowing the type of the variable at compile time?
> > etc.
> > Note: "casting" might not be the perfect name here as what we're really
> > doing is a type check, but this reuses the type casting syntax and
> > resembles Java's object casting.
> > Thank you,
> > Ben
>
> --
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



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

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

Hello Nikita,

I would love to hear your opinion on the `as` syntax from Hack, and whether it 
can be used in PHP the same way or would it be an issue.

Cheers,

- Saif

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 23, 2019 10:16 AM, Nikita Popov  wrote:

> On Mon, Apr 22, 2019 at 11:48 PM Benjamin Morel benjamin.mo...@gmail.com
> wrote:
>
> > Hi internals,
> > I'd like to revive an old discussion https://externals.io/message/67131
> > about
> > object type casting.
> > The idea would be to allow (ClassName) casting:
> >
> > $service = (EmailService) $diContainer->get('email.service');
> >
> >
> > The above code would throw a TypeError if the value is not an instance of
> > the given class. I see the following advantages:
> >
> > -   Type safety: we can be sure that the value is of the correct type or 
> > that
> > we'll get an Error. This syntax allows to fail early if the variable
> > happens to not be of the expected type, and avoids much more verbose
> > checks;
> >
> > -   Static analysis: IDEs and static code analysis tools can now understand
> > the type of the variable, without having to resort to `@var` 
> > annotations.
> >
> >
> > These combine into a third advantage: readability. Today's equivalent of
> > the above one-liner could be:
> >
> > /** @var EmailService $service */
> > $service = $diContainer->get('email.service');
> > if (! $service instanceof EmailService) {
> > throw new TypeError('Expected instance of EmailService, ...');
> > }
> >
> >
> > Which is a lot of boilerplate code that could be easily avoided by
> > introducing this new syntax.
> > Before moving forward and working on a formal RFC, I'd like to hear your
> > thoughts: what's your early feeling about this? Did I miss other
> > discussions around this subject? Are there any technical issues that come
> > to mind? Could this feature help the upcoming JIT compiler produce more
> > efficient machine code by knowing the type of the variable at compile time?
> > etc.
> > Note: "casting" might not be the perfect name here as what we're really
> > doing is a type check, but this reuses the type casting syntax and
> > resembles Java's object casting.
> > Thank you,
> > Ben
>
> Without commenting on the rest of the proposal: It's not possible to use
> (ClassName) as a cast syntax, because it is ambiguous. For example (Foo)
> [$x] is already valid syntax (fetch constant Foo and take index $x), or
> (Foo) +$bar, etc.
>
> The only reason why (int) etc are okay is because we treat the whole (int)
> as a single token, something we can't do in general (because it would break
> foo(Foo)).
>
> Nikita



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

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

I think we would be talking about typed variables at that point.


( something you can do with PHP 7.4 http://github.com/azjezz/typed )

even though `as` is used with `foreach`, i don't think it would be an issue to 
use it for something else, but i think i will leave that to someone who's more 
familiar with the PHP parser than me.


Cheers.

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 23, 2019 1:43 AM, Stephen Reay  
wrote:

> > On 23 Apr 2019, at 06:30, azjezz azj...@protonmail.com wrote:
> > Hello Ben.
> > yes, i have made a gist with a simple example to show the `as` operator 
> > usage in hack + HHVM ( 4.1.0 ) output.
> > see : https://gist.github.com/azjezz/03955ff2b009f1ced22ce68c9a862847
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> >
> > > On Monday, April 22, 2019 11:50 PM, Benjamin Morel 
> > > benjamin.mo...@gmail.com wrote:
> > > Hi Azjezz, thanks for jumping in!
> > >
> > > > I have been using HackLang for quite a while now and i believe they 
> > > > have a better solution for this, and it would awesome to see it in PHP, 
> > > > the `as` operator.
> > >
> > > If I understand correctly, `as` is an operator that performs type checks 
> > > but never casts like () does.
> > > This looks like a serious candidate for an alternative syntax to the one 
> > > I proposed!
> > >
> > > -   Ben
>
> I like the idea but I find the syntax (both suggestions) less than great, 
> given that there’s already “ensure a type” syntax, and both suggestions are 
> already used for other things (casting and foreach)
>
> Is there some reason (eg ambiguities) a type can’t just be placed before a 
> variable to ensure a type, similar to a function parameter or typed property?
>
> Eg
>
> string $foo = 'bar';
> array $bar = getBar();
> foreach($bar as int $k => string $v) {...}
>
> Cheers
>
> Stephen



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

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

Hello Ben.

yes, i have made a gist with a simple example to show the `as` operator usage 
in hack + HHVM ( 4.1.0 ) output.

see : https://gist.github.com/azjezz/03955ff2b009f1ced22ce68c9a862847

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, April 22, 2019 11:50 PM, Benjamin Morel  
wrote:

> Hi Azjezz, thanks for jumping in!
>
>> I have been using HackLang for quite a while now and i believe they have a 
>> better solution for this, and it would awesome to see it in PHP, the `as` 
>> operator.
>
> If I understand correctly, `as` is an operator that performs type checks but 
> never casts like () does.
> This looks like a serious candidate for an alternative syntax to the one I 
> proposed!
>
> - Ben

Re: [PHP-DEV] Object Type Casting Reloaded

[azjezz]

Hello, Internals.

I have been using HackLang for quite a while now and i believe they have a 
better solution for this, and it would awesome to see it in PHP, the `as` 
operator.

see : https://docs.hhvm.com/hack/expressions-and-operators/as

---

when i see :

```
$foo = (Foo) $object;
```
i think that `$object` is going to be converted to an instance of `Foo`, not 
ensure that its an instance of `Foo`.

Hack `as` operator
```
$foo = $object as Foo;
// or
$object as Foo;
// use `$object` now, known that its an instance of `Foo`

```

> a `TypeAssertionException` expect would be throw if `$object` is not `Foo`.






Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, April 22, 2019 11:03 PM, Larry Garfield  
wrote:

> On Mon, Apr 22, 2019, at 4:47 PM, Benjamin Morel wrote:
>
> > Hi internals,
> > I'd like to revive an old discussion https://externals.io/message/67131 
> > about
> > object type casting.
> > The idea would be to allow (ClassName) casting:
> >
> > $service = (EmailService) $diContainer->get('email.service');
> >
> >
> > The above code would throw a TypeError if the value is not an instance of
> > the given class. I see the following advantages:
> >
> > -   Type safety: we can be sure that the value is of the correct type or 
> > that
> > we'll get an Error. This syntax allows to fail early if the variable
> > happens to not be of the expected type, and avoids much more verbose 
> > checks;
> >
> > -   Static analysis: IDEs and static code analysis tools can now understand
> > the type of the variable, without having to resort to `@var` 
> > annotations.
> >
> >
> > These combine into a third advantage: readability. Today's equivalent of
> > the above one-liner could be:
> >
> > /** @var EmailService $service */
> > $service = $diContainer->get('email.service');
> > if (! $service instanceof EmailService) {
> > throw new TypeError('Expected instance of EmailService, ...');
> > }
> >
> >
> > Which is a lot of boilerplate code that could be easily avoided by
> > introducing this new syntax.
> > Before moving forward and working on a formal RFC, I'd like to hear your
> > thoughts: what's your early feeling about this? Did I miss other
> > discussions around this subject? Are there any technical issues that come
> > to mind? Could this feature help the upcoming JIT compiler produce more
> > efficient machine code by knowing the type of the variable at compile time?
> > etc.
> > Note: "casting" might not be the perfect name here as what we're really
> > doing is a type check, but this reuses the type casting syntax and
> > resembles Java's object casting.
> > Thank you,
> > Ben
>
> Hi Ben.
>
> First thought: I'm all for easy ways to be more type-explicit, so yay on the 
> concept.
>
> Second thought: That said, how many use cases for that are there other than 
> function boundaries, which we already have covered?
>
> I can think of two: foreach() loops and returns where you know the return 
> type with more specificity than the method you're calling. Example:
>
> /** @var Foo $foo *//
> foreach ($arrayOfFoo as $foo) {
> $foo->bar();
> }
>
> Example from PSR-14, in which you know the object you're getting back MUST be 
> the same one that's passed in but dispatch() has no return type:
>
> /** @var Foo $event **/
> $event = $dispatcher->dispatch(new Foo());
>
> The second I can see being easily handled by this syntax. The former, how 
> would that look?
>
> Third thought: Casting is the wrong name here, and feels also misleading as a 
> syntax. (float)$anInt means "type coerce this thing into a float", which 
> cannot error. You're suggesting (Foo)$bar to mean "if this isn't already a 
> Foo, throw." That's a very different behavior semantic for the same syntax. 
> Is that a land mine? I would expect (Foo)$bar to mean "recast $bar into an 
> instance of Foo if possible, and error if not". Which... I suppose "is it 
> already" is a subcase of that, but it's still not the behavior I'd expect 
> from that syntax.
>
> --Larry Garfield
>
> ---
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



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

Re: [PHP-DEV] [RFC] JIT

[azjezz]

Hello internals.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, February 6, 2019 9:23 AM, Pierre Joye  
wrote:

> On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov dmi...@zend.com wrote:
>
> > On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> >
> > > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller m...@kelunik.com:
> > >
> > > > Shouldn't we introduce annotations instead of relying on doc comments?
> > >
> > > Yeah I'm not too happy with that approach either. I would rather see
> > > another way to do this and like you said; annotations is probably the
> > > best way to go about it as introducing a new keyword is not very
> > > suitable imo.
> >
> > Attributes were proposed ~3 years ago.
> > https://wiki.php.net/rfc/attributes
> > There were few other releted proposals.
> > But they didn't pass.
>
> Understanding and adoptions of annotations (Doctrine mainly afaics)
> have change. I think it is tricky to define it in a way that it can be
> useful and adopted as a core language feature, meaning being flexible
> enough to be extendable and usable as a base for userland extensions.
> That latter part is the biggest challenge. What do the actual
> users/authors of the current userland implementation think? (pls other
> thread? :)
>
> Best,
>
> 
>
> Pierre
>
> @pierrejoye
>
> 
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


In the past few weeks i have been mainly using hack-lang and the attributes API 
has changed as of 3.29 ( https://hhvm.com/blog/2018/10/22/hhvm-3.29.html - 
change actually landed on 4.0 instead ) and i think its a good approach that 
php can take too.

I have no experience with C so i don't know how this would work out for PHP, 
but i made a gist with a simple example on how it would be in :
https://gist.github.com/azjezz/918e333646d4f4070ab0be4cb41a81de


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

Re: [PHP-DEV] New website for the PHP project

[azjezz]

Hello Bohwaz,

i think you should take a look at the mock ups[1].

I don't plan on using an JS Framework, the frameworks i suggested are 
lightweight CSS Frameworks.


I'm also planning on keeping the shortcut redirects and maybe even improve them.

[1]: https://github.com/azjezz/web-php-mock-ups


‐‐‐ Original Message ‐‐‐
On Thursday, February 7, 2019 10:27 AM, BohwaZ/PHP  wrote:

> Le 04/02/2019 01:14, azjezz a écrit :
>
> > In my opinion, current design looks old, outdated and bland. This
> > sadly may reflect "badly" on the language reputation nowadays.
>
> I find that the main PHP website is quite good actually, the design
> looks modern, it is quite clear and easy to use and it provides great
> access to documentation.
>
> I have to say the PHP documentation is usually great (and when it's not,
> just change it :) ), and the feature where you can just type
> php.net/function to get direct access to the documentation of a
> function/feature is great, although it doesn't search in methods, eg.
> http://php.net/setParam will not return anything about PDOStmt::setParam
> :(
>
> I also love the comments feature, people often provide great examples,
> tips or replacement functions for old PHP versions, this is very
> helpful!
>
> So I don't think that we need to redesign and start over, but iterate
> and make the current website better, please don't throw out what is
> already good :) It would be a recipe for disaster.
>
> But I have to agree that signing to the internals list wasn't an easy
> task as the website form wasn't working when I subscribed 2 years ago,
> but it might have been fixed?
>
> > FrontEnd Framework
> >
> > ===
> >
> > We don't need that too, but we can use one ! there's some light-weight
> > options out there.
>
> Please only use HTML and CSS, don't use a JS framework. The website
> should be future-proof and not broken and hard to maintain in 6 months.
> Also it should be lightweight and not download a bunch of code just to
> display stuff. HTML and CSS are more than plenty for our needs :)
>
>
> 
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Tuesday, February 5, 2019 8:51 PM, Rowan Collins  
wrote:

> On 05/02/2019 17:32, Tom Worster wrote:
>
> > I have two suggestions, assuming you proceed roughly as outlined in
> > your original post.
> >
> > 1.  Start with /community
> >
> > > A new community website [4], it can be a place for people to ask
> > > questions and discuss php in general - no one uses IRC anymore.
>
> Like all the bold ideas in this thread, that alone would need some
> serious planning and commitment.
>
> Technically, it's easy - assuming you'd just install PHPBB / Gitter /
> whatever, and not try to invent yet another wheel; but building a
> community is hard.
>
> For a start, off the top of my head, you would need to figure out:
>
> -   Who is this community aimed at, and how will you attract them to use it?
> -   Who will moderate it, and according to what policies? (Particularly
> important if you're branding it as "the official PHP community")
>
> -   How will it relate to all the existing community tools (IRC,
> StackOverflow Chat, phpug.slack.com, these mailing lists, etc, etc)?
>
> If you can make it successful, I'm sure it would be a great asset, but
> there's a long and uncertain road between here and there.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Webmaster List Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

You are totally right.

in my opinion the the community site should be targeted to all the PHP 
Community ( PHP Developer / Core Developers ) to ask questions about PHP, 
discuss the development of PHP and related topics.

Moderation should be done by a Community Manager and Moderators. ( no idea for 
now who these would be, people we vote for or promoted by core members maybe ? )

For the software i would like to suggest https://flarum.org as well.

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Tuesday, February 5, 2019 8:49 PM, Midori Koçak  wrote:

> I can do some design, I designed the UI of CakePHP framework generators in 
> 2015. You can see the whole process here: 
> https://github.com/cakephp/cakephp/issues/6679
>
> We should not rely on any css, js or html framework in my opinion. But it's 
> up to you.
>
> For layout, CSS Grid and Flexbox is more than enough and would be future 
> proof, but should be tested and polyfilled.
>
> A lot of cross browser testing will be needed.
>
> Cheers,
> Midori

I'd really appreciate help in this.

if you would like to collaborate in the mock-ups for now, that would be great.

I'm not good enough with CSS so i have used Specter CSS framework in the 
mock-ups, it a lightweight pure CSS framework as i don't see the need for any 
JS yet.

I have sent you an invitation on GitHub, if you would like to join you are 
welcome.

https://github.com/azjezz/web-php-mock-ups/invitations

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

> Is this your desired look you wanna propose? I may misunderstand and

this is the original proposal :
> https://twitter.com/azjezz/status/1091722433424285698

how ever people seem to lean more toward having releases and changlogs in the 
front-page.


> -   example code (with an option to run)
i have already explored more sites for programming languages and most do have 
code samples and `run` option, but people seem to dislike this idea here.

> -   short description
> -   get started
> -   latest versions
i already added these in the last changes : 
https://github.com/azjezz/web-php-mock-ups#landing


> -   example code (with an option to run)
> -   features
> -   why this lang and what especially for
> -   some latest news (not few pages as it is right now)
> -   etc.

i don't see how can we fit all this in 1 page.

but i think we can show releases in the sidebar + a button to read more ( see 
changelogs, download links .. etc ) / code sample in the main container / 
features and why this lang under it, and few news cards under with a link to 
/news.

if you have any other ideas please let me know or if you wanna send a PR that 
would be amazing :)

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

Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Tuesday, February 5, 2019 2:20 AM, Andrey Andreev  wrote:

> Hi,
>
> On Mon, Feb 4, 2019 at 5:14 PM azjezz azj...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, February 4, 2019 2:32 PM, Andrey Andreev n...@devilix.net wrote:
> >
> > > Hi,
> > > I could nitpick on most of the proposed plan, but I really only wanted
> > > to reply to this:
> > >
> > > > > -   A new home page, not a "news" page, but a page simply showing the 
> > > > > PHP Logo, a code example maybe and
> > > > > the download link [3].
> > > > >
> > > > >
> > > > > [...]
> > > > > [3] 
> > > > > https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> > >
> > > I just hate those useless landing pages.
> > > Yes, it looks neat and clean, but after the initial "OMG so pretty"
> > > phase it just becomes annoying - noone cares about the code example
> > > and I for one never know what "Get Started" means. PHP isn't some
> > > consumer desktop software; nobody would just stumble upon php.net and
> > > "get started" with it, whatever that means ...
> > > I'm all for a modern look and all, but let's please keep the news on
> > > the index page. Personally, I only go to php.net to look for the news,
> > > changelogs and to search the docs. This image suggests that I'd need
> > > to do an extra click for each of those things and I'm sure I wouldn't
> > > be the only one unhappy about that.
> > > Cheers,
> > > Andrey.
> >
> > The landing page is meant for the new comers to PHP, when people search for 
> > php, the home page is the first to appear. it make sense to show a sample 
> > and a straightforward button to get started with using PHP ( introduction, 
> > installation and tutorial )
>
> There's a missing link here - who searches for "php" without prior
> knowledge of what it is? Programming languages aren't buzzwords that
> come up in casual conversations between people who don't already use
> them.
>
> And how does it make sense to show a code sample? What for? The only
> time I've seen isolated, meaningless code samples serve a purpose is
> to look cool in movies.
>
> Now that you mentioned a tutorial, that's one thing I agree is useful
> and missing. As a self-learner myself, 15 years ago I would've
> appreciated a vetted selection of tutorials on the official website.
> But why not just put a "Tutorials" link alongside "Documentation"?
>
> > You can see the mock up repository for what the "Getting Started" page 
> > would look like.
>
> No such thing had been linked until your last reply (which was sent
> after I started writing this), but that's my point exactly - you have
> to look at it first in order to know what's hiding behind it and
> that's counter-productive to me; I reiterate the suggestion to have a
> "Tutorials" link instead.
>
> > if you usually visit the website for documentation, you would just type 
> > php.net/documentation in the url bar instead of php.net or php.net/blog for 
> > changelogs and articles.
>
> See, this is where you actually make the site harder to use.
>
> Today, I only type "ph" into my address bar and thanks to Firefox
> hitting enter gets me to php.net, which in turn gives me everything
> that I need:
>
> -   The news are the main content and you want to put that on a separate
> page, calling it "Blog".
> Yes, most modern websites have a "Blog" instead of a "News" section,
> but that's because at some point it became "cool" for everyone to
> blog. There's no use to just naming it that when there's zero blogging
> going on and we have almost exclusively only release announcements.
>
> -   The ChangeLog I get convenienty linked to from each news article
> about a release (again that's all the news). So that's another thing
> you're taking away from the index page, even if by accident.
>
> -   The search bar allows me to check the manual for any function
> signature, built-in class reference, etc.
> Note that I said "search the manual" in my first reply, not browse
> it. I've never needed to visit php.net/documentation, yet that's what
> you suggest I should do.
>
> These things are regressions for me, not improvements.
>
>
> In essence, I share Rowan's sentiment in that I act

Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Monday, February 4, 2019 5:11 PM, Thomas Hruska  
wrote:

> On 2/4/2019 6:32 AM, Andrey Andreev wrote:
>
> > Hi,
> > I could nitpick on most of the proposed plan, but I really only wanted
> > to reply to this:
> >
> > > > -   A new home page, not a "news" page, but a page simply showing the 
> > > > PHP Logo, a code example maybe and
> > > > the download link [3].
> > > >
> > > >
> > > > [...]
> > > > [3] 
> > > > https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> >
> > I just hate those useless landing pages.
> > Yes, it looks neat and clean, but after the initial "OMG so pretty"
> > phase it just becomes annoying - noone cares about the code example
> > and I for one never know what "Get Started" means. PHP isn't some
> > consumer desktop software; nobody would just stumble upon php.net and
> > "get started" with it, whatever that means ...
> > I'm all for a modern look and all, but let's please keep the news on
> > the index page. Personally, I only go to php.net to look for the news,
> > changelogs and to search the docs. This image suggests that I'd need
> > to do an extra click for each of those things and I'm sure I wouldn't
> > be the only one unhappy about that.
> > Cheers,
> > Andrey.
>
> I regularly go to thephp.net homepage for the live documentation search
> function just to make sure I'm using functions correctly. My most
> frequent search is the date() function for the % code list. One of
> these days I'll print out that docs page instead of looking it up every
> time to save everyone the bandwidth. Of the things I'd miss the most
> would be the live documentation search feature to jump directly to what
> I'm looking for. Google Search doesn't cut it here.
>
> For a newbie, I'd say a "Get Started" button that goes to a vetted group
> of starter tutorials (maybe videos?) on a variety of subjects could be
> valuable. I wouldn't want the homepage to load a video player though.
>
> My biggest complaint is that there's nothing in the mockup that says
> what PHP is for.
>
> Website: "Here's PHP spelled out and a difficult to comprehend code
> example. Uh...Get Started?"
>
> First time visitor: "Okay, that's great. Now tell me what is PHP in
> words I can understand and what can I use it for and is it popular?"
>
> A code example rarely, if ever, makes a good first impression.
>
> -
>
> 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/


thanks for your suggestion, i have update the mock up to :

1. include a search input in the navbar
2. move the "Getting Started" button to the navbar
3. include a short description of what PHP is ( the same one that is currently 
on the of php.net )

see : https://github.com/azjezz/web-php-mock-ups


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

Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Monday, February 4, 2019 5:16 PM, Rowan Collins  
wrote:

> On Mon, 4 Feb 2019 at 15:19, azjezz  wrote:
>
>> I'm not proposing updating the UI and other websites to use, instead rebuild 
>> all PHP websites.
>
> I'm not sure what the difference between "updating the UI" and "rebuilding 
> the websites" is. Do you mean that as well as rewriting every HTML and CSS 
> template, you're going to build a completely new bug tracker, a new DocBook 
> to HTML generator for the manual, and so on? If so, I strongly suggest you 
> rein in your ambitions and tackle one problem at a time.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

i think i will start by php.net and the documentation. but this would also 
require markdown documentation, as contributing to the PHP docs is not easy at 
all now.
but this it another topic for another time.

for now, i'll just finish doing the mock ups.

Re: [PHP-DEV] New website for the PHP project

[azjezz]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, February 4, 2019 2:02 AM, Levi Morrison  wrote:

> On Sun, Feb 3, 2019 at 5:15 PM azjezz azj...@protonmail.com wrote:
>
> > Hello Internals !
> > As @official_php suggested [1], I'm here to propose a new website for the 
> > PHP Project.
> > In my opinion, current design looks old, outdated and bland. This sadly may 
> > reflect "badly" on the language
> > reputation nowadays.
> > New comers find it hard to go around the website, to write "comments", 
> > report issues or write RFCs.
> > Even signing up for the internals mailing list wasn't an easy task [2].
> > Since the development of PHP 8.0 has started, I think its a good idea to 
> > start working on a new website.
> >
> > Global proposal
> >
> > 
> >
> > The proposal here is to do a major rewrite of the PHP sites. This rewrite 
> > would includes php.net, windows.php.net,
> > bug.php.net, wiki.php.net, qa.php.net and other official php websites.
> > It would be done with this in mind:
> >
> > -   No PHP framework (to avoid favoriting one)
> >
> > -   Keep it simple: little to no changes to the database structures
> >
> > -   This site should look modern, simple and feel welcoming.
> >
> > -   A new home page, not a "news" page, but a page simply showing the PHP 
> > Logo, a code example maybe and
> >
> >
> > the download link [3].
> >
> > -   A new community website [4], it can be a place for people to ask 
> > questions and discuss php in general - no one uses IRC anymore.
> >
> > -   Single account: Users should be able to use the same community account 
> > to file bugs, create a new RFC (depending on karma) and leave notes on the 
> > documentation.
> >
> > -   Ideally all *.php.net websites would be "merged" into a single brand 
> > new website, but I'm not sure about the hosting
> >
> >
> > specificities (eg, what server does what).
> >
> > FrontEnd Framework
> >
> > ===
> >
> > We don't need that too, but we can use one ! there's some light-weight 
> > options out there.
> > but i'm pretty sure some people in the php community have experience with 
> > front-end development and will happily contribute.
> > see :
> >
> > -   https://mustard-ui.com/
> >
> > -   https://getuikit.com/
> >
> > -   https://bulma.io/
> >
> > -   https://picturepan2.github.io/spectre/index.html
> >
> >
> > Next steps
> >
> > ===
> >
> > I would really like to hear opinions about this proposal.
> > [1] https://twitter.com/official_php/status/1091903415377108994
> > [2] https://twitter.com/SaraMG/status/1092185205572542466
> > [3] 
> > https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> > [4] https://php.net/community
> >
> > Saif Eddin Gmati https://azjezz.github.io
>
> I appreciate the enthusiasm. If you think the current PHP website is
> old, out-dated, and bland, you must have not experienced the previous
> one:
>
> https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png
>
> In any case, I hope you realize this is an ambitious project. It will
> take a very long time to build a cohesive UI, and then also a very
> long time to update the bugs, windows, docs, wiki, etc, websites to
> use it. If you are seriously committed to this, then the next step is
> to create mock-ups for every type of page across PHP.net that you can
> find, and to share them on the PHP Webmasters mailing list (which I've
> cc'd). Then, we'll probably give you a few more pages that needs
> mocks, after which you will then have to attempt to build the mock-ups
> in a few different codebases.
>
> I did the last redesign, and I took a less rigorous approach. If I
> were to do it again, I would be much more rigorous in gathering
> requirements and building mock-ups. There were a lot of pages which
> needed re-worked because of my design, which took even more time.
> While it's okay for some pages to be re-worked content-wise to fit the
> new design, you want to minimize it.

I'm not proposing updating the UI and other websites to use, instead rebuild 
all PHP websites.

for the mock-ups, i have created a GitHub repository : 
https://github.com/azjezz/web-php-mock-ups/

this would take more time than just updating the UI, but the PHP website is 
getting old and most of it is broken or just hard to use.

i would appreciate any help or suggestions for the UI.
as it would be the first step before starting to build the new website.

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

Re: [PHP-DEV] New website for the PHP project

[azjezz]

‐‐‐ Original Message ‐‐‐
On Monday, February 4, 2019 2:32 PM, Andrey Andreev  wrote:

> Hi,
>
> I could nitpick on most of the proposed plan, but I really only wanted
> to reply to this:
>
> > > -   A new home page, not a "news" page, but a page simply showing the PHP 
> > > Logo, a code example maybe and
> > > the download link [3].
> > >
> > >
> > > [...]
> > > [3] 
> > > https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> I just hate those useless landing pages.
>
> Yes, it looks neat and clean, but after the initial "OMG so pretty"
> phase it just becomes annoying - noone cares about the code example
> and I for one never know what "Get Started" means. PHP isn't some
> consumer desktop software; nobody would just stumble upon php.net and
> "get started" with it, whatever that means ...
>
> I'm all for a modern look and all, but let's please keep the news on
> the index page. Personally, I only go to php.net to look for the news,
> changelogs and to search the docs. This image suggests that I'd need
> to do an extra click for each of those things and I'm sure I wouldn't
> be the only one unhappy about that.
>
> Cheers,
> Andrey.

The landing page is meant for the new comers to PHP, when people search for 
php, the home page is the first to appear. it make sense to show a sample and a 
straightforward button to get started with using PHP ( introduction, 
installation and tutorial )

You can see the mock up repository for what the "Getting Started" page would 
look like.

if you usually visit the website for documentation, you would just type 
php.net/documentation in the url bar instead of php.net or php.net/blog for 
changelogs and articles.

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

[PHP-DEV] New website for the PHP project

[azjezz]

Hello Internals !

As @official_php suggested [1], I'm here to propose a new website for the PHP 
Project.

In my opinion, current design looks old, outdated and bland. This sadly may 
reflect "badly" on the language

reputation nowadays.

New comers find it hard to go around the website, to write "comments", report 
issues or write RFCs.

Even signing up for the internals mailing list wasn't an easy task [2].

Since the development of PHP 8.0 has started, I think its a good idea to start 
working on a new website.

# Global proposal

The proposal here is to do a major rewrite of the PHP sites. This rewrite would 
includes php.net, windows.php.net,

bug.php.net, wiki.php.net, qa.php.net and other official php websites.

It would be done with this in mind:

* No PHP framework (to avoid favoriting one)

* Keep it simple: little to no changes to the database structures

* This site should look modern, simple and feel welcoming.

* A new home page, not a "news" page, but a page simply showing the PHP Logo, a 
code example maybe and

the download link [3].

* A new community website [4], it can be a place for people to ask questions 
and discuss php in general - no one uses IRC anymore.

* Single account: Users should be able to use the same community account to 
file bugs, create a new RFC (depending on karma) and leave notes on the 
documentation.

* Ideally all *.php.net websites would be "merged" into a single brand new 
website, but I'm not sure about the hosting

specificities (eg, what server does what).

# FrontEnd Framework

We don't need that too, but we can use one ! there's some light-weight options 
out there.

but i'm pretty sure some people in the php community have experience with 
front-end development and will happily contribute.

see :

- https://mustard-ui.com/

- https://getuikit.com/

- https://bulma.io/

- https://picturepan2.github.io/spectre/index.html

# Next steps

I would really like to hear opinions about this proposal.

[1] https://twitter.com/official_php/status/1091903415377108994

[2] https://twitter.com/SaraMG/status/1092185205572542466

[3] 
https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67

[4] https://php.net/community

---

Saif Eddin Gmati