On 3/19/2016 9:32 PM, Andrea Faulds wrote: > Hi, > > Fleshgrinder wrote: >> 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? > > This is actually a problem for optimising PHP. If the compiler cannot be > sure a property's value actually matches its declared type, it can't > optimise operations on that property to remove a type check. >
Can we optimize operations or is this theoretical?
On 3/19/2016 9:32 PM, Andrea Faulds wrote:
> I also think it would be unintuitive if typed properties had some
> exception where they don't obey the given type. If I ask for an integer,
> then surely I should get an integer?
>
Of course but there is some *void* time until an object is fully
initialized. We've seen many examples now in this thread.
On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>>
>> 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.
>
> This adds a loophole to property type checks which, as previously
> mentioned, prevents us from performing optimisations. I also don't see
> why internal functions should be treated specially here, given that
> surely one could write userland code with the same needs as MySQLi? It
> doesn't seem intuitive.
>
It is just code that exists and is used and I am trying to find a
solution for it together with this new feature. I already wrote that I
would highly prefer that *mysqli_result::fetch_object* and
*PDOStatement::fetchObject* work differently but I am not the maintainer
and I cannot tell if they are willing to change their behavior.
The auto-mapping these methods provide is in general an extremely nice
thing to have. Plus it is much faster than a comparable userland
solution; which is of course implementable.
On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>> 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.
>
> We could certainly do this, but I'm not sure we should. Like for
> arguments, this would mean that your default value must be null, and you
> don't have to assign to it. But what if you want a different default
> value? What if you want to require it be assigned to?
>
> Adding a syntax form for nullable types (e.g. `?int` or `int|null`)
> would avoid these issues, and also solve the nullable return type issue.
>
You are absolutely right I did not think about that. But currently it
seems as if nobody (including me) wants nullable types anyways.
On 3/19/2016 9:32 PM, Andrea Faulds wrote:
>> 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.
>
> An INI setting to control type checks is impractical, because it would
> affect all PHP code running in a given PHP interpreter. This means you
> control not only the type checking mode of your own code, but also of
> all the libraries you're using. Unless you never use other people's
> code, using this INI setting would just break things.
>
>> 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
>
> Why would you want to disable type checks altogether? There might be a
> small performance improvement, but you've removed important error
> checking. What if something goes wrong at runtime?
>
>> Where 1 would be the default since the default should be for development
This should have been 2.
>> 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 solves a problem which I don't believe exists. The system PHP 7 has
> means that if you don't want to use strict types, they never affect you.
>
>>
>> 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.
>
> Yes, the declare() approach is unusual compared to other settings.
> That's because it was designed so the choices your code makes doesn't
> affect other code which uses it. In the Composer era, this matters,
> because a lot of code your interpreter is running will not be written or
> maintained by you.
>
> Thanks.
>
I just though its nice to have the setting without having a strong
opinion about it.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
