Consider dropping PHP 5 support

[Ocramius]

PHP 7 has declare(strict_types=true), which is awesome, tbh.

We'd also be able to throw more specific exceptions.

[Ocramius]

Not sure about this yet. Maybe release 1.0.0 for PHP 5.5 and then bump to PHP 7 for 2.0.0?

[gianarb]

1.0.0 => 5.5
2.0.0 => 7
👍 👍

[GeeH]

Doesn't PHP7 remove a lot of need for this with STH and RTH though?

On Fri, 26 Jun 2015 at 23:27 Gianluca Arbezzano notifications@github.com
wrote:

1.0.0 => 5.5
2.0.0 => 7
[image: 👍] [image: 👍]

—
Reply to this email directly or view it on GitHub
#7 (comment).

[Ocramius]

Exactly. It mitigates also some of the code required in this repo.
On Jun 27, 2015 11:38 AM, "Gary Hockin" notifications@github.com wrote:

Doesn't PHP7 remove a lot of need for this with STH and RTH though?

On Fri, 26 Jun 2015 at 23:27 Gianluca Arbezzano notifications@github.com
wrote:

1.0.0 => 5.5
2.0.0 => 7
[image: 👍] [image: 👍]

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[GeeH]

You mistake me.

When I have STH in my setters, then I no longer need boilerplate tests to check types, therefore I have very much LESS need for this library.

So basically making it PHP 6 only negates the main need for the library, therefore causing the world to implode.

👎

[Ocramius]

@GeeH this library verifies assignments at property level. STH are more about what I'm currently implementing in #20 (except that I went the extra mile to make it more awesome):

[GeeH]

I am not an idiot, I understand what it does.

However, my point still stands, with the advent of PHP 6 I can simply create a setter around my object and STH which is a) production ready, and b) much easier than all that messing about in hyperspace.

[malukenho]

@GeeH It's provide more features them STH as parameter interface jailing, which is awesome IMHO.
So this don't invalidate this library.

[GeeH]

I'm not saying it invalidates the library, what I am saying is that is seriously limits the audience.

[GeeH]

BTW - I was sitting with @Ocramius as he coded this, I know what the library does 😉

[GeeH]

Let me make myself clear:

Scenario One: PHP 7.x only

• parameter/property protection is not so useful because I can easily protect parameters via STH/RTH
• interfacing jailing useful
  Target user-base = fair

Scenario Two: PHP 5.x (but runs on PHP 7 correctly)

• parameter/property incredibly useful to PHP 5.x users because no STH/RTH
• interface jailing userful
  Target user-base = good

[Ocramius]

Note that property protection can't be achieved at language level ATM, because we don't have property accessors :sadpanda: :-(

[GeeH]

@Ocramius I get that, but here is the scenario

Mary is using PHP 7 and has public properties. She's sick of writing 100s of shitty boilerplate tests that check what happens when properties are of given types, and decides to bite the bullet and refactor her application so that she has some type protection in the properties.

"OH! Look!" she exclaims, "I can either refactor my public properties to private, wrap them in type-hinted accessor methods and then use my unit tests to confirm I've caught all the places I need to change a property access to a method call... OR I can install this crazy voodoo reflection based cocktail of insanity that I will only be able to use in my tests and will give me no protection at run-time".

Mary decides to write the type hinted accessor methods.

[Ocramius]

@GeeH this library checks private state as well, but again, is not meant as drop-in type-safety engine for everything.

It is not providing type safety, it is providing fuckups-safety (so yes, it is an aid for Mary that is writing type-hinted accessors), so that she doesn't forget assigning something, or forgot a type hint, or had an expression th.

This is not a replacement for good coding, it is just an extra strict mode for development only.

Here's what the exact use-case for these failures looks like (in PHP 7):

/**
 * @param $age
 * mary forgot the type-hint due to old habits or IDE autocompletion without type
 */
public function __construct($age)
{
    $this->age = $age; // no type-cast because she assumes PHP 7
}

The check is applied on property assignment ($age is marked as int).

If I catch anyone using this library as a replacement for property accessors they are going to have a bad day because of me torturing them.

@GeeH you might want to make that clear in the docs, since it seems like you also confused the scope of this project.

[GeeH]

Everything you say doesn't change the fact that usage is reduced in PHP7.

[GeeH]

Also

/**
 * @param $age
 *  Mary didn't forget the type hint
 */
public function __construct(int $age)
{
    $this->age = $age; // yay, it's type cast
}

[Ocramius]

@GeeH this lib is not about providing the type-safety, it's about finding out where you forgot to provide it yourself (snippet of code you pasted is AFTER you corrected a StrictPhp failure)

[GeeH]

OK OK OK OK OK OK

🎤 ⬇️

[Ocramius]

After careful consideration, it is clear to me that there is no need for a PHP5 version of this library, as it is to be used in development environments only anyway.