Awesome feature thanks for the RFC. :) On 3/16/2016 5:36 PM, Phil Sturgeon wrote: > 1. How scared are we that integers can be expanded to floats on runtime? >
This is already what happens in PHP all the time and I personally only
see harm if we change that. People are already not understand what the
difference between the two is and someone who is serious about this
topic is taking care of it on her/his own (many thanks to *intdiv*) or
is using strings anyways (*bcmath*/*gmp*).
On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 2. This whole temporary nullability situation, where unset properties
> will error on attempted usage if not set. Should they instead error
> after the constructor has been called if they are still not holding a
> value?
>
I see a big problem with the erroring no matter when as others already
pointed out, e.g. together with named constructors (or factory methods
if you prefer that name) but also with lazy loading. I think that the
null value of properties during and after construction should simply be
ignored and left to the implementer. I know that it would be nice to
have 100% assurance that the property is always set but it would simply
result in rules that are too strict for various use cases. I mean,
aren't we trying to solve a problem that never was a problem here?
Another more complicated user case would be *mysqli_fetch_object* that
populates the properties with values from a storage but values that
should become something specific and strict at some point but are
initially populated as strings. Type coercion would be a nice thing here
but with strict checks afterwards. Note that this cannot be handled by
the extension due to user types:
final class Bar {
private string $data;
public function __construct(string $data) {
$this->data = $data;
}
}
final class Foo {
private Bar $bar;
private function __construct() {
if (isset($this->bar)) {
$this->bar = new Bar($bar);
}
}
}
$mysqli_result->fetch_object(Foo::class);
It is correctly populated with a string and the constructor changes it
to the desired instance. All fine, but the strict type check would kill
everything here.
I think that the strict type checks should start with the first
*userland* assignment and at no other point in time. The correct
initialization of an object is up to the implementer as it always was.
On 3/16/2016 6:27 PM, Chris Riley wrote:
> [...] how about some syntax which allows for a property to be null,
> or for it to be a specific type. I'd suggest a null assignment to
> fall in line with parameter type hints eg:
>
> class Foo {
> protected int $bar = null; //can be null
> private stdClass $baz; //can't be null
> }
>
This aligns nicely with the syntax that is present in PHP for arguments
since ages and it directly could solve the Nullable problem mentioned in
future scope. An example to illustrate how nicely it aligns with
existing PHP 5+ syntax:
final class Foo {
private int $bar = null;
public function setBar(int $bar = null): void {
$this->bar = $bar;
}
}
(new Foo)->setBar(42);
(new Foo)->setBar(null);
Additionally the extreme verbosity is super nice.
On 3/16/2016 5:36 PM, Phil Sturgeon wrote:
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their public API".
>
An ini setting to control type checks and hints would be a nice thing to
have. Like the checked mode of Google's Dart language. Such a setting
could and should also allow to disable type checks altogether, like we
have it with assertions:
strict_types = -1 ; NOOP
strict_types = 0 ; PHP 5 Style
strict_types = 1 ; PHP 7 Coercion Style
strict_types = 2 ; PHP 7 Strict Style
Where 1 would be the default since the default should be for development
and people who hate strict types just throw that zero in their ini and
are fine to reuse any code out there while ignoring all property/scalar
type checks/hints.
This would make the `declare` thingy pretty useless and I think it is
easier to understand. I thought that this approach was kind of weird
since its inception.
On 3/16/2016 6:39 PM, Johannes Schlüter wrote:
> What about references? (yeah, references should die, but currently
> they still exist)
>
> What's expected here:
>
> class A {
> public int $i;
> }
>
> $a = new A();
> $r = &$a->i;
> $r = "foobar";
>
I think this missing functionality is a blocker right now. Either we
have a plan to get rid of references altogether as Johannes mentions it
or the typed properties need support for it.
Note that the following currently works with the patch, which might lead
to more ranting in regards to missing/overlooked functionality if the
properties on their own do not support it.
declare(strict_types=1);
class A {
private int $x = 0;
public function &x(): int {
return $this->x;
}
}
$a = new A;
$x =& $a->x();
$x = 42;
echo $a->x(); // 42
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
