Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/20/2016 10:18 PM, Dominic Grostate wrote:
> Just a thought that crossed my mind which might satisfy both worlds.  Has
> anyone every considered unions as a type declaration?
> 
> namespace Vector/TypeDefs
> 
> union Stringable
> {
> as string;
> as int;
> as float;
> 
> private $value;
> 
> public function __make($type)
> {
> switch (type) {
> case 'string': return (string) $this->value;
> case 'int':return (int)$this->value;
> case 'float':  return (float)  $this->value;
> }
> }
> }
> 
> my_echo_func("123"); // << A scalar variable on the outside.
> 
> function my_echo_func(Stringable $stringable) // << a union on the inside
> {
> var_dump($stringable as string); // string(3) "123"
> var_dump($stringable as int);   // int(123)
> var_dump($stringable as float);  // float(123.0)
> }
> 
> Perhaps not exactly like this, but adding unions as type of class
> declaration should save a hell of a lot of keywords, and may save a number
> of "instanceof" type checks as well.
> 

I do not like the idea because these types directly become part of your
public API and you end up including a dozen packages just to get the
basic union types in. More IO, more cache utilization, more
dependencies, ...

Also, one cannot change any type that was ever declared without a direct
BC. No, sorry, I thing that this is very bad. :(

However, the idea to make objects castable to more of the various scalar
types is not new and would be awesome.

interface Object {

  function __toBool(): bool;
  function __toFloat(): float;
  function __toInt(): int;
  function __toString(): string;

  function __toArray(): array;
  function __toObject(): object;
  function __toResource(): resource;

}

Auto-conversion only if not ambiguous (`$o1 + $o2` where both have
`__toInt()` and `__toFloat()` throws an ?Error but `(float)$o1 +
(float)$o2` works so does `intdiv($o1, $o2)`), next is operator
overloading. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Dominic Grostate]

Just a thought that crossed my mind which might satisfy both worlds.  Has
anyone every considered unions as a type declaration?

namespace Vector/TypeDefs

union Stringable
{
as string;
as int;
as float;

private $value;

public function __make($type)
{
switch (type) {
case 'string': return (string) $this->value;
case 'int':return (int)$this->value;
case 'float':  return (float)  $this->value;
}
}
}

my_echo_func("123"); // << A scalar variable on the outside.

function my_echo_func(Stringable $stringable) // << a union on the inside
{
var_dump($stringable as string); // string(3) "123"
var_dump($stringable as int);   // int(123)
var_dump($stringable as float);  // float(123.0)
}

Perhaps not exactly like this, but adding unions as type of class
declaration should save a hell of a lot of keywords, and may save a number
of "instanceof" type checks as well.

On 20 April 2016 at 20:55, Fleshgrinder  wrote:

> I am not quoting anything because the formatting of your emails is
> completely off in Thunderbird. However, I want to add one to the list:
>
> declare(strict_types=1);
>
> interface Stringable {
> function __toString(): string;
> }
>
> function fn(string|Stringable $arg) {
> $param = (string) $arg;
> }
>
> We could add a new *stringable* primitive to PHP though, but do we guys
> really want to start doing so? There is pretty much an endless amount of
> combinations and finding names alone is endlessly hard.
>
> declare(strict_types=1);
>
> function fn(int|string $maybe_bigint) {
> // mysqlnd automatically creates the proper type based on the value.
> // Expressing this in userland is impossible ... :(
> }
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

I am not quoting anything because the formatting of your emails is
completely off in Thunderbird. However, I want to add one to the list:

declare(strict_types=1);

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
$param = (string) $arg;
}

We could add a new *stringable* primitive to PHP though, but do we guys
really want to start doing so? There is pretty much an endless amount of
combinations and finding names alone is endlessly hard.

declare(strict_types=1);

function fn(int|string $maybe_bigint) {
// mysqlnd automatically creates the proper type based on the value.
// Expressing this in userland is impossible ... :(
}

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/19/2016 10:19 PM, Zeev Suraski wrote:
> I can only repeat - primitive types can and should get dedicated solutions.  
> There's really no need for allowing over creativity with userland-customized 
> scalar types.  If we think that a certain scalar definition makes a lot of 
> sense, we can add it at the language level.  There's no need to complicate 
> the language, add syntax which makes no sense for objects and isn't really 
> needed for scalars either.
> 

We can for many:

type number := int|float
type object := 
type scalar := bool|int|float|string
...

However, what about:

type ? := array|Traversable
type ? := int|string
type ? := float|string
type ? := bool|null
...

I actually argue that we do not even want to define them on a language
level (with the exception of array|Traversable) because these
combinations are too usecase specific.

