Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27/05/16 18:25, Rowan Collins wrote: > On 27 May 2016 10:53:05 GMT+01:00, Lester Caine wrote: >>On 27/05/16 10:16, Rowan Collins wrote: >>> The most useful typehints are inside the SomeModel class, not the >>> table-level wrapper. This is true even if they're just dumb structs, >>and >>> all the behaviour is at the table level, because it presumably has >>> basically one field: array $data. >> >>Probably the only difference here is that '$row' in my result set is >>not >>a dumb structure. It has type information, field lengths and >>potentially >>even value constraints. > > Do you mean it "has" that type information because it's guaranteed by > other logic? Or is $row already an object, in which case we're saying > the same thing? As there is no current way of adding type information to the elements of an associative array one has to manipulate http://adodb.org/dokuwiki/doku.php?id=v5:dictionary:adofieldobject to obtain the missing information. ADOdb will also return the row as an object http://adodb.org/dokuwiki/doku.php?id=v5:reference:recordset:fetchobj and I have been trying for 15+ years to make that work with the type data we have always had here. The important thing to note here is that rather than having a pre-defined set of fields with pre-defined types, the result set can be controlled by what is returned by the database! While a 'built in' object would have to define every possible filed that might be used. I know that we have had differences in the past on 'well defined data', and I do accept that providing a fixed set of fields would be a preferable way of working, but being able to take a flexible result set and provide a clean fully typed object from it should not be difficult? >> So my table level wrapper can potentially have >>the same typehints that you are then adding to SomeModel. > > An object holding 20 people has no "date of birth" property, so how can > it have a typehint for it? An object representing one row of the table > can, and that's what most of the examples here are talking about. My initial query will establish the tree of people available in the database, and just what data fields are available. Some fields are 'required' such as 'dateofbirth' which are by definition a DateTime type but wild card results will add additional fields. > I think maybe we're just talking cross-purposes - my example was a > clumsy way of saying that *somewhere* the raw data coming back from the > DBMS driver gets converted to an appropriate object. ADOdb will return a fully formed object containing it's set of data if we get the way of handling typed 'variables' sorted properly! The 'person' object simply becomes a database query return ... and no secondary copying is needed. > The main point was that that conversion doesn't need some pool of empty > objects to "fill up" with data, it just creates a new object for each > row in the result set. My 'empty pots' are more related to rendering the displayed page. I can see where my terminology is perhaps wrong, and perhaps a different way of handling things which in the past have been easy as associative arrays with null elements. It's being able to pick up just what validation is needed on the page for those empty inputs which needs more than a null object? The empty pot has all of the type/attribute information ... -- 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] [RFC][Vote] Typed Properties
On 5/27/2016 7:48 PM, Rowan Collins wrote:
> On 27 May 2016 11:25:48 GMT+01:00, Fleshgrinder wrote:
>> if (isset($row['d'])) {
>>$o->d = new DateTime($row['d']);
>> }
>>
>> No need to assign null since it already is null by default and the
>> nullable hint will not result in any errors upon accessing it.
>
> Actually, that's one of the points up for discussion: should accessing the
> property when no assignment has been made raise an E_NOTICE, so that there is
> a difference between "?int $foo" and "?int $foo = null".
>
> Regards,
>
True, I forgot and I am in favor of E_NOTICE. This was actually part of
my super confusing long example.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27 May 2016 11:25:48 GMT+01:00, Fleshgrinder wrote:
> if (isset($row['d'])) {
>$o->d = new DateTime($row['d']);
> }
>
>No need to assign null since it already is null by default and the
>nullable hint will not result in any errors upon accessing it.
Actually, that's one of the points up for discussion: should accessing the
property when no assignment has been made raise an E_NOTICE, so that there is a
difference between "?int $foo" and "?int $foo = null".
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27 May 2016 13:34:17 GMT+01:00, Lester Caine wrote: >Hence the 'in an ideal world'! It is perhaps worth making clear that a >'typed property' element IS simply a holder for the pointer to the real >element while the untyped properties are the element themselves? In database terms, a property - typehinted or not, scalar, whatever - is like a column. On a particular instance (= row) each property will have some particular value. Consider how "father" would be modelled as a foreign key in the DB. If you don't know the father, you would insert a null, not reference a special row representing The NullFather. And if you discovered the father was incorrect, you would update the row to point at a new record, not change the name on the old father record - it is not the name that was incorrect, only the relationship. So in OO you do the same: if you don't know the father, you store a null in that field. If you want to change the father, you point at a new object, you don't go in and edit the existing one. $this->father = $newFather; There's no "empty object" here, no need to "reset" the object which was incorrectly assigned to the father property, just a new association representing the corrected information. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27 May 2016 10:53:05 GMT+01:00, Lester Caine wrote: >On 27/05/16 10:16, Rowan Collins wrote: >> The most useful typehints are inside the SomeModel class, not the >> table-level wrapper. This is true even if they're just dumb structs, >and >> all the behaviour is at the table level, because it presumably has >> basically one field: array $data. > >Probably the only difference here is that '$row' in my result set is >not >a dumb structure. It has type information, field lengths and >potentially >even value constraints. Do you mean it "has" that type information because it's guaranteed by other logic? Or is $row already an object, in which case we're saying the same thing? > So my table level wrapper can potentially have >the same typehints that you are then adding to SomeModel. An object holding 20 people has no "date of birth" property, so how can it have a typehint for it? An object representing one row of the table can, and that's what most of the examples here are talking about. I think maybe we're just talking cross-purposes - my example was a clumsy way of saying that *somewhere* the raw data coming back from the DBMS driver gets converted to an appropriate object. The main point was that that conversion doesn't need some pool of empty objects to "fill up" with data, it just creates a new object for each row in the result set. -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27/05/16 15:12, Ryan Pallas wrote: > Now you can blindly initialize it, and call format on it, whether or not > the date is provided. This is all controllable in userland, there is no > reason to make the language do it for you, as its purely a design decision. Which has been the main argument all along. And if I'm doing it all in userland anyway I do it in the database read/write rather than duplicating all of that in secondary copies ... -- 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] [RFC][Vote] Typed Properties
On Fri, May 27, 2016 at 6:34 AM, Lester Caine wrote:
> On 27/05/16 11:25, Fleshgrinder wrote:
> > On 5/27/2016 11:41 AM, Lester Caine wrote:
> >> Now I am confused, but it's probably because I'm looking at a simple
> >>
> >> $f->d = new DateTime( $initial );
> >>
> >> While you are looking at
> >>
> >> If ( isset($initial) )
> >> then $f->d = new DateTime( $initial );
> >> else $f->d = null;
> >>
> >> While the original code would have simply been
> >>
> >> $f->d = $initial;
> >>
> >> And in an ideal world, because $d has been typed as DateTime this would
> >> magically run 'new DateTime($initial)' which is where I am stumbling
> >> because *I* simply look at '?DateTime $d' as creating a DateTime object
> >> where in fact $d is a different type of object which will then hold the
> >> link to the real one. I am still looking for $d to be an object I can do
> >> all of the checks on that are provided by int or DateTime as appropriate
> >> ... the object needs to exist before the 'new' in order to know if you
> >> need the first or second type of $initial code ... or we make typed
> >> properties only work one way or the other?
> >
> > PHP does not automagically instantiate the DateTime object for you, this
> > is still your responsibility. The type hint on the property only
> > restricts what you are allowed to assign to the property, nothing else.
>
> If you want something to magically happen when setting a property, PHP has
a way to do this called magic methods. Think about this:
class Person {
protected ?DateTime $death;
public function setDeath($date) {
if (!empty($date) && is_string($date)) {
$this->death = new DateTime($date);
}
elseif ($date instanceof DateTime) {
$this->death = $date;
}
// else $date is empty, person has not died
}
public function __set($prop, $val) {
if (method_exists($this, "set_$prop")) {
$this->{"set_$prop"}($val);
}
}
public function __get($prop) {
if (property_exists($this, $prop)) {
return $this->$prop;
}
}
}
$p = new Person();
$p->death = "2015-06-01";
var_dump($p->death); // class DateTime#1 (3) { ...
$p2 = new Person();
$p2->death = new DateTime("2016-01-02");
var_dump($p2->death); // class DateTime#1 (3) { ...
$p3 = new Person();
var_dump($p3->death); // NULL, $p3 is not dead
Note, all of this is possible currently except the typing of the property,
you could enforce this right now in exactly this way.
If however, you want an object that will provide a format function (as in
your example) whether or not it was initiated with a value, then you would
need to define your own class for that:
class MyDateTime {
protected $dt;
public function __construct($date) {
if (!empty($date)) {
$this->dt = new DateTime($date);
}
}
public function format($format) {
if (!empty($this->dt)) {
return $this->dt->format($format);
}
return '';
}
}
Now you can blindly initialize it, and call format on it, whether or not
the date is provided. This is all controllable in userland, there is no
reason to make the language do it for you, as its purely a design decision.
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 5/27/2016 2:34 PM, Lester Caine wrote: > Hence the 'in an ideal world'! It is perhaps worth making clear that a > 'typed property' element IS simply a holder for the pointer to the real > element while the untyped properties are the element themselves? The > differentiation of 'scalar' probably comes into play, but does that > result in untyped scalers having to have the overheads for adding the > type flags? > Nope, they both work exactly the same way. Typed properties just guard the properties from assignment of values that are not typed hinted against. I don't know what you mean with untyped scalars. Every variable always has a type. It is up to you if you care about it or not. On 5/27/2016 2:34 PM, Lester Caine wrote: > And 32bit builds mess things up as well ... > YES! On 5/27/2016 2:34 PM, Lester Caine wrote: > With the proviso that $o is not used again ... currently all of my > object classes have a constructor for a blank object along with a loader > to 'initialize' the data. Empty objects such as 'father' can be > populated with data and saved, loaded with an existing record, or wiped > if incorrect associations existed ... allowing the correct data to be > added. AJAX allows things to happen within a page which in the past > would have been complete new page loads without any of the problems of > 'cached' data? > Sounds like bad design to me where you always need to know when to call what and when what was called but if it works for you. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27/05/16 11:25, Fleshgrinder wrote:
> On 5/27/2016 11:41 AM, Lester Caine wrote:
>> Now I am confused, but it's probably because I'm looking at a simple
>>
>> $f->d = new DateTime( $initial );
>>
>> While you are looking at
>>
>> If ( isset($initial) )
>> then $f->d = new DateTime( $initial );
>> else $f->d = null;
>>
>> While the original code would have simply been
>>
>> $f->d = $initial;
>>
>> And in an ideal world, because $d has been typed as DateTime this would
>> magically run 'new DateTime($initial)' which is where I am stumbling
>> because *I* simply look at '?DateTime $d' as creating a DateTime object
>> where in fact $d is a different type of object which will then hold the
>> link to the real one. I am still looking for $d to be an object I can do
>> all of the checks on that are provided by int or DateTime as appropriate
>> ... the object needs to exist before the 'new' in order to know if you
>> need the first or second type of $initial code ... or we make typed
>> properties only work one way or the other?
>
> PHP does not automagically instantiate the DateTime object for you, this
> is still your responsibility. The type hint on the property only
> restricts what you are allowed to assign to the property, nothing else.
Hence the 'in an ideal world'! It is perhaps worth making clear that a
'typed property' element IS simply a holder for the pointer to the real
element while the untyped properties are the element themselves? The
differentiation of 'scalar' probably comes into play, but does that
result in untyped scalers having to have the overheads for adding the
type flags?
> It is true that PHP will coerce the value automatically if you are in
> weak mode but this is only true for scalar values and nothing else. Also
> note that you might not want that while working with a database because
> PHP might destroy your UNSIGNED BIGINTs without you noticing.
And 32bit builds mess things up as well ...
> class O {
> public ?DateTime $d;
> }
>
> if (isset($row['d'])) {
> $o->d = new DateTime($row['d']);
> }
>
> No need to assign null since it already is null by default and the
> nullable hint will not result in any errors upon accessing it.
With the proviso that $o is not used again ... currently all of my
object classes have a constructor for a blank object along with a loader
to 'initialize' the data. Empty objects such as 'father' can be
populated with data and saved, loaded with an existing record, or wiped
if incorrect associations existed ... allowing the correct data to be
added. AJAX allows things to happen within a page which in the past
would have been complete new page loads without any of the problems of
'cached' data?
> PS: The UNSIGNED BIGINT thing is one of the reasons why I want
> intersection and union types so that we can do the following:
>
> class O {
> private int|string $id;
> }
>
> And leave it to a more intelligent system to determine whether this can
> be safely converted to an int or not (e.g. MySQLi).
And the same thing applies to me except in relation to 32 bit or 64 bit
integers. Many legacy systems still use 32bit id's while all of my new
systems use 64bit ones. So int32 and int64 is one requirement which int
does not allow. On the SomeModel example the type of ['id'] is provided
by ADOdb and I can check if I need to handle the problem or not. If the
$row['id'] was correctly typed a lot of additional checks would be
eliminated, but the safe way of passing these id's IS as a string rather
than an integer.
--
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
[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-05-27
Results for project PHP master, build date 2016-05-27 06:28:00+03:00 commit: 42be298 previous commit:2ae21ab revision date: 2016-05-26 03:06:32+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.20% -0.32% 1.07% 6.96% :-| Drupal 7.36 cgi -T1 0.21% -0.02% 5.17% 4.46% :-| MediaWiki 1.23.9 cgi -T5000 0.18% 0.19% 1.08% 3.25% :-| bench.php cgi -T100 0.10% 0.17% 27.53% -0.64% :-| micro_bench.php cgi -T10 0.03% 0.28% 5.38% 2.05% :-| mandelbrot.php cgi -T100 0.01% 0.01% 31.94% 0.55% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-05-27/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 5/27/2016 11:53 AM, Lester Caine wrote:
> On 27/05/16 10:16, Rowan Collins wrote:
>> My comment was in reaction to Lester expressing surprise at destroying
>> and re-creating objects when new data is fetched. To be clear, I'm
>> talking about this:
>>
>> // Clear old data
>> $this->data = [];
>> // Re-populate from new DB result
>> foreach ( $db_resultset as $row ) {
>>$this->data[] = new SomeModel($row);
>> }
>>
>> The most useful typehints are inside the SomeModel class, not the
>> table-level wrapper. This is true even if they're just dumb structs, and
>> all the behaviour is at the table level, because it presumably has
>> basically one field: array $data.
>
> Probably the only difference here is that '$row' in my result set is not
> a dumb structure. It has type information, field lengths and potentially
> even value constraints. So my table level wrapper can potentially have
> the same typehints that you are then adding to SomeModel. All the
> properties of SomeModel already exist and if typed properties are
> working correctly in PHP $row can simply be accessed directly. This is
> why in my book all of the debate about 'attributes' and everything else
> is so tied up in the definition of making a simple variable a much more
> flexible generic object.
>
The type hints belong to SomeModel because you want to insert the data
into SomeModel and not into your repository (Table).
class Person {
public int $id;
public DateTimeImmutable $created;
public DateTimeImmutable $changed;
public string $name;
public DateTimeImmutable $birth;
public ?DateTimeImmutable $marriage;
public ?DateTimeImmutable $death;
public int $number_of_siblings = 0;
}
class SomeModels {
public function findAll() {
foreach ($db->select('SELECT * FROM `SomeModel`') as $row) {
$some_model = new SomeModel;
$some_model->id = $row['id'];
$some_model->created = new DateTimeImmutable($row['created']);
$some_model->changed = new DateTimeImmutable($row['changed']);
$some_model->name = $row['name'];
$some_model->birth = new DateTimeImmutable($row['birth']);
if (isset($row['marriage'])) {
$some_model->marriage = new DateTimeImmutable($row['marriage']);
}
if (isset($row['death'])) {
$some_model->death = new DateTimeImmutable($row['death']);
}
$some_model->number_of_siblings = $row['number_of_siblings'];
yield $some_model;
}
}
}
The Person object is however still behaviorless and anemic, throwing
type hints at public properties does not change that fact.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 5/27/2016 11:41 AM, Lester Caine wrote:
> Now I am confused, but it's probably because I'm looking at a simple
>
> $f->d = new DateTime( $initial );
>
> While you are looking at
>
> If ( isset($initial) )
> then $f->d = new DateTime( $initial );
> else $f->d = null;
>
> While the original code would have simply been
>
> $f->d = $initial;
>
> And in an ideal world, because $d has been typed as DateTime this would
> magically run 'new DateTime($initial)' which is where I am stumbling
> because *I* simply look at '?DateTime $d' as creating a DateTime object
> where in fact $d is a different type of object which will then hold the
> link to the real one. I am still looking for $d to be an object I can do
> all of the checks on that are provided by int or DateTime as appropriate
> ... the object needs to exist before the 'new' in order to know if you
> need the first or second type of $initial code ... or we make typed
> properties only work one way or the other?
>
PHP does not automagically instantiate the DateTime object for you, this
is still your responsibility. The type hint on the property only
restricts what you are allowed to assign to the property, nothing else.
It is true that PHP will coerce the value automatically if you are in
weak mode but this is only true for scalar values and nothing else. Also
note that you might not want that while working with a database because
PHP might destroy your UNSIGNED BIGINTs without you noticing.
class O {
public ?DateTime $d;
}
if (isset($row['d'])) {
$o->d = new DateTime($row['d']);
}
No need to assign null since it already is null by default and the
nullable hint will not result in any errors upon accessing it.
PS: The UNSIGNED BIGINT thing is one of the reasons why I want
intersection and union types so that we can do the following:
class O {
private int|string $id;
}
And leave it to a more intelligent system to determine whether this can
be safely converted to an int or not (e.g. MySQLi).
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27/05/16 10:16, Rowan Collins wrote:
> My comment was in reaction to Lester expressing surprise at destroying
> and re-creating objects when new data is fetched. To be clear, I'm
> talking about this:
>
> // Clear old data
> $this->data = [];
> // Re-populate from new DB result
> foreach ( $db_resultset as $row ) {
>$this->data[] = new SomeModel($row);
> }
>
> The most useful typehints are inside the SomeModel class, not the
> table-level wrapper. This is true even if they're just dumb structs, and
> all the behaviour is at the table level, because it presumably has
> basically one field: array $data.
Probably the only difference here is that '$row' in my result set is not
a dumb structure. It has type information, field lengths and potentially
even value constraints. So my table level wrapper can potentially have
the same typehints that you are then adding to SomeModel. All the
properties of SomeModel already exist and if typed properties are
working correctly in PHP $row can simply be accessed directly. This is
why in my book all of the debate about 'attributes' and everything else
is so tied up in the definition of making a simple variable a much more
flexible generic object.
--
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] [RFC][Vote] Typed Properties
On 27.05.2016 at 10:27, Rowan Collins wrote:
> On 26/05/2016 23:03, Lester Caine wrote:
>> On 26/05/16 22:38, Rowan Collins wrote:
> // accessing $me->marriage or $me->death returns NULL (because they
>> allow nulls) but raises E_NOTICE
BUT DateTime currently will not store 'null' - it returns 'now'
instead.
We end up having to store string or integer values because we can't
store a null date :(
>>>
>>> That's exactly what ?DateTime is for - "either DateTime or Null", just
>>> like in a database.
>>>
>>> In most type systems, there is no such thing as "a null date" - if it's
>>> null, it's not a date, it's a null value.
>>
>> The exact question here then is in relation to just how one uses
>> 'DateTime' in this situation? Or more accurately how one maintains the
>> 'or Null' state when the type does not allow null itself?
>
> I don't understand the question.
>
> class Foo { ?DateTime $d }
> $f = new Foo;
> $f->d = null;
> $f->d = new DateTime;
>
> It's either a DateTime, or it's null.
ACK. However, an alternative might be:
class NullDateTime extends DateTime {...}
class Foo { DateTime $d }
$f = new Foo;
$f->d = new NullDateTime;
$f->d = new DateTime;
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 27/05/16 09:27, Rowan Collins wrote:
> // accessing $me->marriage or $me->death returns NULL (because they
>> allow nulls) but raises E_NOTICE
BUT DateTime currently will not store 'null' - it returns 'now'
instead.
We end up having to store string or integer values because we can't
store a null date :(
>>>
>>> That's exactly what ?DateTime is for - "either DateTime or Null", just
>>> like in a database.
>>>
>>> In most type systems, there is no such thing as "a null date" - if it's
>>> null, it's not a date, it's a null value.
>>
>> The exact question here then is in relation to just how one uses
>> 'DateTime' in this situation? Or more accurately how one maintains the
>> 'or Null' state when the type does not allow null itself?
>
> I don't understand the question.
>
> class Foo { ?DateTime $d }
> $f = new Foo;
> $f->d = null;
> $f->d = new DateTime;
>
> It's either a DateTime, or it's null.
Now I am confused, but it's probably because I'm looking at a simple
$f->d = new DateTime( $initial );
While you are looking at
If ( isset($initial) )
then $f->d = new DateTime( $initial );
else $f->d = null;
While the original code would have simply been
$f->d = $initial;
And in an ideal world, because $d has been typed as DateTime this would
magically run 'new DateTime($initial)' which is where I am stumbling
because *I* simply look at '?DateTime $d' as creating a DateTime object
where in fact $d is a different type of object which will then hold the
link to the real one. I am still looking for $d to be an object I can do
all of the checks on that are provided by int or DateTime as appropriate
... the object needs to exist before the 'new' in order to know if you
need the first or second type of $initial code ... or we make typed
properties only work one way or the other?
--
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] [RFC][Vote] Typed Properties
On 27/05/2016 09:35, Tony Marston wrote:
"Lester Caine" wrote in message news:5747f02a.2010...@lsces.co.uk...
On 26/05/16 22:36, Rowan Collins wrote:
So every time I update the current tree because the client has selected
a different initial root I have to destroy perhaps 30 person objects
and
rebuild the whole lot again from scratch?
In a word, yes: if you have a different set of data, use a different set
of objects to hold it.
Objects are not memory slots to be re-filled, they represent a specific
instance of a thing.
I disagree completely. In a database system there is no rule that says
an object can only hold data from a single row otherwise Martin Fowler,
the author of PoEE, would not have patterns that hold data from several
rows. When I instantiate one of my table classes it is a valid but empty
object. There are two actions I can perform - inject data from the
client via the $_POST array, or tell it to retrieve data from the
database. This may involve just a single row, or multiple rows. When
reading from the database it may even result in zero rows.
That sounds like an object that represents the database table as an
entity, that's fine. What does it contain - how is the row data
represented? If it's just an array of arrays, then none of this
discussion is relevant; if it's an array of model objects, then those
objects must have properties, and those properties can be given type
annotations under this proposal.
My comment was in reaction to Lester expressing surprise at destroying
and re-creating objects when new data is fetched. To be clear, I'm
talking about this:
// Clear old data
$this->data = [];
// Re-populate from new DB result
foreach ( $db_resultset as $row ) {
$this->data[] = new SomeModel($row);
}
The most useful typehints are inside the SomeModel class, not the
table-level wrapper. This is true even if they're just dumb structs, and
all the behaviour is at the table level, because it presumably has
basically one field: array $data.
The alternative implied by Lester's comment seemed to be to somehow
re-use the entries in the data array by calling a magic "reset" method,
then populating them with new data. That's what I meant by "slots".
If I create a Person object representing "Lester Caine", it makes
absolutely no sense to go out of my way to recycle it and use it to
represent "Tony Marston"; that's a new value of the same type, so a new
instance of the same class.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 5/27/2016 10:35 AM, Tony Marston wrote: > I disagree completely. In a database system there is no rule that says > an object can only hold data from a single row otherwise Martin Fowler, > the author of PoEE, would not have patterns that hold data from several > rows. When I instantiate one of my table classes it is a valid but empty > object. There are two actions I can perform - inject data from the > client via the $_POST array, or tell it to retrieve data from the > database. This may involve just a single row, or multiple rows. When > reading from the database it may even result in zero rows. > Yes?!? That is how everybody does it. On 5/27/2016 10:35 AM, Tony Marston wrote: > You are trying to change the language to suit the way that you work > without considering the fact that your way is not the only way and this > change may not suit the way that others work. As far as I can see this > proposal not only does not solve a genuine problem, it adds levels of > complexity that will do nothing but increase the WTF! factor for untold > numbers of programmers who have been happily using the language for years. > Oh come on, this story again? Please, just keep on using PHP in the way you like it without making use of these new features. Nothing is changing and if all your problems are solved, good. And please, please don't start the PHP 5.2 was so much better discussion now and claiming that we all are incapable programmers. We know it by now. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
"Lester Caine" wrote in message news:5747f02a.2010...@lsces.co.uk... On 26/05/16 22:36, Rowan Collins wrote: So every time I update the current tree because the client has selected a different initial root I have to destroy perhaps 30 person objects and rebuild the whole lot again from scratch? In a word, yes: if you have a different set of data, use a different set of objects to hold it. Objects are not memory slots to be re-filled, they represent a specific instance of a thing. I disagree completely. In a database system there is no rule that says an object can only hold data from a single row otherwise Martin Fowler, the author of PoEE, would not have patterns that hold data from several rows. When I instantiate one of my table classes it is a valid but empty object. There are two actions I can perform - inject data from the client via the $_POST array, or tell it to retrieve data from the database. This may involve just a single row, or multiple rows. When reading from the database it may even result in zero rows. You are trying to change the language to suit the way that you work without considering the fact that your way is not the only way and this change may not suit the way that others work. As far as I can see this proposal not only does not solve a genuine problem, it adds levels of complexity that will do nothing but increase the WTF! factor for untold numbers of programmers who have been happily using the language for years. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.36 is available
Hello! The PHP development team announces the immediate availability of PHP 5.5.36. Several security related issues were fixed in this release. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.36 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/. The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.36 To verify the downloads, you can use the following information: php-5.5.36.tar.bz2 SHA256 hash: 2484edfaa3de606d74f927b55c5206f51b1ae24ea8e428aa9fc15474c7bb71bb PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABAgAGBQJXRXOMAAoJEP6FfZqQ2Q7BwtwIAISF1Wq6bgKZa/5nT/KBQGn7 /AYrxa0JtN7+5lh0JDjVzAaeRDlb0Kx+Xl1wafIKsKQ+5I7PRWUS1A8/XDHV+01f qOSOH4GEKI502CUlJDonQbLjhZtm1cs5BjP4lEB8ohPIHbgY2CNc+4xSwtTgHHcV opeU+ZEL0rqnkZhzP4LzyqQcOoQ8ObN4IMr84EoT8AXffPtr4N3oTdAE9/5qXbt5 kHAKPBUIWWcQ+6HDkGRK4KPuM2U0ItaGC5uJHqRQ1TabgvewbJBkj4TII4nlmHGH UPRxUSjjbDwCsCk/mboAKVtKoDdb5bzNGxHpsjIJBo7Y2tP62YLqsm4vLPLlQcQ= =1MhH -END PGP SIGNATURE- php-5.5.36.tar.gz SHA256 hash: ef829f9a9600a858e2363533b80c4e4773505bdc8ea3692d703fc893f267728a PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABAgAGBQJXRXOSAAoJEP6FfZqQ2Q7BGSIH/AsR9xPz2gofZp9U+soiaI4N ZMDLgJJM1YsygQLzX4AcVvrlabtbbRYDK3isOOm7NWCMZXCrXqXryBBZcUhhEJ9N W28XffhYGqQ+9KzsSsFrlsuBeKj/Hesll/zfumCicjHOL7fGepQ0cSgJjPAcu2KB PF2UN8aBf9ZiOR4FWkltYyx12XmnRyChvKHxpamwQ2Q5KOY0yix8MBXXz9cI4zym 3L+XqpEabHzF6ZKTJIvTmro40eSLF0Rny1FgOrBoTJaOwPpP6s0abaiLKmBuJ2vi SvQcInkuYcTba6DdXdGrfYzVtNO9MFOKEyaDgTquLRgPPNhCbRM0sA9VIkpyy2g= =SMFR -END PGP SIGNATURE- php-5.5.36.tar.xz SHA256 hash: e1bbe33d6b4da66b15c483131520a9fc505eeb6629fa70c5cfba79590a1d0801 PGP signature: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABAgAGBQJXRXOZAAoJEP6FfZqQ2Q7B1bAIAJujbDV3Ygky5LCPk7Ky2sep jYx8lcHfLhRog8esEuUapUeETUAS6eBIan6yp9IYVUTx3MZ4KUurCojGuevGI81f 2iUcfuaZAc9aixvq++vtVQ1ua7TeP/NV4RLUscqQWy//FQPiJBa78Db8MW1M4TT3 ape4w1JJritLJrtT3589clGmSny3aSU8U7XCZuC2SP5Q+TcN0flCjy06qWL/r2Lf TVQOluoR932cGJh5Hb6C94vvvkUOlTXR/LhhA/NbbcPMDEPaw+eL6UM5kRhGPs0f ExYmVUlYLBMuNsW2RWfNmk9cJdgCFvVqErXQe7pn4RNavYUyngyYCYPbvfpu7y4= =POxo -END PGP SIGNATURE- Julien Pauli & David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 5/26/2016 11:40 PM, Rowan Collins wrote: > On 26/05/2016 21:00, Fleshgrinder wrote: >> PS: This needs a cast unless some special driver options are active. >> >>$me->numSiblings = (int) $db_record['num_siblings']; > > ...or unless strict_types=0, in which case PHP will add an implicit cast > for you. :) > > Regards, > I need to get used to that nice new feature. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Vote] Typed Properties
On 26/05/2016 23:03, Lester Caine wrote:
On 26/05/16 22:38, Rowan Collins wrote:
// accessing $me->marriage or $me->death returns NULL (because they
allow nulls) but raises E_NOTICE
BUT DateTime currently will not store 'null' - it returns 'now' instead.
We end up having to store string or integer values because we can't
store a null date :(
That's exactly what ?DateTime is for - "either DateTime or Null", just
like in a database.
In most type systems, there is no such thing as "a null date" - if it's
null, it's not a date, it's a null value.
The exact question here then is in relation to just how one uses
'DateTime' in this situation? Or more accurately how one maintains the
'or Null' state when the type does not allow null itself?
I don't understand the question.
class Foo { ?DateTime $d }
$f = new Foo;
$f->d = null;
$f->d = new DateTime;
It's either a DateTime, or it's null.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