>> interface HouseCat {
>> function drink();
>> }
>>
>> interface Dog {
>> function eat();
>> }
>>
>> -interface Lion {
>> +interface Lion extends HouseCat, Dog{
>> function drink();
>> function eat();
>> }
> 
> Pardon me saying this but it doesn't appear as if you've read what I wrote.  
> Please take a look at the 'diff' I made in the definition of your Lion class, 
> because without it, your sample and mine have little to do with each other.
> 
> With that change in place, please reevaluate whether what you said is 
> relevant:
> 

I guess I just jumped over that fact and misinterpreted it because what
you are proposing is a magic intersection type limited to interfaces.
While I cannot think of a situation where this creates problems from a
technical point of view (it is duck typing after all) I find it highly,
highly unusual and way too magic as well as even confusing.

I think there are two ways:

- No union/intersection at all!
+ Union and intersection!

Going somewhere in between destroys generics, bounded quantification,
and F-bounded quantification in the future or at least makes it harder
to implement cleanly. You need to consider that this RFC might be voted
negative but it might come back in PHP 8 or PHP 9 where the landscape
has changed so vastly that it might become a yes.

Let's not introduce half backed features that nobody ever implemented
and found useful in any context or we end up with more weirdness that we
already have a some points.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On Behalf Of 
Jesse Schalken
Sent: Wednesday, April 20, 2016 4:42 PM
To: Zeev Suraski <z...@zend.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: Improving PHP's type system



On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski 
<z...@zend.com<mailto:z...@zend.com>> wrote:

On 20 באפר׳ 2016, at 14:54, Jesse Schalken 
<m...@jesseschalken.com<mailto:m...@jesseschalken.com>> wrote:
If I had "scalar", "number" and ?T as types, the types I would need would be:

  1.  ?scalar|Decimal

What's decimal?  I'm not aware we have that type.  Apologies if I missed it 
that it was added.

As I said:

I have a function that converts values to SQL which have SQL equivalents, 
including decimal values represented by a special Decimal class. It accepts 
int|string|bool|null|float|Decimal.

Zeev> So just use a container class (SQLValue or whatnot) that can include a 
scalar or a Decimal, and use this instead.  It would probably result in a 
cleaner function body anyway.


  1.  ?scalar|Decimal|Expr

What's Expr?  Again I'm not aware that we have that type.

As I said:

I have a class Expr which represents an expression in SQL. Expressions can be 
composed of other expressions, and of literal values, so the constructors for 
Exprs accept int|string|bool|null|float|Decimal|Expr.

Zeev> Same as above.  Another option of course is to handle the type checks 
inside – that depends on whether you want to handle the details inside the 
SQLValue class or inside the function that accepts it.


  1.  ?scalar|array
Conduct this check in user code, you'd have to anyway.

Not if I'm giving it straight to json_encode() I don't.

Zeev> Why not let json_encode() do the type checking then?

  1.  int|string (I want int|string here. I know array keys are always 
int|string. A wider type is lies.)
This is needlessly purist.  For handling a meaningless con, we'd overcomplicate 
the language and provide a footgun(tm) for everyone.  Not a good bargain.

int|string is the correct type. If you're going to dismiss correctness as 
"needlessly purist" then I'm going to dismiss PHP as not intended for writing 
correct software.

Zeev> Purism by definition – in all areas of life - insists it’s the one and 
only correct way to look at things.  PHP has never been about purism, and we’re 
not going to start now.  Instead of adjusting to how PHP models scalars, or 
moving to another language (both very valid options) – you insist on saying PHP 
must change to be your way.

  1.  T|false
You didn't answer my question on this one.

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.

Zeev> Why is it important to have a type that maps the return values of these 
functions?  What does it buy you?

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski  wrote:

>
> On 20 באפר׳ 2016, at 14:54, Jesse Schalken  wrote:
>
> If I had "scalar", "number" and ?T as types, the types I would need would
> be:
>
>1. ?scalar|Decimal
>
>
> What's decimal?  I'm not aware we have that type.  Apologies if I missed
> it that it was added.
>

As I said:

I have a function that converts values to SQL which have SQL equivalents,
> including decimal values represented by a special Decimal class. It accepts
> int|string|bool|null|float|Decimal.


All of int|string|bool|null|float can be converted to SQL
straightforwardly, however, MySQL has a distinct decimal type for exact
decimal values, written like "8542.31" in SQL (to get write a float, you
need "8542.31e0"). My class Decimal is used to represent a MySQL value of
type decimal, so it can be passed without be lossily converted to/from
float, and so it can be converted to the correct SQL. It is neither a float
nor an integer. A distinct class is needed for it.

>
>1. ?scalar|Decimal|Expr
>
>
> What's Expr?  Again I'm not aware that we have that type.
>

As I said:

I have a class Expr which represents an expression in SQL. Expressions can
> be composed of other expressions, and of literal values, so the
> constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.



In both, a nullable scalar does the job.
>
>
>1. ?scalar|array
>
> Conduct this check in user code, you'd have to anyway.
>

Not if I'm giving it straight to json_encode() I don't.


>
>1. int|string (I *want* int|string here. I know array keys are always
>int|string. A wider type is lies.)
>
> This is needlessly purist.  For handling a meaningless con, we'd
> overcomplicate the language and provide a footgun(tm) for everyone.  Not a
> good bargain.
>

int|string is the correct type. If you're going to dismiss correctness as
"needlessly purist" then I'm going to dismiss PHP as not intended for
writing correct software.

>
>1. ?scalar (probably)
>
> Ok
>
>
>1. number
>
> Ok
>
>
>1. T|false
>
> You didn't answer my question on this one.
>

substr() returns string|false
file_get_contents() returns string|false
fopen() returns resource|false
strpos() returns int|false
etc..

Without unions, the types of these functions cannot be denoted.


>1. ?T
>
> Ok
>
> 5 out of 8 still need a union.
>
>
> Actually, in my count only one of them does (#7) and it's probably
> solvable (if it's even a thing), and in another, it makes no sense to use
> types at all (#3) as you'd have to do these checks in userland anyway.  All
> others can be satisfied just fine with scalar, numeric and nullable types,
> unless you're being needlessly purist - and we're not going to
> overcomplicate the language for the sake of purism.
>
> Zeev
>

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Tom Worster [mailto:f...@thefsb.org]
> Sent: Wednesday, April 20, 2016 4:24 PM
> To: Rick Widmer <vch...@developersdesk.com>; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> On 4/19/16 7:21 PM, Rick Widmer wrote:
> > Are too many of these incompatible shiny things, too fast, the main
> > reason so many PHP users are on older versions?
> >
> > IMHO, yes.
> 
> This would mean, by an large, that people had tried a more recent version of
> PHP and found that their code was incompatible. I think on the contrary that
> they haven't tried because they have little motive. A lot of running apps are 
> in
> maintenance mode with no significant investments in new code, without
> which it's easier to take the attitude that it's not broken so don't mess 
> around
> with it.

It's more complicated than that - people don't actually have to try and upgrade 
in order to know (or think they know) that they'll have to invest time and 
efforts in getting their code to run on a new version.  They guess as much.

That said, I don't think the issue with shiny new things is that they introduce 
incompatibilities.  They rarely do - I think the biggest source of 
incompatibilities we have is removal of deprecated features and not 
introduction of new ones.  Shiny new features have other issues - increased 
cognitive burden, increased code complexity, etc. - but typically introduction 
of incompatibilities is not one of them.

However, we can learn that the attractiveness of new features in PHP is not 
very high - or we'd see much faster adoption of new versions (which also leads 
me to believe that we're spending too much effort on the wrong things).  I 
think we're going to see much faster adoption of 7.0 - but in my experience at 
least, it's predominantly the increased performance and reduced memory 
consumption that gets people excited - the new features are secondary if they 
play any role at the decision.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Tom Worster]

On 4/19/16 7:21 PM, Rick Widmer wrote:

Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?

IMHO, yes.


This would mean, by an large, that people had tried a more recent 
version of PHP and found that their code was incompatible. I think on 
the contrary that they haven't tried because they have little motive. A 
lot of running apps are in maintenance mode with no significant 
investments in new code, without which it's easier to take the attitude 
that it's not broken so don't mess around with it.


Tom


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

On 20 ? 2016, at 14:54, Jesse Schalken 
> wrote:

If I had "scalar", "number" and ?T as types, the types I would need would be:

  1.  ?scalar|Decimal

What's decimal?  I'm not aware we have that type.  Apologies if I missed it 
that it was added.

  1.  ?scalar|Decimal|Expr

What's Expr?  Again I'm not aware that we have that type.

In both, a nullable scalar does the job.

  1.  ?scalar|array

Conduct this check in user code, you'd have to anyway.

  1.  int|string (I want int|string here. I know array keys are always 
int|string. A wider type is lies.)

This is needlessly purist.  For handling a meaningless con, we'd overcomplicate 
the language and provide a footgun(tm) for everyone.  Not a good bargain.

  1.  ?scalar (probably)

Ok

  1.  number

Ok

  1.  T|false

You didn't answer my question on this one.

  1.  ?T

Ok

5 out of 8 still need a union.

Actually, in my count only one of them does (#7) and it's probably solvable (if 
it's even a thing), and in another, it makes no sense to use types at all (#3) 
as you'd have to do these checks in userland anyway.  All others can be 
satisfied just fine with scalar, numeric and nullable types, unless you're 
being needlessly purist - and we're not going to overcomplicate the language 
for the sake of purism.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

I just noticed I originally missed "array" for #3. (The type is technically
recursive, ie "type Jsonable = int|string|float|bool|null|array",
but that's another can of worms.)

On Wed, Apr 20, 2016 at 9:54 PM, Jesse Schalken <m...@jesseschalken.com>
wrote:

> If I had "scalar", "number" and ?T as types, the types I would need would
> be:
>
>1. ?scalar|Decimal
>2. ?scalar|Decimal|Expr
>3. ?scalar|array
>4. int|string (I *want* int|string here. I know array keys are always
>int|string. A wider type is lies.)
>5. ?scalar (probably)
>6. number
>7. T|false
>8. ?T
>
> 5 out of 8 still need a union.
>
> On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski <z...@zend.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
>> > Behalf Of Jesse Schalken
>> > Sent: Wednesday, April 20, 2016 1:12 PM
>> > To: Johannes Schlüter <johan...@schlueters.de>
>> > Cc: Andrea Faulds <a...@ajf.me>; PHP internals <internals@lists.php.net>
>> > Subject: Re: [PHP-DEV] Re: Improving PHP's type system
>> >
>> >1. I have a function that converts values to SQL which have SQL
>> >equivalents, including decimal values represented by a special
>> Decimal
>> >class. It accepts int|string|bool|null|float|Decimal.
>> >2. I have a class Expr which represents an expression in SQL.
>> >Expressions can be composed of other expressions, and of literal
>> values, so
>> >the constructors for Exprs accept
>> int|string|bool|null|float|Decimal|Expr.
>> >3. I have a function that converts values to JSON that can be
>> reliably
>> >converted back into their original. It accepts
>> int|string|bool|null|float.
>>
>> In other words, they accepts scalars (or nullable scalars).  Introducing
>> a scalar type would do the job.
>>
>> >4. I have a function that returns the first key in an array (or
>> throws
>> >an exception if empty). It returns int|string.
>>
>> I'd argue that here too, a scalar would be fine.  Worrying about a
>> floating point here is not a very relevant worry.
>>
>> >5. I have a function that returns a value for a key in an array, and
>> >removes the key. The type of the key is things that are valid array
>> keys
>> >(int|string|bool|null IIRC).
>>
>> Scalar (or nullable scalar).
>>
>> >6. I have a set of functions which operates on numbers. They accept
>> >int|float.
>>
>> Numeric (to also include strings that look like numbers when strict is
>> not on).
>>
>> >7. All the PHP functions which say "returns ... or FALSE on failure"
>> >have their correct return type as T|false (where T is the return
>> value on
>> >success) (or T|bool is "false" is not an allowed type).
>>
>> How many of those do we have?  As opposed to T|null?  I think most
>> functions that return objects return null on failure, not false.  And those
>> who don't can probably evolve to that approach.
>>
>> >8. Nullability is nothing but a special case of union type with
>> T|null.
>>
>> Academically that's true, but practically speaking, the general T1|T2 is
>> almost always bogus while T|null subset makes a lot of sense.
>>
>> In reality, we can solve all the relevant use cases for union types by
>> relatively minor tweaks (or rather additions) to our scalar type hints, by
>> adding nullability, and by using interfaces where they make sense.
>>
>> Zeev
>>
>
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

If I had "scalar", "number" and ?T as types, the types I would need would
be:

   1. ?scalar|Decimal
   2. ?scalar|Decimal|Expr
   3. ?scalar|array
   4. int|string (I *want* int|string here. I know array keys are always
   int|string. A wider type is lies.)
   5. ?scalar (probably)
   6. number
   7. T|false
   8. ?T

5 out of 8 still need a union.

On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski <z...@zend.com> wrote:

>
>
> > -Original Message-
> > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
> > Behalf Of Jesse Schalken
> > Sent: Wednesday, April 20, 2016 1:12 PM
> > To: Johannes Schlüter <johan...@schlueters.de>
> > Cc: Andrea Faulds <a...@ajf.me>; PHP internals <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> >
> >1. I have a function that converts values to SQL which have SQL
> >equivalents, including decimal values represented by a special Decimal
> >class. It accepts int|string|bool|null|float|Decimal.
> >2. I have a class Expr which represents an expression in SQL.
> >Expressions can be composed of other expressions, and of literal
> values, so
> >the constructors for Exprs accept
> int|string|bool|null|float|Decimal|Expr.
> >3. I have a function that converts values to JSON that can be reliably
> >converted back into their original. It accepts
> int|string|bool|null|float.
>
> In other words, they accepts scalars (or nullable scalars).  Introducing a
> scalar type would do the job.
>
> >4. I have a function that returns the first key in an array (or throws
> >an exception if empty). It returns int|string.
>
> I'd argue that here too, a scalar would be fine.  Worrying about a
> floating point here is not a very relevant worry.
>
> >5. I have a function that returns a value for a key in an array, and
> >removes the key. The type of the key is things that are valid array
> keys
> >(int|string|bool|null IIRC).
>
> Scalar (or nullable scalar).
>
> >6. I have a set of functions which operates on numbers. They accept
> >int|float.
>
> Numeric (to also include strings that look like numbers when strict is not
> on).
>
> >7. All the PHP functions which say "returns ... or FALSE on failure"
> >have their correct return type as T|false (where T is the return
> value on
> >success) (or T|bool is "false" is not an allowed type).
>
> How many of those do we have?  As opposed to T|null?  I think most
> functions that return objects return null on failure, not false.  And those
> who don't can probably evolve to that approach.
>
> >8. Nullability is nothing but a special case of union type with
> T|null.
>
> Academically that's true, but practically speaking, the general T1|T2 is
> almost always bogus while T|null subset makes a lot of sense.
>
> In reality, we can solve all the relevant use cases for union types by
> relatively minor tweaks (or rather additions) to our scalar type hints, by
> adding nullability, and by using interfaces where they make sense.
>
> Zeev
>

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On
> Behalf Of Jesse Schalken
> Sent: Wednesday, April 20, 2016 1:12 PM
> To: Johannes Schlüter <johan...@schlueters.de>
> Cc: Andrea Faulds <a...@ajf.me>; PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
>1. I have a function that converts values to SQL which have SQL
>equivalents, including decimal values represented by a special Decimal
>class. It accepts int|string|bool|null|float|Decimal.
>2. I have a class Expr which represents an expression in SQL.
>Expressions can be composed of other expressions, and of literal values, so
>the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.
>3. I have a function that converts values to JSON that can be reliably
>converted back into their original. It accepts int|string|bool|null|float.

In other words, they accepts scalars (or nullable scalars).  Introducing a 
scalar type would do the job.

>4. I have a function that returns the first key in an array (or throws
>an exception if empty). It returns int|string.

I'd argue that here too, a scalar would be fine.  Worrying about a floating 
point here is not a very relevant worry.

>5. I have a function that returns a value for a key in an array, and
>removes the key. The type of the key is things that are valid array keys
>(int|string|bool|null IIRC).

Scalar (or nullable scalar).

>6. I have a set of functions which operates on numbers. They accept
>int|float.

Numeric (to also include strings that look like numbers when strict is not on).

>7. All the PHP functions which say "returns ... or FALSE on failure"
>have their correct return type as T|false (where T is the return value on
>success) (or T|bool is "false" is not an allowed type).

How many of those do we have?  As opposed to T|null?  I think most functions 
that return objects return null on failure, not false.  And those who don't can 
probably evolve to that approach.

>8. Nullability is nothing but a special case of union type with T|null.

Academically that's true, but practically speaking, the general T1|T2 is almost 
always bogus while T|null subset makes a lot of sense.

In reality, we can solve all the relevant use cases for union types by 
relatively minor tweaks (or rather additions) to our scalar type hints, by 
adding nullability, and by using interfaces where they make sense.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

   1. I have a function that converts values to SQL which have SQL
   equivalents, including decimal values represented by a special Decimal
   class. It accepts int|string|bool|null|float|Decimal.
   2. I have a class Expr which represents an expression in SQL.
   Expressions can be composed of other expressions, and of literal values, so
   the constructors for Exprs accept int|string|bool|null|float|Decimal|Expr.
   3. I have a function that converts values to JSON that can be reliably
   converted back into their original. It accepts int|string|bool|null|float.
   4. I have a function that returns the first key in an array (or throws
   an exception if empty). It returns int|string.
   5. I have a function that returns a value for a key in an array, and
   removes the key. The type of the key is things that are valid array keys
   (int|string|bool|null IIRC).
   6. I have a set of functions which operates on numbers. They accept
   int|float.
   7. All the PHP functions which say "returns ... or FALSE on failure"
   have their correct return type as T|false (where T is the return value on
   success) (or T|bool is "false" is not an allowed type).
   8. Nullability is nothing but a special case of union type with T|null.

If you need more examples, search some PHP codebases for PHPDoc blocks with
union types with a regex, like "@(param|var)\s*(\$\w+\s*)?\w+\|".


On Wed, Apr 20, 2016 at 7:46 PM, Johannes Schlüter 
wrote:

> On Wed, 2016-04-20 at 17:57 +1000, Jesse Schalken wrote:
> >
> > With unions:
> >
> > function foo(Bar|string $b) {
> >
> > if (is_string($b)) {
> > // ...
> > } else {
> > // I know $b is a Bar here. I don't need to check. :)
> > }
> > }
>
> I' still missing a real-life use case for this. There's no operation I
> can come up with which works with an object or string.
>
> Unions between object types should be handled via interface.
>
> The only relevant union types I found till now are
>
>   array | Traversable
>   array | Countable
>
> and eventually
>
>   array | Offset[Get|Set]
>
> The last one is a bit critical due to the fact that arrays are value
> types, whereas objects are reference types so
>
>function ($a) {
>$a[] = 42;
>}
>
> behaves notably differently between objects and arrays. So that case
> might need some thinking. For the others instead of a generic union type
> I'd prefer a special array-solution.
>
> johannes
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Johannes Schlüter]

On Wed, 2016-04-20 at 18:32 +1000, Jesse Schalken wrote:
> On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An 
> wrote:
> 
> >
> > I think the original purpose of adding type system in Hack, is to provide
> > just-in-time compilation, this provides more information to let compiler to
> > optimize the code with specific type.
> >
> >
> Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
> and doesn't use the Hack type annotations for any optimisation. It's is
> really just another dynamic language JIT, like V8 and Chakra.
> 
> The purpose of type annotations and type checkers for dynamic languages,
> including Hack, TypeScript and Flow, is not necessarily to improve
> performance but to improve developer efficiency. Wherever there exists a
> type annotation which is enforced, either statically or at runtime, the
> developer has gained important knowledge to inform the modification of the
> program, and can do so with increased certainty and predictability.

For that there is some research:

How many bugs does static type checking catch?
[...]
answer: 2%.
[...]
not only were development times significantly shorter on average
with dynamically typed languages, so were debug times.

So all those nasty type errors were actually not having any
negative impact on debug times, in fact the reverse was true.

http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Re: Improving PHP's type system

[Johannes Schlüter]

On Wed, 2016-04-20 at 17:57 +1000, Jesse Schalken wrote:
> 
> With unions:
> 
> function foo(Bar|string $b) {
> 
> if (is_string($b)) {
> // ...
> } else {
> // I know $b is a Bar here. I don't need to check. :)
> }
> }

I' still missing a real-life use case for this. There's no operation I
can come up with which works with an object or string.

Unions between object types should be handled via interface.

The only relevant union types I found till now are

  array | Traversable
  array | Countable

and eventually

  array | Offset[Get|Set]

The last one is a bit critical due to the fact that arrays are value
types, whereas objects are reference types so

   function ($a) {
   $a[] = 42;
   }

behaves notably differently between objects and arrays. So that case
might need some thinking. For the others instead of a generic union type
I'd prefer a special array-solution.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 20/04/16 00:34, Johannes Schlüter wrote:
> On Wed, 2016-04-20 at 00:09 +0200, Marco Pivetta wrote:
>> > In Doctrine ORM, having a way to know that a field or parameter is a
>> > `string | null` or a `int | float` may be the difference between
>> > knowing
>> > what kind of column definition is needed for a field at DB level,
>> > without
>> > even need for defining manual mappings.
> So what's the column definition if you see `string | null`? A PHP string
> can have (almost) arbitrary length and binary data, so this is a BLOB?
> Most likely not what the user wants. 
> 
> The PHP type hardly describes the constraints by the application. This
> might add a small sanity check but by no means a game changer.

String length, size of integer and accuracy of numeric all affect the
definition of the schema at the DB level which adding a little twiddly
bit does nothing to provide an expandable type definition. I'm not
objecting to a type system per-say but even the bits that have been
bodged into PHP7 already do not provide a route forward for REAL data
validation?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

On Thu, Apr 14, 2016 at 10:47 PM, Lin Yo-An 
wrote:

>
> I think the original purpose of adding type system in Hack, is to provide
> just-in-time compilation, this provides more information to let compiler to
> optimize the code with specific type.
>
>
Last I checked, the HHVM JIT treats PHP and Hack code roughly identically
and doesn't use the Hack type annotations for any optimisation. It's is
really just another dynamic language JIT, like V8 and Chakra.

The purpose of type annotations and type checkers for dynamic languages,
including Hack, TypeScript and Flow, is not necessarily to improve
performance but to improve developer efficiency. Wherever there exists a
type annotation which is enforced, either statically or at runtime, the
developer has gained important knowledge to inform the modification of the
program, and can do so with increased certainty and predictability.

Re: [PHP-DEV] Re: Improving PHP's type system

[Jesse Schalken]

Without type annotations:

function foo($b) {

if (!is_string($b)) {

// Ugh, why can't the language enforce this?

throw new Exception("needed a string");

}

}


With type annotations:

function foo(string $b) {

// I know $b is a string. I don't need to check. :)

}


Without unions:

function foo($b) {
if (is_string($b)) {
// ...
} else if ($b instanceof Bar) {
// ...

} else {

   // Ugh, why can't the language enforce this?

throw new Exception("needed a string|Bar");

}

}


With unions:

function foo(Bar|string $b) {

if (is_string($b)) {
// ...
} else {
// I know $b is a Bar here. I don't need to check. :)
}
}


In both cases, the type annotation has removed the 1 check and the need to
throw an exception. It's the exact same benefit.


On Sat, Apr 16, 2016 at 1:10 AM, Andrea Faulds  wrote:

> Hi Stas,
>
> Stanislav Malyshev wrote:
>
>> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>> since it is super self-explanatory. However, I find myself checking the
>>>
>>
>> It may be self-explanatory for you. It's much less self-explanatory for
>> somebody just starting to learn. It is also very dangerous - if it's
>> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
>> or not string, can you call strlen on it? Etc., etc. It adds a lot of
>> cognitive load and complicates the whole picture. You may have a
>> specific use case where it is useful (which we have yet to see btw) but
>> please remember it's a language with literally millions of use cases and
>> users.
>>
>
> This is something that particularly concerns me about union types, in that
> they reduce type safety. If you have a union type of Foo|Bar for some
> variable, then the set of methods you can call on that variable is actually
> the intersection, not the union, of the set of methods you can call on Foo
> and Bar. Which, unless those two classes share some interface, is probably
> an empty set. So there's nothing you can actually do safely with it without
> doing checks within the body of the function, and if you're doing that,
> then why do we have a type declaration? It's only barely more useful than
> omitting a type declaration at all; type declarations are supposed to
> prevent you needing to check. On the other hand, if the two classes share
> some methods, then either there's an interface you can already use here, or
> you can create one. Either way, you don't need a union type.
>
> There are some cases where you can't create an interface, but if that's
> the case, I think it is more worthwhile to look at how we can fix those
> cases, rather than add what amounts to a hacky workaround.
>
> Thanks!
> --
> Andrea Faulds
> https://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Johannes Schlüter]

On Tue, 2016-04-19 at 17:21 -0600, Rick Widmer wrote:
> 
> Are too many of these incompatible shiny things, too fast, the main 
> reason so many PHP users are on older versions?

There are many reasons. Often the reason is simply that many cheap
hosting companies or admins don't want to spend time to update. For them
this is only a cost. And there are no game changers which create
pressure. All major applications work on "old" versions and for the
individual developer it is hard to argue "oh, I want to use the <=>
operator" as the work-around is trivial.

Hosters had to offer 5 quite quickly since that was a big game changer
with the new object model.
 
johannes



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> So the Symfony2 routing and Doctrine ORM are academic proof of concepts?

I'm sorry I'm a bit lost about how you got from "prioritizing
'interesting playground' is more suited for academic PoC than for a
mature language" to "Doctrine ORM is an academic PoC". I have little
knowledge on what Doctrine ORM implementation is, but I'm pretty sure
deep technical details of Doctrine ORM should not be primary driver in
designing PHP's type system. There's a lot of ways to write ORM, and I'm
sure Doctrine developers are smart enough to do what is necessary. If
there's some generic lesson they can give us that would serve everybody
- let's hear it then.

> We got to the point of inventing language features by building hacks around
> the engine (Levi and I had a heated discussion about it) due to practical
> necessity, not due to technical/academic onanism.

I appreciate that your specific use case requires certain things. I even
think there is a good concept for these things, if I understand them
right - namely, annotations - and those are used in many other
environments (see? I'm not afraid to quote other languages where it is
appropriate! ;) What I am questioning is that wiring those things into
PHP type system is the right move.

> Removing the hacks and replacing them with actual language features would
> be the way to go here, but let's just keep assuming that wordpress is the
> baseline for good software in 2016.

I have little idea what you referring to here, but I assume you think
wordpress is actually bad software, though I am still a bit lost as to
how it connects to the rest of the discussion.

There are a lot of additions that may improve PHP in many practical
ways. I just think right now there's a bit too much focus on adding new
syntax that adds much more complexity than it's worth. I'm not against
adding new syntax per se, I guess I just want more necessary
capabilities enabled per complexity added ratio.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Johannes Schlüter]

On Wed, 2016-04-20 at 00:09 +0200, Marco Pivetta wrote:
> In Doctrine ORM, having a way to know that a field or parameter is a
> `string | null` or a `int | float` may be the difference between
> knowing
> what kind of column definition is needed for a field at DB level,
> without
> even need for defining manual mappings.

So what's the column definition if you see `string | null`? A PHP string
can have (almost) arbitrary length and binary data, so this is a BLOB?
Most likely not what the user wants. 

The PHP type hardly describes the constraints by the application. This
might add a small sanity check but by no means a game changer.

johannes



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> Are too many of these incompatible shiny things, too fast, the main
> reason so many PHP users are on older versions?

Probably not directly. The reason is PHP 5, as is, is pretty darn good
tool for what it is being used for. Of course, it could be 10x faster,
it could have more extensions and it could have multithreading and
native Unicode support ;) But even as is, it's not bad and allows to do
a lot. So people do not feel a burning need to jump to a new version
yet, let alone learn new concepts and develop new frameworks based on
these concepts. It doesn't mean what we have added in PHP 7 is bad - but
it'll probably take some time until people start really using it.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Rick Widmer]

On 4/19/2016 5:10 PM, Stanislav Malyshev wrote:


In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static


That's my point - "more interesting playground" does not sound like a
reason enough to mess with the type system of the language used by
millions. This sounds like a good description of a thesis project or a
academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for. I completely agree
that *if* we added a ton of shiny things into PHP then there would be a
lot of interesting stuff to play with. I am saying that is not the
reason enough to actually add them.


Are too many of these incompatible shiny things, too fast, the main 
reason so many PHP users are on older versions?


IMHO, yes.


Rick



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

Re: [PHP-DEV] Re: Improving PHP's type system

[Marco Pivetta]

On 20 April 2016 at 01:12, Ronald Chmara  wrote:

> On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta  wrote:
> > In general, improving the type system provides a much more interesting
> and
> > practical playground for any kind of tool that would rely on static
> > introspection: IDEs, reflectors, code generators, code inliners,
>
> So, tooling that relies upon (more) strict typing is less useful for
> for PHP, therefore, rather than change the tooling to be more capable
> with looser typing, change PHP?
>

The tooling already works with annotations, but there is no actual "safety"
introduced by these hacks.

This sounds like a good description of a thesis project or a
> academic proof-of-concept language, not something mature widely-used
> language prizing simplicity should be aiming for.

So the Symfony2 routing and Doctrine ORM are academic proof of concepts?
We got to the point of inventing language features by building hacks around
the engine (Levi and I had a heated discussion about it) due to practical
necessity, not due to technical/academic onanism.
Removing the hacks and replacing them with actual language features would
be the way to go here, but let's just keep assuming that wordpress is the
baseline for good software in 2016.

I think I'm just going to mute the thread.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Re: Improving PHP's type system

[Ronald Chmara]

On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta  wrote:
> In general, improving the type system provides a much more interesting and
> practical playground for any kind of tool that would rely on static
> introspection: IDEs, reflectors, code generators, code inliners,

So, tooling that relies upon (more) strict typing is less useful for
for PHP, therefore, rather than change the tooling to be more capable
with looser typing, change PHP?

-Ronabop

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> Any reflector-based system, such as a serializer, an ORM or just a
> dependency injection or configuration loader would be able to do operations
> in a much more precise and less complex way.

This should be solved by annotations. Yes, I know all the story, but it
does not change the fact that ORM serialization is not the same as
internal PHP typing, and arguing we need to change PHP typing system
because it makes it easier for (a particular) ORM serializer is putting
the cart in front of the horse.

> Having a configuration system that expects to call setters with specific
> parameter types can allow the configuration system to validate the given
> data upfront, providing meaningful exceptions to the user, without having
> to write an entire separate config specification.

We already have system that provides meaningful exceptions to the user.
It's called PHP engine. The system you describe changes nothing but
wording of error messages. This is not really worth changing the typing
system in PHP.

> Having a serializer that expects certain types of data allows rejecting any
> kind of value that is possibly insecure, and would cause a RCE
> vulnerability by unserializing a value into something with a malicious
> `__wakeup` in it.

All examples of unserialize problems so far were in the engine and those
examples have all the types already known, the problem was/is
unserializer has no way to use this information. This problem is not
solved by adding more syntax.

> In general, improving the type system provides a much more interesting and
> practical playground for any kind of tool that would rely on static

That's my point - "more interesting playground" does not sound like a
reason enough to mess with the type system of the language used by
millions. This sounds like a good description of a thesis project or a
academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for. I completely agree
that *if* we added a ton of shiny things into PHP then there would be a
lot of interesting stuff to play with. I am saying that is not the
reason enough to actually add 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] Re: Improving PHP's type system

[Rick Widmer]

On 4/19/2016 2:41 PM, Stanislav Malyshev wrote:

I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Maybe we gained more - I don't know yet, as most of our user base isn't
even on 5.5 by now. But it does worry me that we are not only losing it
- we seem to be actively trying to get rid of it.





I just thought that needed to be repeated!


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Marco Pivetta]

On 20 April 2016 at 00:30, Zeev Suraski  wrote:

>
> this is not a make or break feature for PHP.
>

That's why it's called a "feature"

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

On 20 ? 2016, at 1:10, Marco Pivetta 
> wrote:

On 19 April 2016 at 23:47, Zeev Suraski > 
wrote:
I fail to see how adding C++ templates to PHP takes it to the next level in 
anything but the complexity scale.  Not having them is not preventing anybody 
from doing anything today.  Sure, a bunch of frameworks would adopt them once 
they become available - but it will not enable them to do things that are 
radically different from what they're doing today.

And the fact that you fail to see it is why you don't see any advantages, but 
that's because you are likely unfamiliar with most recent tooling around static 
introspection.

Saying that a given feature will not take PHP to the next level is not at all 
the same as saying I don't see any advantages.  I did not say the latter, and I 
stand behind the former.  As I said, I'm sure frameworks would use it and there 
are obviously some valid use cases for it, but it won't change the way the vast 
majority of people develop code.  Forget for a minute whether we should or 
shouldn't add it - this is not a make or break feature for PHP.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Marco Pivetta]

On 19 April 2016 at 23:47, Zeev Suraski  wrote:

> I fail to see how adding C++ templates to PHP takes it to the next level
> in anything but the complexity scale.  Not having them is not preventing
> anybody from doing anything today.  Sure, a bunch of frameworks would adopt
> them once they become available - but it will not enable them to do things
> that are radically different from what they're doing today.
>

And the fact that you fail to see it is why you don't see any advantages,
but that's because you are likely unfamiliar with most recent tooling
around static introspection.

Any reflector-based system, such as a serializer, an ORM or just a
dependency injection or configuration loader would be able to do operations
in a much more precise and less complex way.

In Doctrine ORM, having a way to know that a field or parameter is a
`string | null` or a `int | float` may be the difference between knowing
what kind of column definition is needed for a field at DB level, without
even need for defining manual mappings.

Having a configuration system that expects to call setters with specific
parameter types can allow the configuration system to validate the given
data upfront, providing meaningful exceptions to the user, without having
to write an entire separate config specification.

Having a serializer that expects certain types of data allows rejecting any
kind of value that is possibly insecure, and would cause a RCE
vulnerability by unserializing a value into something with a malicious
`__wakeup` in it.

Etc etc.

In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static
introspection: IDEs, reflectors, code generators, code inliners,
documentation generators.

The runtime part of this is just a tiny fraction of what is interesting
about improving the type system at all.

Hope that gives some useful context, in order to see where this would
actually be useful.

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf
> Of Levi Morrison
> Sent: Wednesday, April 20, 2016 12:23 AM
> To: Zeev Suraski <z...@zend.com>
> Cc: Larry Garfield <la...@garfieldtech.com>; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> > IMHO, it would be AWESOME if we could funnel some of these cycles from
> new syntax and onto other things like parallel processing, async IO, JIT and
> more - which can truly take PHP to the next level.  New syntax cannot.
> 
> The time investment for those projects is enormous. Not many developers
> have the time or capability to add these things.


But that's what's needed, while new syntax is hardly needed.  Few, if anybody, 
are saying that PHP's syntax is preventing them from doing what they need to 
do.  The argument is always that the new syntax can be useful here or helpful 
there - which even if we accept as true, would make the rating of these 
features as 'nice to have', and not 'important' let alone 'must'.  Not having 
them is not a barrier to adoption, nor is it pushing anybody away from PHP.  
Plus, there's this whole theory that less is more, and in its more relevant 
form - more is less.  So arguably, the added complexity may even hamper 
adoption.

It's of course a lot easier to implement a patch to the engine to add some new 
syntax, but that's not what the language needs.  There's no need to add new 
stuff to PHP every year especially not at the language level, and we seem to be 
obsessed with that.  If people focused their efforts on things that can truly 
move the needle, even if it took a lot longer, it would eventually pay off.  
Instead, we're not even investing in them - because we're in a 'vicious' yearly 
cycle of adding new syntax.
 
> Furthermore, type system enhancements can have enormous impact.
> Consider if generics landed in PHP 7.1. You had better believe that would
> bring us to the "next level".

I fail to see how adding C++ templates to PHP takes it to the next level in 
anything but the complexity scale.  Not having them is not preventing anybody 
from doing anything today.  Sure, a bunch of frameworks would adopt them once 
they become available - but it will not enable them to do things that are 
radically different from what they're doing today.

> Please do not reduce type system enhancements to mere syntax.

For the most part, it is - as most sensible use cases have alternative 
solutions - either by different methods or by writing tiny bits of userland 
code.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Levi Morrison]

> IMHO, it would be AWESOME if we could funnel some of these cycles from new 
> syntax and onto other things like parallel processing, async IO, JIT and more 
> - which can truly take PHP to the next level.  New syntax cannot.

The time investment for those projects is enormous. Not many
developers have the time or capability to add these things.

Furthermore, type system enhancements can have enormous impact.
Consider if generics landed in PHP 7.1. You had better believe that
would bring us to the "next level".

I agree that some of those things you mention would be great things.
Please do not reduce type system enhancements to mere syntax.

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

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Tuesday, April 19, 2016 11:07 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> strawman?  A number of people are using it, and it's a flippant and insulting
> ad hominem attack; from everyone using it.

While I agree that it can be insulting I do think that there's a certain degree 
of this happening (not necessarily in this thread or in any recent thread;  I'm 
talking completely in general).  It may not be productive to bring it up 
(because as you say, it can be insulting) - but given that I think that 
internals isn't free from it, I would hope that people will be encouraged to 
think hard on whether what they're proposing is truly needed, as opposed to 
just being useful.

>It's the same thing as "PHP is not
> $other_language, therefore nothing from that language is useful for PHP."

Larry, I don't believe that anybody has ever said anything of the sort on 
internals, ever (although I've been known to readily admit I'm senile).  We 
never block a feature from PHP because it comes from a given language.  
However, when considering a new feature for PHP - a procedural, OO 
loosely-typed language, and not a functional or strongly typed one - bringing 
in features that make it more functional or more strongly typed, cannot be on 
the grounds that they exist in other languages.  Of course they exist in other 
languages - there are many different types of languages, PHP cannot and should 
not try be all of them.

>  PHP's history has
> very clearly been one of borrowing and stealing ideas from every language we
> can find if they fit and make sense in PHP (and not if they don't).

I think that it's much more correct to say that PHP's history has been clearly 
one of borrowing and stealing ideas from C, Java and Perl, and not every 
language we can find.  C, Java and Perl have some very strong commonalities, 
which is why creating a language that merged good stuff from all of them - plus 
adding more of our own - made sense and created a generally successful mix.  
But we never ever wanted, nor do we want right now, to borrow ideas from all of 
the languages in existence, even if they're good ideas.  Good ideas exist in 
other languages, that don't fit PHP language characteristics.

Which again, does not mean that a feature that comes from a functional/academic 
language is inherently disqualified, and I do maintain to nobody is saying it;  
But when we come to evaluate whether it "fits and makes sense in PHP", than 
naturally, the likelihood that it does is inherently lower.
 
> Referencing other languages to support the inclusion of a feature is not a
> coolness argument.  It's a "solved problem, prior art exists"
> argument.

But it's a weak, almost trivial argument.  It's still one that is relevant - 
but given that it's weak, people should not expect that by saying that "XYZ 
language has it", this constitutes a strong argument in its favor.  If that XYZ 
language is from a very different language family, then as I mentioned above, 
it may be an indicator that it's not a very good fit for PHP.  Again - not 
inherently disqualified - just 'raising questions'.

>If a need is identified within PHP for a given feature, it is both
> logical and expected to look for prior solutions to the same or similar
> problems.  That's the whole point of OSS.  That doesn't make the solution
> used by another language necessarily the right one, but it should be
> considered a viable candidate.

The problem is, IMHO, that we're very, VERY flexible with the definition of the 
word 'need'.
There used to be a rule of thumb on internals that finding some use cases for a 
given language-level feature hardly constituted grounds to add it.  It had to 
be useful on a very wide range of situations, in order to be worth the trouble 
of implementing it, maintaining it, but most of all - of adding complexity 
layers to the language (both in terms of cognitive burden and likelihood of 
misuse).  Now, the whole 'complexity' factor is almost ignored.  Focus is on 
finding a use case or a handful of use cases where the feature can be useful - 
a task which is almost always doable - especially when borrowing features from 
other languages.
 
> Remember:
> 
> 'Programming languages teach you not to want what they don't provide.'
> --https://twitter.com/compscifact/status/375283793923670016

Is that inherently bad?  It could be if it truly limits you, but if a language 
has a certain way of doing things, and not another - is it bad that it'd funnel 
you to do things its way?
Is it that bad that something that wants to use functional syntax, will not 
embrace PHP but something else?  We don't have to be everything for everyone.

Regardless, at least as far as I can tell, it seems as if on inte

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> same thing as "PHP is not $other_language, therefore nothing from that
> language is useful for PHP."  Which is an utterly wrong and useless

No, it's not. Nobody claims *nothing* from other languages is useful in
PHP. What is claimed instead that *not everything* from other languages
is useful in PHP, and, for example, importing random high-order type
constructs from these languages without having extensive supporting
infrastructure that those languages have makes no sense. Or, for
example, importing arguments like "nulls are evil, let's replace nulls
with monadic types" into PHP make much less sense in PHP context then
they make in the context where they are made.

> Referencing other languages to support the inclusion of a feature is not
> a coolness argument.  It's a "solved problem, prior art exists"

The problem is that this prior art exists in different context,
targeting different audience and having different styles, traditions,
capabilities and support system, and it is taken wholesale without
accounting for that.

> argument.  If a need is identified within PHP for a given feature, it is

Maybe my feeling is wrong, but I do have a feeling that recently "need
is identified" turned into "I can, if I think really hard, think of a
complex artificial example where this feature would provide a marginal
improvement". I would like a much higher barrier for "need is
identified" that that. For me, some of the proposals look like solution
is search of a problem. Maybe it's just because I do not understand the
actual need enough. In that case I'd like to see it shown more prominently.

I mean, for adding a function or a parameter to function - fine, almost
any use case will do, the more the merrier. But for overhauling whole
language's type system - I don't think so.

> Similarly, actual computer science (as opposed to the software
> engineering most of us do) is developing real and meaningful new
> solutions to problem spaces, which take years, often decades, to
> percolate down into production languages.  That doesn't mean proposing a
> language feature informed by academia is just being hipster or elitist,
> it means learning from and benefiting from the work of others.  That's
> the whole point of OSS.

I do not object to being informed by academia, far from it. I object to
arguments "some folks from academia say X is a good thing, therefore we
must do X". Maybe X is a good thing for PHP, maybe it isn't - but
whichever way it is, it's not because somebody likes (or dislikes) it in
a completely unrelated context.

> its inclusion. I completely agree with that.  But rejecting a feature
> suggestion with "you're just trying to look cool" is unhelpful,
> unconstructive, and frankly harmful to the community and the language.

Nobody does that - that is not the *reason* for rejecting anything, it's
just a marginal side note. I just try to turn our attention to the fact
that not all cool features that exist in other languages can, or should
be, in PHP, even if they do look cool. And I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Maybe we gained more - I don't know yet, as most of our user base isn't
even on 5.5 by now. But it does worry me that we are not only losing it
- we seem to be actively trying to get rid of it.

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

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

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Fleshgrinder [mailto:p...@fleshgrinder.com]
> Sent: Tuesday, April 19, 2016 11:03 PM
> To: Zeev Suraski <z...@zend.com>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> On 4/19/2016 8:48 PM, Zeev Suraski wrote:
> >> but it does not help with primitive types. :(
> >
> > Which is fine.  Primitive types can and should get dedicated solutions.
> There's really no need for allowing over creativity with userland-customized
> scalar types.
> >
> 
> Hmmm... nope. I already brought various examples where I personally see the
> strength of union types and that is exactly with the primitives.[1]
> *int|string* is so powerful if you deal with MySQLi and its BIGINT stuff
> because I can fully type hint it now (like the /mysqli/ extension does in C) 
> and
> check very fast if I need to use GMP or not.

I can only repeat - primitive types can and should get dedicated solutions.  
There's really no need for allowing over creativity with userland-customized 
scalar types.  If we think that a certain scalar definition makes a lot of 
sense, we can add it at the language level.  There's no need to complicate the 
language, add syntax which makes no sense for objects and isn't really needed 
for scalars either.

> interface HouseCat {
> function drink();
> }
> 
> interface Dog {
> function eat();
> }
> 
>-interface Lion {
>+interface Lion extends HouseCat, Dog{
> function drink();
> function eat();
> }

Pardon me saying this but it doesn't appear as if you've read what I wrote.  
Please take a look at the 'diff' I made in the definition of your Lion class, 
because without it, your sample and mine have little to do with each other.

With that change in place, please reevaluate whether what you said is relevant:

> A lion drinks and eats but is neither a HouseCat nor a Dog. This is dangerous
> and introduces many potential hard to find bugs. Better don't touch it and go
> for duck typing or the introduction of a dedicated
> interface: *always*

Nothing further.

Zeev

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/19/16 1:43 PM, Stanislav Malyshev wrote:

Hi!


Creating a generic feature that makes sense in a handful of
situations, while at the same time being one that's
waiting-to-be-abused in the vast majority of the rest (or as Tom put
it, a 'footgun') is a pretty poor bargain IMHO.

Completely agree with Zeev here.

It also seems to me that some measure of support for these features
comes from the "coolness factor" - look, ma, we have complex types, just
like those cool academic languages everybody is excited about! And I
don't deny the importance of language having some coolness factor and
getting people excited, but in this case I think it's a bit misplaced -
in *PHP*, I believe, most of the use for this feature would be to hide
lazy design and take shortcuts that should not be taken, instead of
developing robust and powerful type system.

Now, PHP's origins are not exactly in "powerful type system" world, so
it's fine if some people feel not comfortable with this rigidity and
having to declare tons of interfaces, and so on. This is fine. But
inserting shortcuts in the system to make it "strict, but not strict"
seems wrong to me.


Can we please, please drop the "you only want it because it's cool" 
strawman?  A number of people are using it, and it's a flippant and 
insulting ad hominem attack; from everyone using it.  It's the same 
thing as "PHP is not $other_language, therefore nothing from that 
language is useful for PHP."  Which is an utterly wrong and useless 
argument to make.  PHP's history has very clearly been one of borrowing 
and stealing ideas from every language we can find if they fit and make 
sense in PHP (and not if they don't).


Referencing other languages to support the inclusion of a feature is not 
a coolness argument.  It's a "solved problem, prior art exists" 
argument.  If a need is identified within PHP for a given feature, it is 
both logical and expected to look for prior solutions to the same or 
similar problems.  That's the whole point of OSS.  That doesn't make the 
solution used by another language necessarily the right one, but it 
should be considered a viable candidate.


Similarly, actual computer science (as opposed to the software 
engineering most of us do) is developing real and meaningful new 
solutions to problem spaces, which take years, often decades, to 
percolate down into production languages.  That doesn't mean proposing a 
language feature informed by academia is just being hipster or elitist, 
it means learning from and benefiting from the work of others.  That's 
the whole point of OSS.


True, the onus is on the proposer of any new language feature to justify 
its inclusion. I completely agree with that.  But rejecting a feature 
suggestion with "you're just trying to look cool" is unhelpful, 
unconstructive, and frankly harmful to the community and the language.


Remember:

'Programming languages teach you not to want what they don't provide.'
--https://twitter.com/compscifact/status/375283793923670016

That means PHP-centric developers are inherently inclined to not think a 
a feature PHP has right now is useful.  It's an entirely natural and 
normal response to have.  That doesn't make it right, or helpful.


--
--Larry Garfield


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/19/2016 8:48 PM, Zeev Suraski wrote:
>> but it does not help with primitive types. :(
> 
> Which is fine.  Primitive types can and should get dedicated solutions.  
> There's really no need for allowing over creativity with userland-customized 
> scalar types.
> 

Hmmm... nope. I already brought various examples where I personally see
the strength of union types and that is exactly with the primitives.[1]
*int|string* is so powerful if you deal with MySQLi and its BIGINT stuff
because I can fully type hint it now (like the /mysqli/ extension does
in C) and check very fast if I need to use GMP or not.

I can only repeat. I am fully supporting to block union types if we
instead commit to the introduction of additional primitive types (as
outlined in the generics RFC)[2] and operator overloading in userland.

However, use cases remain and union/intersection types can help
especially if you do not want any kind of is-a relationship in your
classes. In other words, we do not want to introduce an additional
interface for something because we do not want the instance to pass
through other checks. Or, of course, the situation where it is simply
impossible for me to introduce the interface: built-in classes. I might
want to decorate them and pass through all checks but I cannot because,
well, how?

[1] http://marc.info/?l=php-internals=146080503103988=2
[2] https://wiki.php.net/rfc/generics#related_enhancements

> I believe you think I meant that instead of checking that $b's class actually 
> implements foo and bar, we'd check whether $b has all of the methods needed 
> by foo and bar - which means that theoretically means that it may have 
> methods foo() and bar() but not actually 'officially' implement their 
> respective interfaces.  But there's no reason to do it this way and that's 
> not what I meant.
> Instead, with my proposal, a $b object whose class implements both foo and 
> bar - will automatically be accepted as one that also implements baz.  The 
> checks will be conducted at the interface level, not the function list level. 
>  In other words, if $b doesn't explicitly implement baz, we'd take a look at 
> 'baz', see it's comprised of foo & bar, and check whether $b's class 
> implements them.
> 
> At this point, I can't imagine any negative side effect to automatically 
> deducing that an object that implements foo and bar also implements baz 
> (other than a small performance hit, probably roughly the same as the AND 
> union type).  Like I mentioned in my original post, I don't necessarily think 
> it's needed - I personally see no reason not to add 'baz' to the list of 
> interfaces impl implements, or as you said, replace foo and bar with baz 
> altogether.
> 

interface HouseCat {
function drink();
}

interface Dog {
function eat();
}

interface Lion {
function drink();
function eat();
}

A lion drinks and eats but is neither a HouseCat nor a Dog. This is
dangerous and introduces many potential hard to find bugs. Better don't
touch it and go for duck typing or the introduction of a dedicated
interface: *always*

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Fleshgrinder [mailto:p...@fleshgrinder.com]
> Sent: Tuesday, April 19, 2016 8:33 PM
> To: Zeev Suraski <z...@zend.com>; Larry Garfield 
> <la...@garfieldtech.com>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> On 4/19/2016 11:41 AM, Zeev Suraski wrote:
> > It could actually implement all of them - the two parents, and the child.
> That sounds like a pretty good, explicit way that requires no 
> introduction of any new syntax, concepts or engine complexity in order 
> to do what you're describing.  This works fine:
> >
> > interface foo { function foo(); }
> > interface bar { function bar(); }
> > interface baz extends foo,bar {}
> >
> > class impl implements foo, bar, baz {
> >   function foo(){}
> >   function bar(){}
> > }
> >
> > function sth(baz $b){}
> >
> 
> `class impl implements baz {}` is actually already enough here because 
> `baz` extends `foo` and `bar`.

Yes I know[1] - it was in the context of Larry's point.

> This is the only way to solve such situations right now

And it's a good one!

> but it does not help with primitive types. :(

Which is fine.  Primitive types can and should get dedicated solutions.  
There's really no need for allowing over creativity with userland-customized 
scalar types.

> > One thing we could consider is adding some intelligence for these 
> > cases, and
> for interfaces that only extend other interfaces (without adding new
> signatures) - a class would be considered to implement that interface 
> if it implements all of the 'parent' interfaces that the child interface 
> extends:
> >
> > class impl implements foo, bar {
> >   function foo(){}
> >   function bar(){}
> > }
> >
> > function sth(baz $b){}   <-- would work, as impl implements both foo and
> bar, and baz does nothing but extending those.
> >
> > I'm not sure that's necessary, and believe the current mechanisms 
> > and
> syntax satisfy these use cases already, but it's probably a possibility.
> >
> 
> That sounds like runtime checked duck typing.
> This actually makes the type
> system less strict and might have horrific side effects and that is 
> exactly the opposite of what union/intersection types are meant for:

Not at all.  I'm pretty sure you misunderstood what I meant.

> preventing this. Above code is the same as:
> 
> function sth($b) {
> $b->foo();
> $b->bar();
> }
> [snip]

I believe you think I meant that instead of checking that $b's class actually 
implements foo and bar, we'd check whether $b has all of the methods needed by 
foo and bar - which means that theoretically means that it may have methods 
foo() and bar() but not actually 'officially' implement their respective 
interfaces.  But there's no reason to do it this way and that's not what I 
meant.
Instead, with my proposal, a $b object whose class implements both foo and bar 
- will automatically be accepted as one that also implements baz.  The checks 
will be conducted at the interface level, not the function list level.  In 
other words, if $b doesn't explicitly implement baz, we'd take a look at 'baz', 
see it's comprised of foo & bar, and check whether $b's class implements them.

At this point, I can't imagine any negative side effect to automatically 
deducing that an object that implements foo and bar also implements baz (other 
than a small performance hit, probably roughly the same as the AND union type). 
 Like I mentioned in my original post, I don't necessarily think it's needed - 
I personally see no reason not to add 'baz' to the list of interfaces impl 
implements, or as you said, replace foo and bar with baz altogether.  In other 
words, the way I see I, PHP already supports AND union types through interfaces 
as it is.

Thanks,

Zeev


[1] bit.ly/1NkDmOA

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> Creating a generic feature that makes sense in a handful of
> situations, while at the same time being one that's
> waiting-to-be-abused in the vast majority of the rest (or as Tom put
> it, a 'footgun') is a pretty poor bargain IMHO.

Completely agree with Zeev here.

It also seems to me that some measure of support for these features
comes from the "coolness factor" - look, ma, we have complex types, just
like those cool academic languages everybody is excited about! And I
don't deny the importance of language having some coolness factor and
getting people excited, but in this case I think it's a bit misplaced -
in *PHP*, I believe, most of the use for this feature would be to hide
lazy design and take shortcuts that should not be taken, instead of
developing robust and powerful type system.

Now, PHP's origins are not exactly in "powerful type system" world, so
it's fine if some people feel not comfortable with this rigidity and
having to declare tons of interfaces, and so on. This is fine. But
inserting shortcuts in the system to make it "strict, but not strict"
seems wrong to me.

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

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/19/2016 4:36 AM, Tom Worster wrote:
> On 4/18/16 4:34 AM, Tony Marston wrote:
> 
>> I repeat, where was the insult in the post in question?  What exactly
>> were the insulting words?
> 
> I chose just one example:
> 
>> Those who cannot write effective software without these "clever"
>> additions to the language are doing nothing but announcing to the
>> world that they are not clever enough to write effective software
>> using their own limited abilities.
> 
> I think it's hard to avoid construing an implication that people
> proposing and/or supporting changes to how PHP handles type in the
> current discussions here are incompetent programmers.
> 
> There's no doubt that this sentence posits a class of incompetent
> programmers who need crutches ('these "clever" additions') and a
> complementary class of competent programmer who don't. Saying so is
> pointless without some assignment (imaginary, implied or real) of
> individuals to the classes. It's hard to imagine that present company or
> the people whose interests we attempt to represent are not involved in
> the assignment. I find this a bit insulting.
> 
> Insult is something experienced as well as something performed. If
> enough people experience it then probably it was performed, regardless
> of intent. So to this extent I just disagree that...
> 
>> The fact that you don't like what I say does
>> not make it an insult.
> 
> "It's Not What You Say, It's What People Hear"
> 
> 
> But we are now completely off topic. To bring us back on topic I repeat
> my request that you try to be specific about what you want and why, with
> respect to the RFCs under discussion.
> 
> Tom
> 
> 

Very well said! :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/19/2016 11:41 AM, Zeev Suraski wrote:
> It could actually implement all of them - the two parents, and the child.  
> That sounds like a pretty good, explicit way that requires no introduction of 
> any new syntax, concepts or engine complexity in order to do what you're 
> describing.  This works fine:
> 
> interface foo { function foo(); }
> interface bar { function bar(); }
> interface baz extends foo,bar {}
> 
> class impl implements foo, bar, baz {
>   function foo(){}
>   function bar(){}
> }
> 
> function sth(baz $b){}
> 

`class impl implements baz {}` is actually already enough here because
`baz` extends `foo` and `bar`. This is the only way to solve such
situations right now but it does not help with primitive types. :(

> One thing we could consider is adding some intelligence for these cases, and 
> for interfaces that only extend other interfaces (without adding new 
> signatures) - a class would be considered to implement that interface if it 
> implements all of the 'parent' interfaces that the child interface extends: 
> 
> class impl implements foo, bar {
>   function foo(){}
>   function bar(){}
> }
> 
> function sth(baz $b){}   <-- would work, as impl implements both foo and bar, 
> and baz does nothing but extending those.
> 
> I'm not sure that's necessary, and believe the current mechanisms and syntax 
> satisfy these use cases already, but it's probably a possibility.
> 

That sounds like runtime checked duck typing. This actually makes the
type system less strict and might have horrific side effects and that is
exactly the opposite of what union/intersection types are meant for:
preventing this. Above code is the same as:

function sth($b) {
$b->foo();
$b->bar();
}

It will definitely fail if something else is passed in but if it is
`foo`, `bar`, or `baz` everything is fine. The problem is that any
object that satisfies the implementation of the methods `foo` and `bar`
would ultimately fulfill the contract here.

function sth(foo $b) {}

This is a different situation because now we know that it is something
that actually implements exactly those two interfaces. Including
possible additional constraints like argument and return type hints.
There might even be a documentation shipped together with them that the
implementer should take care of honoring. The intersection type hint is
much stricter in such cases.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Friday, April 15, 2016 9:13 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> On 4/15/16 12:28 PM, Christoph Becker wrote:
> > On 15.04.2016 at 17:42, Larry Garfield wrote:
> >
> >> I think there's 2 general use cases for union types that would be
> >> "good things", which are different for & and |, and have very little...
> >> intersection.  (*yaaa!*)
> >>
> >> The OR case is for cases where the language doesn't support a unified
> >> case at all.  The most obvious example here is array|Traversable.  If
> >> I want "a thing I can foreach()", then PHP right now has no way of
> >> saying that syntactically.  You have to type on array, or
> >> Traversable, or not type at all.  array|Traversable is what you
> >> really want,
> > It is not what I would want, though.
> >
> >> because those
> >> DO have an overlap (foreach-ablility), PHP is just incapable of
> >> representing that otherwise.
> > Maybe we should consider to accept an array as Traversable?  Actually,
> > I wonder why that's not already the case.
> 
> It's been asked a few dozen times, but never went anywhere.  Mainly, I think,
> Traversable implies object, which implies certain passing semantics.  Array is
> a primitive, so has different passing semantics.
> There's probably other subtle issues like that which have kept the engine-
> gurus from trying to make it work.
> 
> My assumption here is "if it were that easy someone would have done it
> already".  (Which may not be an entirely accurate assumption, but seems
> logical given how often it's been asked for.)
> 
> >> A similar example would be callable|SomeInterface.  An interface can
> >> specify a signature for __invoke(), which gives you documentation on
> >> the format that is expected for a callable.  However, you can't
> >> strictly enforce that because then you don't allow for a function or
> >> closure that fits the same method signature.  That means you have to
> >> leave it untyped.  This, I argue, would be better *and* reasonably type 
> >> safe:
> >>
> >> interface MiddlewareInterface {
> >>function __invoke(RequestInterface $req, ResponseInterface $res);
> >> }
> >>
> >> function middleware_builder(callable|MiddlewareInterface $m) {
> >>// ...
> >> }
> >>
> >> As that self-documents that MiddlewareInterface is the callable
> >> signature we need, but still allows an arbitrary callable to be passed.
> >> It's not perfect (I could pass a string of a function name that
> >> doesn't have that interface and it would still explode), but it is an
> >> improvement over middleware_builder() having no type specification at
> >> all, as is the case today.
> > In my opinion, `callable' is to weak a type hint to be really useful,
> > and it would be better if we would improve that (generics come to mind).
> >   Then you wouldn't need MiddlewareInterface at all and be not afraid
> > that somebody passes in an incompatible function.
> 
> One of the key language design points I think we should be keeping in mind is
> that, on the whole, single-purpose features are inferior to more general
> capabilities that implicitly grant the same capability.

It's a good rule-of-thumb, but I don't think it makes a lot of sense here.

Compared to the handful (or less) of situations where two different types of 
objects in fact have similar signatures, and like Christoph suggested - 
arguably, one should be considered a part of the other - in the vast majority 
of cases, lumping together two or more class types makes no sense.  
Unfortunately, I'm much less optimistic than you are about it 
not-being-used-because-it-makes-no-sense.

For uncommon but existent cases like the Symfony Request scenario you 
described, it's entirely reasonable to conduct the type check in userland code.

Creating a generic feature that makes sense in a handful of situations, while 
at the same time being one that's waiting-to-be-abused in the vast majority of 
the rest (or as Tom put it, a 'footgun') is a pretty poor bargain IMHO.

> On the flipside, the & is mostly useful for where you need multiple interfaces
> for something.  For instance, there's the PSR-7 ResponseInterface.  Drupal
> also has a number of interfaces for value objects to indicate their 
> cacheability
> metadata, such as CacheableMetadataInterface.  But that applies to more
> than just Responses, of course, so having it exte

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

On 4/18/16 4:34 AM, Tony Marston wrote:



I repeat, where was the insult in the post in question?  What exactly
were the insulting words?


I chose just one example:

> Those who cannot write effective software without these "clever"
> additions to the language are doing nothing but announcing to the
> world that they are not clever enough to write effective software
> using their own limited abilities.

I think it's hard to avoid construing an implication that people proposing 
and/or supporting changes to how PHP handles type in the current 
discussions here are incompetent programmers.


I did not use the word "incompetent" anywhere in that sentence.

There's no doubt that this sentence posits a class of incompetent 
programmers who need crutches ('these "clever" additions') and a 
complementary class of competent programmer who don't.


I simply pointed out that there is a class of programmer who has been able 
to write successful software using PHP's original dynamic typing approach. 
There is another class of programmer who want to make PHP operate more like 
other languages and introduce strict typing, and these people insist that 
they cannot write successful software WITHOUT these "clever" additions. Some 
programmers follow the KISS principle and write simple code to to complex 
things, while others write complex code to do simple things.


I'm sorry, but those who don't like the way that PHP works should stop 
complaining about it, stop using it, and switch to a language which is more 
suited to their programming style.


Saying so is pointless without some assignment (imaginary, implied or 
real) of individuals to the classes. It's hard to imagine that present 
company or the people whose interests we attempt to represent are not 
involved in the assignment. I find this a bit insulting.


Insult is something experienced as well as something performed. If enough 
people experience it then probably it was performed, regardless of intent. 
So to this extent I just disagree that...


> The fact that you don't like what I say does
> not make it an insult.

"It's Not What You Say, It's What People Hear"


Cobblers. The fact that some over-sensitive souls hear things that weren't 
actually written is their problem, not mine. Nowhere it that sentence did I 
use the word "incompetent", so to say that I did is a downright lie. Unless 
you can point to a word which is described as an insult in the dictionary 
you cannot reasonably complain that your perceived it as an insult. That 
just shows that your perception is faulty.


But we are now completely off topic. To bring us back on topic I repeat my 
request that you try to be specific about what you want and why, with 
respect to the RFCs under discussion.


I don't want the language overloaded with features that I have no intention 
of using just because other languages have them. I don't want the language 
overloaded with useless features which cause the language to run slower, 
introduce bugs, and which make it difficult to add other features which 
could actually be useful to the millions of userland developers out there.


--
Tony Marston


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tom Worster]

On 4/18/16 4:34 AM, Tony Marston wrote:


I repeat, where was the insult in the post in question?  What exactly
were the insulting words?


I chose just one example:

> Those who cannot write effective software without these "clever"
> additions to the language are doing nothing but announcing to the
> world that they are not clever enough to write effective software
> using their own limited abilities.

I think it's hard to avoid construing an implication that people 
proposing and/or supporting changes to how PHP handles type in the 
current discussions here are incompetent programmers.


There's no doubt that this sentence posits a class of incompetent 
programmers who need crutches ('these "clever" additions') and a 
complementary class of competent programmer who don't. Saying so is 
pointless without some assignment (imaginary, implied or real) of 
individuals to the classes. It's hard to imagine that present company or 
the people whose interests we attempt to represent are not involved in 
the assignment. I find this a bit insulting.


Insult is something experienced as well as something performed. If 
enough people experience it then probably it was performed, regardless 
of intent. So to this extent I just disagree that...


> The fact that you don't like what I say does
> not make it an insult.

"It's Not What You Say, It's What People Hear"


But we are now completely off topic. To bring us back on topic I repeat 
my request that you try to be specific about what you want and why, with 
respect to the RFCs under discussion.


Tom


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

wrote in message news:57135893.3070...@fleshgrinder.com...


On 4/17/2016 11:19 AM, Tony Marston wrote:

Where is the insult in what I wrote?



You are not only insulting people in this thread, you do it in every
thread you contribute to. You were exhorted multiple times for doing so.
Pretending otherwise does not change these facts so *please* get a grip.



I repeat, where was the insult in the post in question?  What exactly were 
the insulting words? The fact that you don't like what I say does not make 
it an insult.


--
Tony Marston


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/17/2016 5:58 PM, Lester Caine wrote:
> And this is where the likes of Hack should be exactly where you are
> working ... The vast majority of grass roots users don't need another
> layer of complexity loaded on top of what IS a perfectly functional
> platform. Adding types, complicating procedure calls and lumbering
> everything with 'optional' layers of complexity is not something that a
> small jobbing shop user has time to investigate the implications on his
> client base. I'm still working through code that other have written and
> trying to in many cases unravel exotic code that no longer fits the
> modern programming style. I no longer take on any new clients as there
> is enough work keeping my existing client base working, but there are a
> LOT of people still using PHP5.2/3 who now need help if they are ever to
> be brought forward.
> 
> Now if you were proposing something that actually validated the data
> fully rather than some very restricted 'type' elements then it might be
> worth the effort, but 'int' is only a very small part of validating a
> number and we still need the rest of the validation library after you
> install a replacement for that bit mf it ...
> 

Union and intersection types already get us closer to stricter data
types that are flexible too. Of course they are not the best solution. I
already mentioned in another mail that operator overloading is the only
way to get us there. It is the only thing that allows us to create truly
meaningful types.

However, the problem of primitives remains, as was illustrated in this
and related threads multiple types, e.g. `array|Traversable`.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 17/04/16 14:28, Fleshgrinder wrote:
> Most features that are currently discussed are aiming at enterprise
> applications that require more built-in functionality to ensure
> correctness, reduce the amount of tests (unit as well as runtime) to
> detect bugs, and where many developers work together at the same code
> base. Most features can increase agility and productiveness of such
> teams and allow them to implement new features and A/B tests faster. Of
> course many features require more knowledge about programming. This can
> also be bad for such teams because big teams almost always suffer from a
> huge knowledge gap. Despite that, it helps the more advance developers
> to create richer APIs that are harder to abuse and in turn allow the
> overall design to achieve previously mentioned goals.

And this is where the likes of Hack should be exactly where you are
working ... The vast majority of grass roots users don't need another
layer of complexity loaded on top of what IS a perfectly functional
platform. Adding types, complicating procedure calls and lumbering
everything with 'optional' layers of complexity is not something that a
small jobbing shop user has time to investigate the implications on his
client base. I'm still working through code that other have written and
trying to in many cases unravel exotic code that no longer fits the
modern programming style. I no longer take on any new clients as there
is enough work keeping my existing client base working, but there are a
LOT of people still using PHP5.2/3 who now need help if they are ever to
be brought forward.

Now if you were proposing something that actually validated the data
fully rather than some very restricted 'type' elements then it might be
worth the effort, but 'int' is only a very small part of validating a
number and we still need the rest of the validation library after you
install a replacement for that bit mf it ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/17/2016 2:57 PM, Lester Caine wrote:
> On 17/04/16 13:35, Fleshgrinder wrote:
>> If you are only afraid that usage of your libraries declines because
>> users demand these new features to be part of it and you do not want to
>> implement them. Sorry, but that would be a clear sign that the features
>> are good and should be used.
> 
> I have two major libraries I have used since day one of PHP5 ... ADOdb
> and Smarty ... both of these have provided the core of my framework, but
> have needed a lot of work simply keeping my code in sync with them, and
> the latest 'improvements' to both are not BC for reasons that are blamed
> on needing to 'modernise' the code. Now I DID keep my own copies of both
> for many years to keep the PHp5.2 code working, and perhaps I should
> simply close the door on PHP7 and stay with what is currently working.
> But PHP7 ... ignoring any of the new features ... does provide
> improvements in some areas if you REMOVE the legacy stuff which prevents
> the optimisations from giving their best. The 'improvements' to ADOdb
> and Smarty are claimed to help this process but unfortunately the people
> pushing those changes are 'new school' and expect all the new stuff as
> well. So exactly where is PHP heading? Do we keep with the original
> simple flexible language that even today still works fine, or do we
> accept that everything that is being demanded should also be included
> and just roll over.
> 
> I do not accept the statement that 'You do not have to use it'! That may
> have been true in the past, but today one has to live with the fact that
> legacy code and modern hosting simply do not co-exist. One HAS to take
> care that the key third party bits still work, and it's libraries like
> the mapping extensions which relied on many key elements that HAVE now
> been removed from PHP.
> 

The situation you describe is a pain that I know myself and I agree.
There are too many libraries that try to solve things in the most
possible generic way and abuse OO to ridiculous excesses instead of just
solving a single, simple problem with a few functions (as our old but
gold Unix philosophy has taught us). The simple rule "If it ain't broke
don't fix it" is also violated too much.

The reasons for this are manifold and hard to grasp from time to time. I
guess most often the problem boils down to "my library is not cool if it
does not use the latest language features". Ignoring completely if those
language features are actually appropriate for the problem. E.g.
excessive usage of exceptions without a single assertion spread all over
a code base to validate developer input.

However, you should seek the discussion with the maintainers of these
libraries and have a serious talk about BC, stability, and appropriate
usage of language constructs to solve problems. Instead of trying to
block advancement and evolution within the language itself.

Most features that are currently discussed are aiming at enterprise
applications that require more built-in functionality to ensure
correctness, reduce the amount of tests (unit as well as runtime) to
detect bugs, and where many developers work together at the same code
base. Most features can increase agility and productiveness of such
teams and allow them to implement new features and A/B tests faster. Of
course many features require more knowledge about programming. This can
also be bad for such teams because big teams almost always suffer from a
huge knowledge gap. Despite that, it helps the more advance developers
to create richer APIs that are harder to abuse and in turn allow the
overall design to achieve previously mentioned goals.

This is the sole reason why new language like Rust and Ceylon were
invented in the last years. Of course there are also projects that aim
at the novice user, e.g. Golang[1]. PHP currently achieves both in the
context of web projects and support for enterprise was grew and grew and
big companies like Facebook or my employee trivago who decided to go for
PHP do not want to invest a shitload of money into rewriting everything
from scratch in another language[2] like Twitter did (and exchange all
their developers who were already extremely hard to find in the first
place with new ones) just to get enterprise features. No, they want to
see advances in PHP to support exactly those features.

Facebook did not see those advancements and sent out their OCaml/C++
team to create something that has exactly those enterprise features
while we at trivago plan to upgrade to PHP 7, while I am writing these
lines, to get more performance out of the language and strict type checks.

There are always pros and cons and it is hard to satisfy everyone but
the type system of PHP is definitely one of its main weak spots and it
must be improved to support enterprise requirements better.

[1]
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
[2] This applies to switching from PHP to HHVM/Hack as well.

-- 

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 17/04/16 13:35, Fleshgrinder wrote:
> If you are only afraid that usage of your libraries declines because
> users demand these new features to be part of it and you do not want to
> implement them. Sorry, but that would be a clear sign that the features
> are good and should be used.

I have two major libraries I have used since day one of PHP5 ... ADOdb
and Smarty ... both of these have provided the core of my framework, but
have needed a lot of work simply keeping my code in sync with them, and
the latest 'improvements' to both are not BC for reasons that are blamed
on needing to 'modernise' the code. Now I DID keep my own copies of both
for many years to keep the PHp5.2 code working, and perhaps I should
simply close the door on PHP7 and stay with what is currently working.
But PHP7 ... ignoring any of the new features ... does provide
improvements in some areas if you REMOVE the legacy stuff which prevents
the optimisations from giving their best. The 'improvements' to ADOdb
and Smarty are claimed to help this process but unfortunately the people
pushing those changes are 'new school' and expect all the new stuff as
well. So exactly where is PHP heading? Do we keep with the original
simple flexible language that even today still works fine, or do we
accept that everything that is being demanded should also be included
and just roll over.

I do not accept the statement that 'You do not have to use it'! That may
have been true in the past, but today one has to live with the fact that
legacy code and modern hosting simply do not co-exist. One HAS to take
care that the key third party bits still work, and it's libraries like
the mapping extensions which relied on many key elements that HAVE now
been removed from PHP.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/17/2016 2:19 PM, Lester Caine wrote:
> On 17/04/16 11:29, Fleshgrinder wrote:
>> Especially since its not needed at all. HHVM already solved most of
>> these issues extremely nicely:
>>
>> - https://docs.hhvm.com/hack/types/type-system
>> - https://docs.hhvm.com/hack/type-aliases/introduction
>> - https://docs.hhvm.com/hack/shapes/introduction
>>
>> We want the same but do not want to copy?!?
> 
> The simple answer NO
> 
> If that is how you think it should be done, then use it. On my platform,
> 'point' is a number of floating point numbers depending on your
> geometry. And shapes use those points. So that area of 'hack' is of
> little use to any mapping system, and trying to shoehorn existing code
> to fit is 'pointless' ...
> 
> It's the fact that many of these problems HAVE been solved without
> resorting to overloading PHP with a subset that does not provide a
> complete solution to the alleged problems that is the reall problem
> here. Having to re-write libraries because some one else thinks the
> basic rules are wrong and need fixing :(
> 

Why do you need to rewrite anything?
Why do you need to use it?

Especially, why do you thing that PHP was made solely for auto-mappers
from some SQL to PHP?

$array_point = array('x' => 0.0, 'y' => 0.0); // valid

type Point = shape('x' => float, 'y' => float);
$point = shape('x' => 0.0, 'y' => 0.0); // valid

function distance(array|Point $p1, array|Point $p2) {
// works
}

function distance(Point $p1, Point $p2) {
// works better
}

var_dump($point);

// array(2) {
//   ["x"]=>
//   float(0.0)
//   ["y"]=>
//   float(0.0)
// }

Both works and both is valid. Only the latter case ensures that it is as
defined and the former allows arbitrary changes. If you need arbitrary
changes go for it. It does not matter why you want to use the former
(anemic domain, legacy support, no time to adopt, no muse to adopt,
"everything was better in the old days", ...) as long as it solves your
use case and satisfies your users. All changes that were proposed are
*without any BC!*

If you are only afraid that usage of your libraries declines because
users demand these new features to be part of it and you do not want to
implement them. Sorry, but that would be a clear sign that the features
are good and should be used.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

RE: [PHP-DEV] Re: Improving PHP's type system

[Thomas Punt]

Hi!

>> Just a quick thought.
>>
>>
>> union Iterable {
>> use array;
>> use ArrayAccess;
>> use Traversable;
>> }
>>
>
> I think this example creates another meaning on the "use" syntax, which
> make "use" context depended.
>
> The "use" statement is already used to "create an class name alias in the
> current namespace." and this makes "use" confusing.

I don't think this additional usage of "use" makes it any more confusing.
Many keywords are reused elsewhere, including "use":
 - namespace importing
 - variable importing for closures
 - trait importing

(Ditto with "as.")

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 17/04/16 11:29, Fleshgrinder wrote:
> Especially since its not needed at all. HHVM already solved most of
> these issues extremely nicely:
> 
> - https://docs.hhvm.com/hack/types/type-system
> - https://docs.hhvm.com/hack/type-aliases/introduction
> - https://docs.hhvm.com/hack/shapes/introduction
> 
> We want the same but do not want to copy?!?

The simple answer NO

If that is how you think it should be done, then use it. On my platform,
'point' is a number of floating point numbers depending on your
geometry. And shapes use those points. So that area of 'hack' is of
little use to any mapping system, and trying to shoehorn existing code
to fit is 'pointless' ...

It's the fact that many of these problems HAVE been solved without
resorting to overloading PHP with a subset that does not provide a
complete solution to the alleged problems that is the reall problem
here. Having to re-write libraries because some one else thinks the
basic rules are wrong and need fixing :(

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/17/2016 12:22 PM, Lin Yo-An wrote:
> On Sun, Apr 17, 2016 at 6:06 AM, Bastian Schneider <
> bastian.schnei...@commerce-plus.com> wrote:
> 
>> Just a quick thought.
>>
>>
>> union Iterable {
>> use array;
>> use ArrayAccess;
>> use Traversable;
>> }
>>
> 
> I think this example creates another meaning on the "use" syntax, which
> make "use" context depended.
> 
> The "use" statement is already used to "create an class name alias in the
> current namespace." and this makes "use" confusing.
> 

Especially since its not needed at all. HHVM already solved most of
these issues extremely nicely:

- https://docs.hhvm.com/hack/types/type-system
- https://docs.hhvm.com/hack/type-aliases/introduction
- https://docs.hhvm.com/hack/shapes/introduction

We want the same but do not want to copy?!?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Sun, Apr 17, 2016 at 6:06 AM, Bastian Schneider <
bastian.schnei...@commerce-plus.com> wrote:

> Just a quick thought.
>
>
> union Iterable {
> use array;
> use ArrayAccess;
> use Traversable;
> }
>

I think this example creates another meaning on the "use" syntax, which
make "use" context depended.

The "use" statement is already used to "create an class name alias in the
current namespace." and this makes "use" confusing.



Thanks, Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/17/2016 11:19 AM, Tony Marston wrote:
> Where is the insult in what I wrote?
> 

You are not only insulting people in this thread, you do it in every
thread you contribute to. You were exhorted multiple times for doing so.
Pretending otherwise does not change these facts so *please* get a grip.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

"Tom Worster"  wrote in message news:571267b4.9070...@thefsb.org...


On 4/16/16 5:04 AM, Tony Marston wrote:

"Marco Pivetta"  wrote in message
news:CADyq6sJfPYgQvhQt=uvcbqkoojjoupcz1sufzwxc+55hl0p...@mail.gmail.com...


Tony, that sounds really like "real programmers use `dd -if -of`". 
Please

stop with that argument, as it really doesn't reflect reality.


That is not what I said. As a follower of the KISS principle I believe
that good programmers write simple code that anyone can understand, while 
less-than-good programmers write complex code that only a select

few can understand.


...or perhaps nobody can understand. Agreed. So I guess that makes me
a follower of the KISS principle too. I prefer boring, obvious, 
conventional code and the kind of strict style guides that artisan codes 
hate. I'm also conservative wrt changing PHP -- a gradualist. And I dislike 
arguments proposing feature X because such-and-such more fashionable 
language has it.


That said...

I have found that my programs, my team's and the libs I use are more 
obvious, boring and easy to understand when they are clear about type.


So in recent years I've tried to be more and more rigorous in using PHPdoc2 
type tags, the IDE's linters to run static checks, and working towards 
eliminating using "mixed" and "|" in the type spec.


PHP 7.0's type is better than relying on conventional annotations that 
evolved from a doc generator. I like these specific "shiny new features".


I believe that being stricter with type has helped reduce the rate at which 
we introduce bugs. It's been totally worth it. As I see it, I can't afford 
not to.


So I don't like Union Type because it will encourage sloppy type in libs 
that I might otherwise want to use. I don't want nullable hints for the 
same reason. With some reluctance and acknowledging the inconsistency I 
*do* advocate nullable return because eliminating something or null from 
PHP conventions seems a stretch and I'd rather these were declared than 
not. That's just my position.


I don't think I'm behaving like an academic researcher or computer 
scientist with a PhD. I prefer to see myself as a practical computer 
programmer with a deep concern for long term maintenance of my programs.



> The problem with adding all these new and shiny features ...
> only for the benefit of the few who think programming should be
> restricted to those who have Phd's.

I see two problems with arguing along these lines. 1. It's not specific 
enough. 2. It's a bit insulting both to me and, I imagine, to academics.


Where is the insult in what I wrote?

So please try to be more specific about both what you want and why. At the 
moment you appear to be arguing against any change to PHP and justifying 
this with the argument that anyone who wants to change it is an incompetent 
programmer.


Where did I ever use the word "incompetent"?

You are reading what isn't there.

--
Tony Marston


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Davey Shafik]

On Sat, Apr 16, 2016 at 5:06 PM, Ryan Pallas  wrote:

> On Sat, Apr 16, 2016 at 4:10 AM, Bastian Schneider <
> bastian.schnei...@commerce-plus.com> wrote:
>
> >
> > Just a quick thought. I would prefer something like
> >
> > union Iterable {
> > use array;
> > use ArrayAccess;
> > use Traversable;
> > }
> >
> > function bla(Iterable $iterable) {
> > foreach($iterable as $element) {}
> > }
> >
> > Primitives like string, float, bool or int are not allowed in union. Only
> > classes, interfaces and array. I doesn't see any benefit in combining
> > string with int or int with float in one union.
> >
>
> Here's an example that shows combining scalar maybe useful:
>
> union Numeric {
> use int;
> use float;
> }
>
> Something I would very much like to use where types are allowed.


Could also be used for solving the issue of coercing:

union Numeric {
use int;
use float;
use string as float;
}

Thoughts?

- Davey

Re: [PHP-DEV] Re: Improving PHP's type system

[Ryan Pallas]

On Sat, Apr 16, 2016 at 4:10 AM, Bastian Schneider <
bastian.schnei...@commerce-plus.com> wrote:

>
> Just a quick thought. I would prefer something like
>
> union Iterable {
> use array;
> use ArrayAccess;
> use Traversable;
> }
>
> function bla(Iterable $iterable) {
> foreach($iterable as $element) {}
> }
>
> Primitives like string, float, bool or int are not allowed in union. Only
> classes, interfaces and array. I doesn't see any benefit in combining
> string with int or int with float in one union.
>

Here's an example that shows combining scalar maybe useful:

union Numeric {
use int;
use float;
}

Something I would very much like to use where types are allowed.


>
> Do I overlook or missed anything?
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Bastian Schneider]

Just a quick thought.

union Iterable {
use array;
use ArrayAccess;
use Traversable;
}

function bla(Iterable $iterable) {
foreach($iterable as $element) {}
}

Primitives like string, float, bool or int are not allowed in union. 
Only classes, interfaces and array. I doesn't see any benefit in 
combining string with int or int with float in one union.


Do I overlook or missed anything?

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tom Worster]

On 4/16/16 5:04 AM, Tony Marston wrote:

"Marco Pivetta"  wrote in message
news:CADyq6sJfPYgQvhQt=uvcbqkoojjoupcz1sufzwxc+55hl0p...@mail.gmail.com...


Tony, that sounds really like "real programmers use `dd -if -of`". Please
stop with that argument, as it really doesn't reflect reality.


That is not what I said. As a follower of the KISS principle I believe
that good programmers write simple code that anyone can understand,
while less-than-good programmers write complex code that only a select
few can understand.


...or perhaps nobody can understand. Agreed. So I guess that makes me
a follower of the KISS principle too. I prefer boring, obvious, 
conventional code and the kind of strict style guides that artisan codes 
hate. I'm also conservative wrt changing PHP -- a gradualist. And I 
dislike arguments proposing feature X because such-and-such more 
fashionable language has it.


That said...

I have found that my programs, my team's and the libs I use are more 
obvious, boring and easy to understand when they are clear about type.


So in recent years I've tried to be more and more rigorous in using 
PHPdoc2 type tags, the IDE's linters to run static checks, and working 
towards eliminating using "mixed" and "|" in the type spec.


PHP 7.0's type is better than relying on conventional annotations that 
evolved from a doc generator. I like these specific "shiny new features".


I believe that being stricter with type has helped reduce the rate at 
which we introduce bugs. It's been totally worth it. As I see it, I 
can't afford not to.


So I don't like Union Type because it will encourage sloppy type in libs 
that I might otherwise want to use. I don't want nullable hints for the 
same reason. With some reluctance and acknowledging the inconsistency I 
*do* advocate nullable return because eliminating something or null from 
PHP conventions seems a stretch and I'd rather these were declared than 
not. That's just my position.


I don't think I'm behaving like an academic researcher or computer 
scientist with a PhD. I prefer to see myself as a practical computer 
programmer with a deep concern for long term maintenance of my programs.



> The problem with adding all these new and shiny features ...
> only for the benefit of the few who think programming should be
> restricted to those who have Phd's.

I see two problems with arguing along these lines. 1. It's not specific 
enough. 2. It's a bit insulting both to me and, I imagine, to academics.


So please try to be more specific about both what you want and why. At 
the moment you appear to be arguing against any change to PHP and 
justifying this with the argument that anyone who wants to change it is 
an incompetent programmer.


Tom


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/14/2016 9:59 PM, Stanislav Malyshev wrote:
> Hi!
> 
>>> Reduce assertions*, enhance self-documentation, making code more robust,
>>> perform checks in the VM and not in userland, ...
> 
> You don't reduce assertions, you just make them more cryptic and change
> error message slightly.
> 

e.g.
https://secure.php.net/mysqli.affected-rows#refsect1-mysqli.affected-rows-returnvalues

>> Oh oh oh, I forgot the very important unions *int|string* and
>> *float|string* for overflows as one can encounter them from time to
>> time; even in native code.
> 
> Not sure what are you referring here to, but I suspect you are trying to
> reimplement weak typing in some partial inconsistent and strange way,
> while pretending it's strong typing.
> 

Nope, I want to strengthen from weak to almost-strict for real use-cases
as outlined before. Of course there are other and better possibilities
but Larry Garfield already outlined it much better than I ever could why
they might not be as useful as union and intersection types. Also, I
never said that one does not require additional checks, however ...

function fn(Foo|Bar $arg) {
if ($arg instanceof Foo) {
$arg->foo();
}
else {
$arg->bar();
}
}

... is still much better than ...

function fn($arg) {
if ($arg instanceof Foo) {
$arg->foo();
}
elseif ($arg instanceof Bar) {
$arg->bar();
}
else {
// 
}
}

... and currently one can handle it only as ...

/**
 * @param Foo|Bar $arg
 */
function fn($arg) {
assert('$arg instanceof Foo || $arg instanceof Bar');
if ($arg instanceof Foo) {
$arg->foo();
}
else {
$arg->bar();
}
}

This is an explanatory example real world usage for me is mainly
handling and decorating of built-in PHP stuff.

function fn(string|Stringable $s) {
// Avoid having type casts everywhere and handle it where
// needed.
$s = (string) $s;
}

function fn(int|string $i) {
// Handle scalar and big integer
}

function fn(float|string $f) {
// Handle scalar and real number
}

function fn(array|Traversable $t) {
// foreach
}

public function getLastInsertId(): int|string {
return $this->mysqli->insert_id;
}

// No easy check for big int possible anymore. :(
public function getLastInsertId(): string {
return (string) $this->mysqli->insert_id;
}
// Note that this currently would be my preferred way of handling
// this case because one should not perform arithmetic operations
// on an ID. However, I sadly see it happening all the time...

// Would be awesome but operator overloading is not supported. :(
public function getLastInsertId(): NaturalNumber {
return new NaturalNumber($this->mysqli->insert_id);
}

// This works with integers but there is no equivalent for real
// numbers available. :(
//
// Extending of GMP in userland is not possible and hence adding
// restrictions to it (e.g. above NaturalNumber or a
// PositiveNaturalNumber) is not possible and again needs to be
// spread among the whole code base.
public function getLastInsertId(): GMP {
return gmp_init($this->mysqli->insert_id, 10);
}



public function findEntityById(int $id): ?Entity {
// Not acceptable because we have a BIGINT.
}



https://github.com/Fleshgrinder/php-assertion/blob/master/src/Variable.php#L492-L512

public function findEntityById(string $id): ?Entity {
assert('\Variable::isPositiveNaturalNumber($id)');
}

/** @throws EntityNotFound */
public function getEntityById(string $id): Entity {
assert('\Variable::isPositiveNaturalNumber($id)');
}



public function findEntityById(GMP $id): ?Entity {
assert('$id > 0');
}

/** @throws EntityNotFound */
public function getEntityById(GMP $id): Entity {
assert('$id > 0');
}



public function findEntityById(PositiveNaturalNumber $id): ?Entity {
// DRY + secure :)
}

/** @throws EntityNotFound */
public function getEntityById(PositiveNaturalNumber $id): Entity {
// DRY + secure :)
}

Ergo, I am not saying that union and intersection types are the solution
for all problems in this world. I am only saying that they have their
seldom special use cases. Please note, I am all in if we decide here to
not allow union and intersection and instead fix the type mixture in PHP
and add other features that allow us to create stricter types in
userland code. :)
-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

"Marco Pivetta"  wrote in message 
news:CADyq6sJfPYgQvhQt=uvcbqkoojjoupcz1sufzwxc+55hl0p...@mail.gmail.com...


Tony, that sounds really like "real programmers use `dd -if -of`". Please
stop with that argument, as it really doesn't reflect reality.


That is not what I said. As a follower of the KISS principle I believe that 
good programmers write simple code that anyone can understand, while 
less-than-good programmers write complex code that only a select few can 
understand.


The problem with adding all these new and shiny features to the language is 
that it makes the language more complicated, especially when it comes to all 
those edge cases which keep arising. Changes like this are making the 
language more complicated by getting it to do in core what used to be done 
in userland code. All that is happening is that it becomes more complicated 
to update the language for genuine improvements which would be appreciated 
by the masses instead of these over-complications which are only for the 
benefit of the few who think programming should be restricted to those who 
have Phd's.



I keep
enhancing my software with new (stricter) type checking, when available.
For example, I'm eager to replace current docblocks declaring `void`
methods with the upcoming hint (7.1), and every time I add hints and type
strictness I find new hidden bugs on an already well-tested code (with 100%
coverage and mutation testing). These bugs are legit, they are just waiting
to happen.


That just proves that your unit testing did not in fact have 100% coverage. 
If a potential bug hasn't been encountered by a real user then it doesn't 
actually cause a problem, and if it doesn't cause a problem then why does it 
need a solution? Even Microsoft, the largest software company in the world, 
does not attempt to fix every possible bug only those bugs which cause 
problems.



Additionally, I would also love to get rid of docblocks for type-systems:
they are unreliable, hard to reflect and enforce nothing, which allows lazy
and sloppy programmers to just circumvent specifications as it best pleases
their mood, rather than the requirements.

Yes, I'm a real programmer too, and no, I don't use cosmic rays to write
code to my computer's hard drive, give it a rest.
On Apr 15, 2016 08:09, "Tony Marston"  wrote:


"Levi Morrison"  wrote in message
news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com...



There are too many people out there who are trying to make the language

more complicated than it need be just to prove how clever they are.



I can assure you I am not proposing these RFCs to show how clever I am.



If millions of programmers have written millions of lines of code to 
write

effective programs WITHOUT the use of type hinting/enforcement, then how
come there are some people out there who keep saying that PHP is a bad
language because it does not have type checking? Those who cannot write
effective software without these "clever" additions to the language are
doing nothing but announcing to the world that they are not clever enough
to write effective software using their own limited abilities.

--
Tony Marston


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




--
Tony Marston


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

If we can pre-define the types via something like this:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


And only allow one type for each function parameter in the prototype, then,
I think the performance impact of type checking in the runtime can be
reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

For example,

   typedef T = array | Traversable

   function foo(T $a) {  }
   function bar(T $b) {  }

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

I pretty much like the Haskell type system, it let you define types via the
syntax below:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


But the type inference in Haskell can be resolved in the compile-time. We
can only verify the variable type for each function call in PHP.

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Sat, Apr 16, 2016 at 1:28 AM, Christoph Becker  wrote:

> On 15.04.2016 at 17:42, Larry Garfield wrote:
>
> Maybe we should consider to accept an array as Traversable?  Actually, I
> wonder why that's not already the case.
>

+1, I think so too.


-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/15/16 12:28 PM, Christoph Becker wrote:

On 15.04.2016 at 17:42, Larry Garfield wrote:


I think there's 2 general use cases for union types that would be "good
things", which are different for & and |, and have very little...
intersection.  (*yaaa!*)

The OR case is for cases where the language doesn't support a unified
case at all.  The most obvious example here is array|Traversable.  If I
want "a thing I can foreach()", then PHP right now has no way of saying
that syntactically.  You have to type on array, or Traversable, or not
type at all.  array|Traversable is what you really want,

It is not what I would want, though.


because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.

Maybe we should consider to accept an array as Traversable?  Actually, I
wonder why that's not already the case.


It's been asked a few dozen times, but never went anywhere.  Mainly, I 
think, Traversable implies object, which implies certain passing 
semantics.  Array is a primitive, so has different passing semantics. 
There's probably other subtle issues like that which have kept the 
engine-gurus from trying to make it work.


My assumption here is "if it were that easy someone would have done it 
already".  (Which may not be an entirely accurate assumption, but seems 
logical given how often it's been asked for.)



A similar example would be callable|SomeInterface.  An interface can
specify a signature for __invoke(), which gives you documentation on the
format that is expected for a callable.  However, you can't strictly
enforce that because then you don't allow for a function or closure that
fits the same method signature.  That means you have to leave it
untyped.  This, I argue, would be better *and* reasonably type safe:

interface MiddlewareInterface {
   function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
   // ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that doesn't
have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.

In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
  Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.


One of the key language design points I think we should be keeping in 
mind is that, on the whole, single-purpose features are inferior to more 
general capabilities that implicitly grant the same capability.  Thus, 
I'd argue that the Property Accessor RFC is superior to adding a half 
dozen keywords to object properties (because they implicitly grant all 
of those same capabilities with less mental overhead and fewer keywords) 
and Union Types are superior to special casing array|Traversable or 
array|ArrayAccess, etc.  (Making array a for-reals honest to goodness 
object would be good too, but that's a considerably larger issue.)  
Union Types side-step the need for more special cases, as they can be 
handled in user-space code.  It's not a perfect fix, but the perfect fix 
involves very BC-unfriendly changes to PHP (making everything an object, 
Go-style type aliases, etc.) that are not likely to happen any time soon.


Related: What would union types mean for the typed property RFC? Would 
this be a good solution or an evil solution:


class Foo {
  public array|Traversable $arr;
  public Foo $c;
}

--
--Larry Garfield


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Christoph Becker]

On 15.04.2016 at 17:42, Larry Garfield wrote:

> I think there's 2 general use cases for union types that would be "good
> things", which are different for & and |, and have very little...
> intersection.  (*yaaa!*)
> 
> The OR case is for cases where the language doesn't support a unified
> case at all.  The most obvious example here is array|Traversable.  If I
> want "a thing I can foreach()", then PHP right now has no way of saying
> that syntactically.  You have to type on array, or Traversable, or not
> type at all.  array|Traversable is what you really want,

It is not what I would want, though.

> because those
> DO have an overlap (foreach-ablility), PHP is just incapable of
> representing that otherwise.

Maybe we should consider to accept an array as Traversable?  Actually, I
wonder why that's not already the case.

> A similar example would be callable|SomeInterface.  An interface can
> specify a signature for __invoke(), which gives you documentation on the
> format that is expected for a callable.  However, you can't strictly
> enforce that because then you don't allow for a function or closure that
> fits the same method signature.  That means you have to leave it
> untyped.  This, I argue, would be better *and* reasonably type safe:
> 
> interface MiddlewareInterface {
>   function __invoke(RequestInterface $req, ResponseInterface $res);
> }
> 
> function middleware_builder(callable|MiddlewareInterface $m) {
>   // ...
> }
> 
> As that self-documents that MiddlewareInterface is the callable
> signature we need, but still allows an arbitrary callable to be passed. 
> It's not perfect (I could pass a string of a function name that doesn't
> have that interface and it would still explode), but it is an
> improvement over middleware_builder() having no type specification at
> all, as is the case today.

In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
 Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Christoph Becker]

On 14.04.2016 at 21:32, Jordi Boggiano wrote:

> I don't really think it's much more complex to grasp `Foo|Bar $foo` than
> only `Foo $foo`. I mean once you grasp the concept of type hints you
> probably have by then a good understanding of || and hopefully can
> derive understanding from there.
> 
> That said I agree it's rarely useful, and as such I am not expecting
> we'll see this all over the place, it's just nice to have when you need
> it, but I can't think of very many valid cases (nullable types are much
> more common).

There may not be very many cases for union types, but that might not
hinder some programmers to make extensive use of the feature, which
others may encounter in their APIs.

> Just to highlight one use case I can think of, here is one:
> 
> https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/MongoDBHandler.php#L51-L53
> 
> We need some sort of Mongo thing, and there are two available with
> different interfaces, so here both are accepted but as you see in the
> code below they are handled kinda separately. It would just save us
> those 3 lines of check if we could type-hint appropriately.

It occurs to me that this is an instance of parameter overloading:
accept one of two (or more) unrelated types and handle them separately
in a single function.  An alternative would be to have two (or more)
(factory) functions, each accepting one of the alternative types
(perhaps delegating to a common function for the common code, if necessary).

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tom Worster]

On 4/14/16 3:25 PM, Fleshgrinder wrote:

On 4/14/2016 8:59 PM, Stanislav Malyshev wrote:

>Hi!
>

>>I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>since it is super self-explanatory. However, I find myself checking the

>
>It may be self-explanatory for you. It's much less self-explanatory for
>somebody just starting to learn. It is also very dangerous - if it's
>either Foo or Bar, can you call Foo::stuff on it or not? If it's string
>or not string, can you call strlen on it? Etc., etc. It adds a lot of
>cognitive load and complicates the whole picture. You may have a
>specific use case where it is useful (which we have yet to see btw) but
>please remember it's a language with literally millions of use cases and
>users.
>

Reduce assertions*, enhance self-documentation, making code more robust,


I disagree here. I think our programs are more robust when programmers 
avoid passing mixed types and write more simple code instead.


Hence I agree with Stas about the danger part. Union type hints are a 
hazard. Adding them to PHP as a new feature is like saying "here's a 
great new tool, pick it up and use it" but the tool is really a footgun.


Tom


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/15/16 10:10 AM, Andrea Faulds wrote:

Hi Stas,

Stanislav Malyshev wrote:

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the


It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.


This is something that particularly concerns me about union types, in 
that they reduce type safety. If you have a union type of Foo|Bar for 
some variable, then the set of methods you can call on that variable 
is actually the intersection, not the union, of the set of methods you 
can call on Foo and Bar. Which, unless those two classes share some 
interface, is probably an empty set. So there's nothing you can 
actually do safely with it without doing checks within the body of the 
function, and if you're doing that, then why do we have a type 
declaration? It's only barely more useful than omitting a type 
declaration at all; type declarations are supposed to prevent you 
needing to check. On the other hand, if the two classes share some 
methods, then either there's an interface you can already use here, or 
you can create one. Either way, you don't need a union type.


There are some cases where you can't create an interface, but if 
that's the case, I think it is more worthwhile to look at how we can 
fix those cases, rather than add what amounts to a hacky workaround.


Thanks!


I think there's 2 general use cases for union types that would be "good 
things", which are different for & and |, and have very little... 
intersection.  (*yaaa!*)


The OR case is for cases where the language doesn't support a unified 
case at all.  The most obvious example here is array|Traversable.  If I 
want "a thing I can foreach()", then PHP right now has no way of saying 
that syntactically.  You have to type on array, or Traversable, or not 
type at all.  array|Traversable is what you really want, because those 
DO have an overlap (foreach-ablility), PHP is just incapable of 
representing that otherwise.


A similar example would be callable|SomeInterface.  An interface can 
specify a signature for __invoke(), which gives you documentation on the 
format that is expected for a callable.  However, you can't strictly 
enforce that because then you don't allow for a function or closure that 
fits the same method signature.  That means you have to leave it 
untyped.  This, I argue, would be better *and* reasonably type safe:


interface MiddlewareInterface {
  function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
  // ...
}

As that self-documents that MiddlewareInterface is the callable 
signature we need, but still allows an arbitrary callable to be passed.  
It's not perfect (I could pass a string of a function name that doesn't 
have that interface and it would still explode), but it is an 
improvement over middleware_builder() having no type specification at 
all, as is the case today.


(Hat tip to Matthew O'Phinney for cueing me into this neat feature of 
interfaces and __invoke().)


On the flipside, the & is mostly useful for where you need multiple 
interfaces for something.  For instance, there's the PSR-7 
ResponseInterface.  Drupal also has a number of interfaces for value 
objects to indicate their cacheability metadata, such as 
CacheableMetadataInterface.  But that applies to more than just 
Responses, of course, so having it extend ResponseInterface is not 
good.  So how can I specify that I need an object that is BOTH 
ResponseInterface AND CacheableMetdataInterface?  That's an entirely 
reasonable thing to do, but currently PHP doesn't allow for it at all.  
Even having a custom interface that extends both of those doesn't help, 
because then my class needs to implement the child interface, not both 
parents.


Being able to type on function foo(ResponseInterface & 
CacheableMetadatInterface $r) seems entirely reasonable to me, and 
definitely more type safe than leaving it untyped and relying on 
documentation.


The danger zone is, as many people have noted, OR-ing interfaces 
together.  That does undermine type safety in most cases, I'd argue.  
However, it's also rather obvious when it does so, because you end up 
with a giant if-statement inside your function.  So while it's a risk, I 
don't think it's a subtle one, especially if well documented.


Actually, there is a use case for ORing interfaces, and that's for BC 
reasons.  Take, for instance, Symfony 2's routing system.  It started 
off with 

Re: [PHP-DEV] Re: Improving PHP's type system

[Levi Morrison]

> This is something that particularly concerns me about union types, in that
> they reduce type safety.

This is incorrect. Anyone using a union type now simply uses PHP's
dynamic type system. Going from no enforced type to restricting it to
N types does not in any circumstance reduce type safety.

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the


It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.


This is something that particularly concerns me about union types, in 
that they reduce type safety. If you have a union type of Foo|Bar for 
some variable, then the set of methods you can call on that variable is 
actually the intersection, not the union, of the set of methods you can 
call on Foo and Bar. Which, unless those two classes share some 
interface, is probably an empty set. So there's nothing you can actually 
do safely with it without doing checks within the body of the function, 
and if you're doing that, then why do we have a type declaration? It's 
only barely more useful than omitting a type declaration at all; type 
declarations are supposed to prevent you needing to check. On the other 
hand, if the two classes share some methods, then either there's an 
interface you can already use here, or you can create one. Either way, 
you don't need a union type.


There are some cases where you can't create an interface, but if that's 
the case, I think it is more worthwhile to look at how we can fix those 
cases, rather than add what amounts to a hacky workaround.


Thanks!
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Marco Pivetta]

Tony, that sounds really like "real programmers use `dd -if -of`". Please
stop with that argument, as it really doesn't reflect reality. I keep
enhancing my software with new (stricter) type checking, when available.
For example, I'm eager to replace current docblocks declaring `void`
methods with the upcoming hint (7.1), and every time I add hints and type
strictness I find new hidden bugs on an already well-tested code (with 100%
coverage and mutation testing). These bugs are legit, they are just waiting
to happen.

Additionally, I would also love to get rid of docblocks for type-systems:
they are unreliable, hard to reflect and enforce nothing, which allows lazy
and sloppy programmers to just circumvent specifications as it best pleases
their mood, rather than the requirements.

Yes, I'm a real programmer too, and no, I don't use cosmic rays to write
code to my computer's hard drive, give it a rest.
On Apr 15, 2016 08:09, "Tony Marston"  wrote:

> "Levi Morrison"  wrote in message
> news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com...
>
>>
>> There are too many people out there who are trying to make the language
>>> more complicated than it need be just to prove how clever they are.
>>>
>>
>> I can assure you I am not proposing these RFCs to show how clever I am.
>>
>
> If millions of programmers have written millions of lines of code to write
> effective programs WITHOUT the use of type hinting/enforcement, then how
> come there are some people out there who keep saying that PHP is a bad
> language because it does not have type checking? Those who cannot write
> effective software without these "clever" additions to the language are
> doing nothing but announcing to the world that they are not clever enough
> to write effective software using their own limited abilities.
>
> --
> Tony Marston
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

"Levi Morrison"  wrote in message 
news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com...


There are too many people out there who are trying to make the language 
more complicated than it need be just to prove how clever they are.


I can assure you I am not proposing these RFCs to show how clever I am.


If millions of programmers have written millions of lines of code to write 
effective programs WITHOUT the use of type hinting/enforcement, then how 
come there are some people out there who keep saying that PHP is a bad 
language because it does not have type checking? Those who cannot write 
effective software without these "clever" additions to the language are 
doing nothing but announcing to the world that they are not clever enough to 
write effective software using their own limited abilities.


--
Tony Marston


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

RE: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> -Original Message-
> From: Tony Marston [mailto:tonymars...@hotmail.com]
> Sent: Thursday, April 14, 2016 12:01 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> 
> "Zeev Suraski"  wrote in message
> news:5b147e88-cc0a-4cbc-a49d-c7fe3bf55...@zend.com...
> >
> >
> >> On 14 ? 2016, at 7:14, Larry Garfield <la...@garfieldtech.com> wrote:
> >>
> >>> On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
> >>> Hi!
> >>>
> >>>> May I suggest you the following article (more of a starting point
> >>>> into Ceylon actually) regarding this topic:
> >>> There was a time where PHP was considered a good beginner's language.
> >>> Now it seems we want to pivot and target category theory PhDs instead?
> >>> :)
> >>
> >> A language that is usable primarily by beginners will only be useful
> >> for beginners.  Non-beginners will shun it, or simply grow out of it
> >> and leave.
> >>
> >> A language that is usable only by PhDs will be useful only for PhDs.
> >> Beginners won't be able to comprehend it.
> >>
> >> A language that is usable by both beginners and PhDs, and can scale a
> >> user from beginner to PhD within the same language, will be used by both.
> >>
> >> Doing that is really hard. And really awesome. And the direction PHP
> >> has been trending in recent years is in that direction.  Which is
> >> pretty danged awesome. :-)
> >
> >I would argue that PHP was already doing that almost since inception.
> >I think we have ample evidence that we've been seeing a lot of
> >different types of usage - both beginners' and ultra advanced going on
> >in PHP for decades.
> >I would also argue that in recent years, the trending direction has
> >been focusing on the "PhDs", while neglecting the simplicity seekers
> >(which I wouldn't necessarily call beginners).  Making PHP more and
> >more about being like yet-another-language, as opposed to one that
> >tries to come up with creative, simplified ways of solving problems.
> >Last, I'd argue that a language that tries to be everything for
> >everybody ends up being the "everything's and the kitchen sink", rather
> >than somethings that is truly suitable for everyone.
> >
> >We also seemed to have dumped some of our fundamental working
> >assumptions - that have made PHP extremely successful to begin with:
> >
> >- Emphasis on simplicity
> >- Adding optional features makes the language more complex regardless
> >of whether everyone uses them or not
> >
> >It does seem as if we're trying to replicate other languages,
> >relentlessly trying to "fix" PHP, which has been and still is one of
> >the most successful languages out there - typically a lot more so than
> >the languages we're trying to replicate.
> >
> >Zeev
> 
> I agree with Zeev 100%. There are too many people out there who are trying
> to make the language more complicated than it need be just to prove how
> clever they are. The aim of any language should be to enable programmers to
> do complicated things in a simple way, and not to do simple things in a
> complicated way.
> 
> I have been programming for over 30 years, so in no way can I be classed as a
> newbie. PHP is my favourite language because of its simplicity. I started with
> PHP 4, and although I have upgraded to PHP 5 I refuse to use any of the
> "clever" additions which have been made to PHP 5 simply because I can
> achieve what I need to achieve WITHOUT using any of those additions.
> 
> I will not be making use of any changes that are made to the language in order
> to handle typed variables for the simple reason that PHP was specifically
> designed to be an untyped language, and in the 13+ years that I have been
> programming with PHP I have found that to be more of an advantage than a
> hindrance.


Tony,

I think this is taking the discussion a bit in the wrong direction.

I, for one, certainly don't think that our problem is people who want to prove 
how clever they are, and I do believe that people who are proposing additions 
and improvements to the language are doing it because they think it's a good 
thing.  That does not mean it is though.

I am also saying that generally speaking, most people who are on internals@ are 
biased through self-selection towards change.  People who are just happy the 
way things are, are unlikely to be on internals and are unlikely to want to 
contribute.  Fixing bugs, meticulously optimizing performance while maintaining

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

>> Reduce assertions*, enhance self-documentation, making code more robust,
>> perform checks in the VM and not in userland, ...

You don't reduce assertions, you just make them more cryptic and change
error message slightly.

> Oh oh oh, I forgot the very important unions *int|string* and
> *float|string* for overflows as one can encounter them from time to
> time; even in native code.

Not sure what are you referring here to, but I suspect you are trying to
reimplement weak typing in some partial inconsistent and strange way,
while pretending it's strong typing.

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

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Jordi Boggiano]

Heya,

On 14/04/2016 19:59, Stanislav Malyshev wrote:

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the


It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture.


I don't really think it's much more complex to grasp `Foo|Bar $foo` than 
only `Foo $foo`. I mean once you grasp the concept of type hints you 
probably have by then a good understanding of || and hopefully can 
derive understanding from there.


That said I agree it's rarely useful, and as such I am not expecting 
we'll see this all over the place, it's just nice to have when you need 
it, but I can't think of very many valid cases (nullable types are much 
more common).


Please take that into consideration as well when arguing that it adds 
complexity. If it's rarely seen in the wild it's not very valuable but 
it's *also* not hindering newcomers often.



You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.


Just to highlight one use case I can think of, here is one:

https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/MongoDBHandler.php#L51-L53

We need some sort of Mongo thing, and there are two available with 
different interfaces, so here both are accepted but as you see in the 
code below they are handled kinda separately. It would just save us 
those 3 lines of check if we could type-hint appropriately.


And it would save us one line of phpdoc as well because IDEs could infer 
the information from the code.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/14/2016 9:25 PM, Fleshgrinder wrote:
> On 4/14/2016 8:59 PM, Stanislav Malyshev wrote:
>> Hi!
>>
>>> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>> since it is super self-explanatory. However, I find myself checking the
>>
>> It may be self-explanatory for you. It's much less self-explanatory for
>> somebody just starting to learn. It is also very dangerous - if it's
>> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
>> or not string, can you call strlen on it? Etc., etc. It adds a lot of
>> cognitive load and complicates the whole picture. You may have a
>> specific use case where it is useful (which we have yet to see btw) but
>> please remember it's a language with literally millions of use cases and
>> users.
>>
> 
> Reduce assertions*, enhance self-documentation, making code more robust,
> perform checks in the VM and not in userland, ...
> 
> function fn($arg) {
> assert('is_string($arg) || method_exists($arg, "__toString")');
> }
> 
> interface Stringable {
> function __toString(): string;
> }
> 
> function fn(string|Stringable $arg) {
> // :)
> }
> 
> You can find more information on the topic here:
> 
> https://en.wikipedia.org/wiki/Tagged_union
> 
> * Assertions in PHP are very error prone if combined with refactoring
> due to the fact that one should enclose the actual assertion in a string.
> 

Oh oh oh, I forgot the very important unions *int|string* and
*float|string* for overflows as one can encounter them from time to
time; even in native code.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/14/2016 8:59 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>> since it is super self-explanatory. However, I find myself checking the
> 
> It may be self-explanatory for you. It's much less self-explanatory for
> somebody just starting to learn. It is also very dangerous - if it's
> either Foo or Bar, can you call Foo::stuff on it or not? If it's string
> or not string, can you call strlen on it? Etc., etc. It adds a lot of
> cognitive load and complicates the whole picture. You may have a
> specific use case where it is useful (which we have yet to see btw) but
> please remember it's a language with literally millions of use cases and
> users.
> 

Reduce assertions*, enhance self-documentation, making code more robust,
perform checks in the VM and not in userland, ...

function fn($arg) {
assert('is_string($arg) || method_exists($arg, "__toString")');
}

interface Stringable {
function __toString(): string;
}

function fn(string|Stringable $arg) {
// :)
}

You can find more information on the topic here:

https://en.wikipedia.org/wiki/Tagged_union

* Assertions in PHP are very error prone if combined with refactoring
due to the fact that one should enclose the actual assertion in a string.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> I don't know what is complicated about "string|Stringable" or "Foo|Bar"
> since it is super self-explanatory. However, I find myself checking the

It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.

> docs (IDE or online) in which order I need to pass arguments to one of
> the various mixed up functions in the core all the time.

Which takes about 0.5 seconds. Can we please not waste time on
discussing argument order some 9000th time?

> PHP is not easy, it has so many quirks that one needs to know of that
> you could make a PhD only for that.

PHP has some quirks, but it doesn't take PhD to look up argument order
in a manual. Anyway, having super-complicated type algebra does not help
any with argument order, so I'm not sure why it's brought here at all.

> https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> 
> This contains A LOT of that stuff.

Oh, could we please stop referring to this list of nitpicks each time we
discuss the language? About 90% of it is not worth the bytes spent on it
for discussing it again and again. Using it as some kind of magic "some
guy wrote article bashing PHP, therefore my proposals need to be
accepted" card makes no sense at all.

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

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/14/2016 2:47 PM, Lin Yo-An wrote:
> But weak type conversion and union type are not, it introduces more complex
> rules of how variables should be converted into another values, and there
> will be more implementation defined behavior. People will have to always
> have a cheatsheet or something to check whether if they write the correct
> code.
> 
> And I believe, if we can remove the support of weak type conversion, PHP
> could be a "consistent", "simple" language and it can help people write
> confident code.
> 

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the
docs (IDE or online) in which order I need to pass arguments to one of
the various mixed up functions in the core all the time.

PHP is not easy, it has so many quirks that one needs to know of that
you could make a PhD only for that.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

This contains A LOT of that stuff.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Levi Morrison]

> There are too many people out there who are trying to make the language more 
> complicated than it need be just to prove how clever they are.

I can assure you I am not proposing these RFCs to show how clever I am.

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Thu, Apr 14, 2016 at 5:44 PM, Alain Williams  wrote:

> On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:
>
> > I agree with Zeev 100%. There are too many people out there who are
> > trying to make the language more complicated than it need be just to
> > prove how clever they are. The aim of any language should be to
> > enable programmers to do complicated things in a simple way, and not
> > to do simple things in a complicated way.
>
> I disagree. My way of looking at it is that adding some features(eg the
> current
> type specification/checking) adds to the simplicity because I can say what
> types
> I want and don't need to write code to check the types of argument
> received by a
> function (etc).

Why would I want to check: because I value robustness, ie not having my code
> fall over because, somehow, a wrong type slips by unnoticed.



I think the original purpose of adding type system in Hack, is to provide
just-in-time compilation, this provides more information to let compiler to
optimize the code with specific type.

Haskell, OCaml, C or C++, these statically typed languages compile code
into executable binary, the compiler raises the warnings or errors before
executing it, thus they have more time to check type information, they
usually don't check type in the run-time.

However PHP is not, PHP runs script on the fly, and check the type in the
runtime (instead of compile time), therefore the type checking implemented
in PHP is a kind of execution performance trade off (until we implemented
the JIT compiler). and a complex type system add more extra work to the
whole system than statically typed language.

Adding type hinting makes people writing PHP code with more confident, I
like the scalar type hinting implemented in the current PHP.

But weak type conversion and union type are not, it introduces more complex
rules of how variables should be converted into another values, and there
will be more implementation defined behavior. People will have to always
have a cheatsheet or something to check whether if they write the correct
code.

And I believe, if we can remove the support of weak type conversion, PHP
could be a "consistent", "simple" language and it can help people write
confident code.



Cheers, Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 14/04/16 10:00, Tony Marston wrote:
> I have been programming for over 30 years, so in no way can I be classed
> as a newbie. PHP is my favourite language because of its simplicity. I
> started with PHP 4, and although I have upgraded to PHP 5 I refuse to
> use any of the "clever" additions which have been made to PHP 5 simply
> because I can achieve what I need to achieve WITHOUT using any of those
> additions.

+1
I certainly wish I'd stopped at PHP5.2 and simply maintained a safe copy
of that.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Lester Caine]

On 13/04/16 21:24, Stanislav Malyshev wrote:
>> May I suggest you the following article (more of a starting point into
>> > Ceylon actually) regarding this topic:
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)

Well it's well above my M.Sc in Digital Systems ... but that was gained
in 1982 and it seems even my wife's primary school charges are already
trained to a higher level of programming.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Alain Williams]

On Thu, Apr 14, 2016 at 10:00:41AM +0100, Tony Marston wrote:

> I agree with Zeev 100%. There are too many people out there who are
> trying to make the language more complicated than it need be just to
> prove how clever they are. The aim of any language should be to
> enable programmers to do complicated things in a simple way, and not
> to do simple things in a complicated way.

I disagree. My way of looking at it is that adding some features(eg the current
type specification/checking) adds to the simplicity because I can say what types
I want and don't need to write code to check the types of argument received by a
function (etc).

Why would I want to check: because I value robustness, ie not having my code
fall over because, somehow, a wrong type slips by unnoticed.

Does that make quick/simple programming not possible in PHP ?

No: I will put the most of the robustness work into libraries/classes that I
write and want to reuse - the simple programs that use them don't necessarily be
written to the same standard.

> I have been programming for over 30 years, so in no way can I be
> classed as a newbie. PHP is my favourite language because of its
> simplicity. I started with PHP 4, and although I have upgraded to
> PHP 5 I refuse to use any of the "clever" additions which have been
> made to PHP 5 simply because I can achieve what I need to achieve
> WITHOUT using any of those additions.
> 
> I will not be making use of any changes that are made to the
> language in order to handle typed variables for the simple reason
> that PHP was specifically designed to be an untyped language, and in
> the 13+ years that I have been programming with PHP I have found
> that to be more of an advantage than a hindrance.

Type juggling is useful, but somewhere you do need to check your input.

I doubt that we will agree, but we don't need to: we prob have different aims
and goals. There is no reason that PHP cannot satisfy both of us.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include 

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

"Zeev Suraski"  wrote in message 
news:5b147e88-cc0a-4cbc-a49d-c7fe3bf55...@zend.com...




On 14 ? 2016, at 7:14, Larry Garfield  wrote:


On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
Hi!


May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this topic:

There was a time where PHP was considered a good beginner's language.
Now it seems we want to pivot and target category theory PhDs instead? 
:)


A language that is usable primarily by beginners will only be useful for 
beginners.  Non-beginners will shun it, or simply grow out of it and 
leave.


A language that is usable only by PhDs will be useful only for PhDs. 
Beginners won't be able to comprehend it.


A language that is usable by both beginners and PhDs, and can scale a 
user from beginner to PhD within the same language, will be used by both.


Doing that is really hard. And really awesome. And the direction PHP has 
been trending in recent years is in that direction.  Which is pretty 
danged awesome. :-)


I would argue that PHP was already doing that almost since inception.  I 
think we have ample evidence that we've been seeing a lot of different 
types of usage - both beginners' and ultra advanced going on in PHP for 
decades.
I would also argue that in recent years, the trending direction has been 
focusing on the "PhDs", while neglecting the simplicity seekers (which I 
wouldn't necessarily call beginners).  Making PHP more and more about being 
like yet-another-language, as opposed to one that tries to come up with 
creative, simplified ways of solving problems.
Last, I'd argue that a language that tries to be everything for everybody 
ends up being the "everything's and the kitchen sink", rather than 
somethings that is truly suitable for everyone.


We also seemed to have dumped some of our fundamental working assumptions - 
that have made PHP extremely successful to begin with:


- Emphasis on simplicity
- Adding optional features makes the language more complex regardless of 
whether everyone uses them or not


It does seem as if we're trying to replicate other languages, relentlessly 
trying to "fix" PHP, which has been and still is one of the most successful 
languages out there - typically a lot more so than the languages we're 
trying to replicate.


Zeev


I agree with Zeev 100%. There are too many people out there who are trying 
to make the language more complicated than it need be just to prove how 
clever they are. The aim of any language should be to enable programmers to 
do complicated things in a simple way, and not to do simple things in a 
complicated way.


I have been programming for over 30 years, so in no way can I be classed as 
a newbie. PHP is my favourite language because of its simplicity. I started 
with PHP 4, and although I have upgraded to PHP 5 I refuse to use any of the 
"clever" additions which have been made to PHP 5 simply because I can 
achieve what I need to achieve WITHOUT using any of those additions.


I will not be making use of any changes that are made to the language in 
order to handle typed variables for the simple reason that PHP was 
specifically designed to be an untyped language, and in the 13+ years that I 
have been programming with PHP I have found that to be more of an advantage 
than a hindrance.


--
Tony Marston


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Peter Lind]

On 14 April 2016 at 01:43, Zeev Suraski  wrote:

>
> > On 14 באפר׳ 2016, at 7:14, Larry Garfield 
> wrote:
> >
> >> On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
> >> Hi!
> >>
> >>> May I suggest you the following article (more of a starting point into
> >>> Ceylon actually) regarding this topic:
> >> There was a time where PHP was considered a good beginner's language.
> >> Now it seems we want to pivot and target category theory PhDs instead?
> :)
> >
> > A language that is usable primarily by beginners will only be useful for
> beginners.  Non-beginners will shun it, or simply grow out of it and leave.
> >
> > A language that is usable only by PhDs will be useful only for PhDs.
> Beginners won't be able to comprehend it.
> >
> > A language that is usable by both beginners and PhDs, and can scale a
> user from beginner to PhD within the same language, will be used by both.
> >
> > Doing that is really hard. And really awesome. And the direction PHP has
> been trending in recent years is in that direction.  Which is pretty danged
> awesome. :-)
>
> I would argue that PHP was already doing that almost since inception.  I
> think we have ample evidence that we've been seeing a lot of different
> types of usage - both beginners' and ultra advanced going on in PHP for
> decades.
> I would also argue that in recent years, the trending direction has been
> focusing on the "PhDs", while neglecting the simplicity seekers (which I
> wouldn't necessarily call beginners).  Making PHP more and more about being
> like yet-another-language, as opposed to one that tries to come up with
> creative, simplified ways of solving problems.
> Last, I'd argue that a language that tries to be everything for everybody
> ends up being the "everything's and the kitchen sink", rather than
> somethings that is truly suitable for everyone.
>
> We also seemed to have dumped some of our fundamental working assumptions
> - that have made PHP extremely successful to begin with:
>
> - Emphasis on simplicity
> - Adding optional features makes the language more complex regardless of
> whether everyone uses them or not
>
>
Really? The recent number of RFCs focusing on making some of PHPs
annoyances go away have passed you by? They seem to fall squarely within
"emphasis on simplicity" as far as I can tell.

Also, PHP is known as the language with a million ways to do things, where
some functions even have aliases because reasons. It's been that way since
a very long time. That suggests to me that complexity/optional features are
not frowned upon - only some types of complexity are seen as bad, and only
some types of simplicity are apparent worthwhile. Spelling out personal
preferences here would probably help solve these discussions faster.



> It does seem as if we're trying to replicate other languages, relentlessly
> trying to "fix" PHP, which has been and still is one of the most successful
> languages out there - typically a lot more so than the languages we're
> trying to replicate.
>
>
Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Re: Improving PHP's type system

[Zeev Suraski]

> On 14 באפר׳ 2016, at 7:14, Larry Garfield  wrote:
> 
>> On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
>> Hi!
>> 
>>> May I suggest you the following article (more of a starting point into
>>> Ceylon actually) regarding this topic:
>> There was a time where PHP was considered a good beginner's language.
>> Now it seems we want to pivot and target category theory PhDs instead? :)
> 
> A language that is usable primarily by beginners will only be useful for 
> beginners.  Non-beginners will shun it, or simply grow out of it and leave.
> 
> A language that is usable only by PhDs will be useful only for PhDs.  
> Beginners won't be able to comprehend it.
> 
> A language that is usable by both beginners and PhDs, and can scale a user 
> from beginner to PhD within the same language, will be used by both.
> 
> Doing that is really hard. And really awesome. And the direction PHP has been 
> trending in recent years is in that direction.  Which is pretty danged 
> awesome. :-)

I would argue that PHP was already doing that almost since inception.  I think 
we have ample evidence that we've been seeing a lot of different types of usage 
- both beginners' and ultra advanced going on in PHP for decades.
I would also argue that in recent years, the trending direction has been 
focusing on the "PhDs", while neglecting the simplicity seekers (which I 
wouldn't necessarily call beginners).  Making PHP more and more about being 
like yet-another-language, as opposed to one that tries to come up with 
creative, simplified ways of solving problems.
Last, I'd argue that a language that tries to be everything for everybody ends 
up being the "everything's and the kitchen sink", rather than somethings that 
is truly suitable for everyone.

We also seemed to have dumped some of our fundamental working assumptions - 
that have made PHP extremely successful to begin with:

- Emphasis on simplicity
- Adding optional features makes the language more complex regardless of 
whether everyone uses them or not

It does seem as if we're trying to replicate other languages, relentlessly 
trying to "fix" PHP, which has been and still is one of the most successful 
languages out there - typically a lot more so than the languages we're trying 
to replicate.

Zeev

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/13/16 3:24 PM, Stanislav Malyshev wrote:

Hi!


May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this topic:

There was a time where PHP was considered a good beginner's language.
Now it seems we want to pivot and target category theory PhDs instead? :)


A language that is usable primarily by beginners will only be useful for 
beginners.  Non-beginners will shun it, or simply grow out of it and leave.


A language that is usable only by PhDs will be useful only for PhDs.  
Beginners won't be able to comprehend it.


A language that is usable by both beginners and PhDs, and can scale a 
user from beginner to PhD within the same language, will be used by both.


Doing that is really hard. And really awesome. And the direction PHP has 
been trending in recent years is in that direction.  Which is pretty 
danged awesome. :-)


--
--Larry Garfield


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/13/2016 10:24 PM, Stanislav Malyshev wrote:
> Hi!
> 
>> May I suggest you the following article (more of a starting point into
>> Ceylon actually) regarding this topic:
> 
> There was a time where PHP was considered a good beginner's language.
> Now it seems we want to pivot and target category theory PhDs instead? :)
> 

Hahaha funny how many people consider Ceylon to be too academic. :)

I personally just want to make the language more consistent, secure (in
terms of introduction of bugs and error handling), and better suited for
real enterprise and high performance usage. And of course learn a
shitload about language design along the way. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Stanislav Malyshev]

Hi!

> May I suggest you the following article (more of a starting point into
> Ceylon actually) regarding this topic:

There was a time where PHP was considered a good beginner's language.
Now it seems we want to pivot and target category theory PhDs instead? :)
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

On 4/13/2016 9:57 PM, Levi Morrison wrote:
> On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder  wrote:
>> Nothing to add other than +1, however, didn't you already write those?
>>
>> https://wiki.php.net/rfc/nullable_types
>> https://wiki.php.net/rfc/union_types
>>
>> Or is this just an announcement that these will be finalized now?
>>
>> Btw. I am in favor of having the question mark as a suffix and not as a
>> prefix because it is more readable and more natural to type.
>>
>> function fn(string? $str): bool?;
>>
>> Declare a function with the name fn that takes a string argument that is
>> nullable which will return a bool or null.
>>
>> That is exactly how I would think about the above while writing and
>> reading. :)
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
> 
> I have written them but later they will be formally moved to Under
> Discussion and will create new threads for them here on the mailing
> list.
> 

Awesome, let me know if I can be of any help, even if it is only proof
reading. This is an extremely valuable addition that I want to have.

May I suggest you the following article (more of a starting point into
Ceylon actually) regarding this topic:

http://ceylon-lang.org/documentation/tour/types/

Ceylon is very nicely designed regarding union and intersection types
and I think it can add value to learn from these people too. I am not
handing out this because I think that you don't know what you are doing.
The opposite is the case. However, Ceylon is very young and I don't
think many people know of it; while you probably already know all the
oldies who support union and intersection types. ;)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Improving PHP's type system

[Levi Morrison]

On Wed, Apr 13, 2016 at 1:10 PM, Fleshgrinder  wrote:
> Nothing to add other than +1, however, didn't you already write those?
>
> https://wiki.php.net/rfc/nullable_types
> https://wiki.php.net/rfc/union_types
>
> Or is this just an announcement that these will be finalized now?
>
> Btw. I am in favor of having the question mark as a suffix and not as a
> prefix because it is more readable and more natural to type.
>
> function fn(string? $str): bool?;
>
> Declare a function with the name fn that takes a string argument that is
> nullable which will return a bool or null.
>
> That is exactly how I would think about the above while writing and
> reading. :)
>
> --
> Richard "Fleshgrinder" Fussenegger
>

I have written them but later they will be formally moved to Under
Discussion and will create new threads for them here on the mailing
list.

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Fleshgrinder]

Nothing to add other than +1, however, didn't you already write those?

https://wiki.php.net/rfc/nullable_types
https://wiki.php.net/rfc/union_types

Or is this just an announcement that these will be finalized now?

Btw. I am in favor of having the question mark as a suffix and not as a
prefix because it is more readable and more natural to type.

function fn(string? $str): bool?;

Declare a function with the name fn that takes a string argument that is
nullable which will return a bool or null.

That is exactly how I would think about the above while writing and
reading. :)

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature