Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5244 > unrolled thread
| Started by | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| First post | 2012-03-27 12:31 -0430 |
| Last post | 2012-04-12 07:45 -0400 |
| Articles | 20 on this page of 96 — 10 participants |
Back to article view | Back to comp.lang.php
out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 12:31 -0430
Re: out of sheer curiosity... "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-03-27 19:06 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 13:04 -0430
Re: out of sheer curiosity... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-28 21:12 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-28 20:23 -0430
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 10:00 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-29 05:23 -0430
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 11:46 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 14:02 +0200
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 14:33 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 14:37 +0100
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 15:59 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 17:58 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 09:39 -0400
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 16:21 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 18:09 +0100
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:07 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 23:43 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-30 04:52 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 16:11 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:01 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 19:29 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-08 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 17:15 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 00:39 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-09 00:59 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:28 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:24 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 11:29 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 08:27 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 15:20 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 12:03 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 20:04 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 14:37 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:17 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 10:05 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:28 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 18:54 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:10 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:23 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:30 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:43 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:08 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-11 10:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 07:58 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 16:04 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:10 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:18 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-10 18:20 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:31 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:20 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:57 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:50 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 17:41 +0100
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:25 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:16 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:04 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:37 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:19 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:23 -0400
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 11:50 -0700
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 23:03 +0200
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 15:27 -0700
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:25 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:48 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:06 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 07:52 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:20 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 12:03 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:28 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 00:13 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:53 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:30 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:22 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:43 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:15 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:09 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:17 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:25 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:21 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:34 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 01:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:54 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:10 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:31 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:02 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 12:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 07:45 -0400
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-10 20:23 +0200 |
| Message-ID | <9ujc45Fae4U1@mid.uni-berlin.de> |
| In reply to | #5435 |
Am 10.04.2012 20:10, schrieb Thomas Mlynarczyk: > M. Strobel schrieb: > >> In your example above the problem is if you need to do more init work on the data you >> need an extra method call. With the implemented solution you just have to know that >> the constructor is called after setting the vars, and you can detect it, testing the >> unique key or so, but need not do so if you don't care. > > Hm, yes, but it still feels wrong to me that the constructor call is not the very > first thing happening to the object. > >> Are you aware of the fact that __set() is not called for defined variables? > > Yes, it's not called for defined /public/ variables. But you rarely have public > variables in your classes. > >> The rationale (or use case) of __set_state() is a mystery to me. > > Well, it's used by var_export() when exporting objects. For example, > > $a = (object) array( 'foo' => 'bar' ); > > will be exported as > > stdClass::__set_state(array( 'foo' => 'bar', )) > > even though PHP should know very well that stdClass has no such static method. > Consequently, writing the output of var_export() to a file and then re-including it, > will fail, thus defeating the whole purpose of var_export(). Test code: > > $a = (object) array( 'foo' => 'bar' ); > $s = var_export( $a, true ); > var_dump( $a, $s ); > $b = eval( "return $s;" ); > var_dump( $b ); > > But __set_state() seems to be some sort of "factory method" which is called as a > static method on a class, passing an array with "state information" and the method is > supposed to create an object, set its state using the passed array and return the new > object. And that would be exactly what PDO needs to set the data of the row object: > no need to define an array with extra constructor arguments -- just tell PDO the > class name and make sure the class has a __set_state() method defined. But alas, it's > not what PDO does. Still a mystery, why should I want to do var_export()? And your code gives a fatal error. <shrug> but it's late here, getting dark /Str.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 23:17 +0200 |
| Message-ID | <jm280r$rte$1@news.albasani.net> |
| In reply to | #5437 |
M. Strobel schrieb: > Still a mystery, why should I want to do var_export()? I recently had a use for it: Reading some data from an external source and creating a PHP file like this: <?php return array( ... lots ... of ... data ... ); ?> so I could later retrieve the data with $data = include $datafile; I thought var_export() would be the simplest way to do this. But the array contained stdclass objects and var_export() fails on them :-( (I ended up running str_replace() over the string returned by var_export() to change the stdClass::__set_state to (object). > And your code gives a fatal error. Exactly. Because var_export(), although supposed to produce valid PHP code, fails to do so. > <shrug> but it's late here, getting dark Yeah, here too. Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 17:11 -0400 |
| Message-ID | <jm27ln$1fv$2@dont-email.me> |
| In reply to | #5435 |
On 4/10/2012 2:10 PM, Thomas Mlynarczyk wrote: > M. Strobel schrieb: > >> In your example above the problem is if you need to do more init work >> on the data you >> need an extra method call. With the implemented solution you just have >> to know that >> the constructor is called after setting the vars, and you can detect >> it, testing the >> unique key or so, but need not do so if you don't care. > > Hm, yes, but it still feels wrong to me that the constructor call is not > the very first thing happening to the object. > I agree that it "feels wrong", but is perfectly valid. There are other examples - for instance in Java and C++, the vase class constructor is called before the derived class constructor. >> Are you aware of the fact that __set() is not called for defined >> variables? > > Yes, it's not called for defined /public/ variables. But you rarely have > public variables in your classes. > >> The rationale (or use case) of __set_state() is a mystery to me. > > Well, it's used by var_export() when exporting objects. For example, > > $a = (object) array( 'foo' => 'bar' ); > > will be exported as > > stdClass::__set_state(array( 'foo' => 'bar', )) > > even though PHP should know very well that stdClass has no such static > method. Consequently, writing the output of var_export() to a file and > then re-including it, will fail, thus defeating the whole purpose of > var_export(). Test code: > > $a = (object) array( 'foo' => 'bar' ); > $s = var_export( $a, true ); > var_dump( $a, $s ); > $b = eval( "return $s;" ); > var_dump( $b ); > > But __set_state() seems to be some sort of "factory method" which is > called as a static method on a class, passing an array with "state > information" and the method is supposed to create an object, set its > state using the passed array and return the new object. And that would > be exactly what PDO needs to set the data of the row object: no need to > define an array with extra constructor arguments -- just tell PDO the > class name and make sure the class has a __set_state() method defined. > But alas, it's not what PDO does. > > Greetings, > Thomas > Possibly for future use? Most of PDO was written before __set_state() was added, so maybe newer versions will use it. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 23:30 +0200 |
| Message-ID | <jm28q7$toh$1@news.albasani.net> |
| In reply to | #5440 |
Jerry Stuckle schrieb: [setting data on object before constructor is called] > I agree that it "feels wrong", but is perfectly valid. There are other > examples - for instance in Java and C++, the vase class constructor is > called before the derived class constructor. The base constructor, okay, yes. But setting data on the object, possibly invoking __set() which, in turn might (need to) do things requiring prior object initialization? [PDO does not use __set_state()] > Possibly for future use? Most of PDO was written before __set_state() > was added, so maybe newer versions will use it. Hm, maybe. Meanwhile I think I can live with the fact that the constructor is called after setting the data. It's just something one must know and remember... Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 19:43 -0400 |
| Message-ID | <jm2gij$ncu$1@dont-email.me> |
| In reply to | #5446 |
On 4/10/2012 5:30 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > > [setting data on object before constructor is called] >> I agree that it "feels wrong", but is perfectly valid. There are other >> examples - for instance in Java and C++, the vase class constructor is >> called before the derived class constructor. > > The base constructor, okay, yes. But setting data on the object, > possibly invoking __set() which, in turn might (need to) do things > requiring prior object initialization? > That is correct. That way __set() does not need to check to see if the object has been initialized already. > [PDO does not use __set_state()] >> Possibly for future use? Most of PDO was written before __set_state() >> was added, so maybe newer versions will use it. > > Hm, maybe. Meanwhile I think I can live with the fact that the > constructor is called after setting the data. It's just something one > must know and remember... > > Greetings, > Thomas > -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 17:08 -0400 |
| Message-ID | <jm27fn$1fv$1@dont-email.me> |
| In reply to | #5429 |
On 4/10/2012 12:54 PM, M. Strobel wrote:
> Am 10.04.2012 13:28, schrieb Thomas Mlynarczyk:
>> M. Strobel schrieb:
>>
>>> Now PDO comes in. When getting a query result as object your constructor is called
>>> *after* the properties are set.
>>
>> Really? That would be very strange indeed.
>>
>> [minutes later]
>> I just tested it and it is indeed as you state. Thanks for pointing that out -- is
>> this documented?
>>
>>> I found it quite annoying to have an exception from the rule. But thinking more about
>>> it I found out they had a choice of either calling __construct() after setting the
>>> data, or to define another magic method like __pdoconstruct() to give the programmer
>>> a chance to adapt the init process to the data.
>>
>> I don't quite follow you here. Why did they have no choice? I don't see why they
>> (c|sh)ould not call the constructor before setting the data. After all, that would be
>> the only logical and sensible thing to do. If you would do this "manually", you would
>> do it like this:
>>
>> foreach ( $rows as $row ):
>> $item = new MyClass( 'foo', 'bar' );
>> foreach ( $row as $name => $value ):
>> $item->$name = $value;
>> endforeach;
>> $result[] = $item;
>> endforeach;
>>
>
> Meanwhile I have more ideas about choices.
>
> The correct way would have been to pass the row to the constructor. This would have
> required a matching parameter definition for the constructor, and the corresponding
> code, quite error prone.
>
Yes, that's how C++ does it, for instance (overloaded functions). It
would be harder in PHP, but it could be done.
> In your example above the problem is if you need to do more init work on the data you
> need an extra method call. With the implemented solution you just have to know that
> the constructor is called after setting the vars, and you can detect it, testing the
> unique key or so, but need not do so if you don't care.
>
>> And I guess it would be impossible to do it the other way round (first setting data,
>> then calling constructor). The setting of the data can be controlled using the magic
>> __set() method, so there's no need for __pdoconstruct(), if I understand you correctly.
>
> Are you aware of the fact that __set() is not called for defined variables? Test:
> <?php
> class Upset {
> public $var1;
> function __set($n, $v) {
> echo "setting variable $n to: $v\n";
> $this->$n = $v;
> }
> }
> $c = new Upset();
> $c->var1 = 'Try this';
> $c->another = ' and this ';
> echo "Values are now $c->var1 $c->another\n";
> ------------------- Result: ----
> setting variable another to: and this
> Values are now Try this and this
>
>
That is correct - you are directly setting a public variable. Now make
$var1 private and see what happens.
>> A more intelligent approach may have been to define an interface which any "result
>> row" class must implement and which defines a method like setData( $rowAsArray ). Or
>> maybe even better: make use of the existing __set_state() magic method.
>
> The rationale (or use case) of __set_state() is a mystery to me.
>
> Maybe they did not want to ask too much from PHP programmers...
>
> /Str.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-11 10:40 +0200 |
| Message-ID | <9ukubqFtk8U1@mid.uni-berlin.de> |
| In reply to | #5439 |
Am 10.04.2012 23:08, schrieb Jerry Stuckle:
> On 4/10/2012 12:54 PM, M. Strobel wrote:
>> Am 10.04.2012 13:28, schrieb Thomas Mlynarczyk:
>>> M. Strobel schrieb:
>>>
>>>> Now PDO comes in. When getting a query result as object your constructor is called
>>>> *after* the properties are set.
>>>
>>> Really? That would be very strange indeed.
>>>
>>> [minutes later]
>>> I just tested it and it is indeed as you state. Thanks for pointing that out -- is
>>> this documented?
>>>
>>>> I found it quite annoying to have an exception from the rule. But thinking more
>>>> about
>>>> it I found out they had a choice of either calling __construct() after setting the
>>>> data, or to define another magic method like __pdoconstruct() to give the programmer
>>>> a chance to adapt the init process to the data.
>>>
>>> I don't quite follow you here. Why did they have no choice? I don't see why they
>>> (c|sh)ould not call the constructor before setting the data. After all, that would be
>>> the only logical and sensible thing to do. If you would do this "manually", you would
>>> do it like this:
>>>
>>> foreach ( $rows as $row ):
>>> $item = new MyClass( 'foo', 'bar' );
>>> foreach ( $row as $name => $value ):
>>> $item->$name = $value;
>>> endforeach;
>>> $result[] = $item;
>>> endforeach;
>>>
>>
>> Meanwhile I have more ideas about choices.
>>
>> The correct way would have been to pass the row to the constructor. This would have
>> required a matching parameter definition for the constructor, and the corresponding
>> code, quite error prone.
>>
>
> Yes, that's how C++ does it, for instance (overloaded functions). It would be harder
> in PHP, but it could be done.
>
>> In your example above the problem is if you need to do more init work on the data you
>> need an extra method call. With the implemented solution you just have to know that
>> the constructor is called after setting the vars, and you can detect it, testing the
>> unique key or so, but need not do so if you don't care.
>>
>>> And I guess it would be impossible to do it the other way round (first setting data,
>>> then calling constructor). The setting of the data can be controlled using the magic
>>> __set() method, so there's no need for __pdoconstruct(), if I understand you
>>> correctly.
>>
>> Are you aware of the fact that __set() is not called for defined variables? Test:
>> <?php
>> class Upset {
>> public $var1;
>> function __set($n, $v) {
>> echo "setting variable $n to: $v\n";
>> $this->$n = $v;
>> }
>> }
>> $c = new Upset();
>> $c->var1 = 'Try this';
>> $c->another = ' and this ';
>> echo "Values are now $c->var1 $c->another\n";
>> ------------------- Result: ----
>> setting variable another to: and this
>> Values are now Try this and this
>>
>>
>
> That is correct - you are directly setting a public variable. Now make $var1 private
> and see what happens.
Let's see, this gives a good reference:
<?php
class Upset {
public $pubvar;
private $privvar;
function __set($n, $v) {
echo "setting variable $n to: $v\n";
$this->$n = $v;
}
function __get($n) {
echo "getting variable $n\n";
if (isset($this->$n)) return $this->$n;
else return null;
}
}
$c = new Upset();
$c->pubvar = 'Try this';
$c->privvar = ' private ';
$c->adhoc = ' and this ';
echo "Values are now $c->pubvar $c->privvar $c->adhoc\n";
------------------- Result is: ----
setting variable privvar to: private
setting variable adhoc to: and this
getting variable privvar
Values are now Try this private and this
/Str.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 07:58 -0400 |
| Message-ID | <jm178k$l6m$1@dont-email.me> |
| In reply to | #5397 |
On 4/10/2012 4:05 AM, M. Strobel wrote: > Am 10.04.2012 02:17, schrieb Jerry Stuckle: >> On 4/9/2012 4:50 PM, Thomas Mlynarczyk wrote: >> >>> And this initialization is not needed (or might even prove harmful) when >>> the object is copied rather than created from scratch, because in that >>> case the initialization was already done on the original object and the >>> copy was thus created from an already initialized object and it will >>> "inherit" the initialized state. Instead, there are __clone() and >>> __wakeup() which replace __construct() and can do different >>> initialization tasks depending on how the object was created. >>> >> >> Initialization is NEVER harmful if it is done properly. That's the whole purpose of >> initialization!. wakeup() is NOT a constructor - any more than sleep() is a destructor. > > 'if done properly' fits everywhere and is just too true to be useful. > > In PHP the constructor is called on an object without state (data). So you would > normally in the constructor just write out our data, like setting a counter to zero > or a date to the current time. This would be harmful to do on a 'not new' object. > But you are creating an object without state. When the object state is serialized, by definition it is no longer an object because it has no behavior. You need to understand what an object is according to Object Oriented principles. An object has both state and behavior - it has properties and methods which act on those properties. The latter is not possible in a serialized object. And yes, you call the constructor when creating ANY object, even if the object is being created from existing data. Your understanding of object oriented principles shows you have never read much about it nor have you use a true OO language. > Now PDO comes in. When getting a query result as object your constructor is called > *after* the properties are set. > And exactly how is that? > I found it quite annoying to have an exception from the rule. But thinking more about > it I found out they had a choice of either calling __construct() after setting the > data, or to define another magic method like __pdoconstruct() to give the programmer > a chance to adapt the init process to the data. > Another problem - you should NEVER call the constructor. True OO languages do that for you as part of creating a new object. And you never have to call the parent constructor, either. PHP is sadly lacking as an OO language, that's for sure. > Bottom line is: you just have to know your programming language very well, and test > everything thoroughly. Knowledge of OO principles help a lot, but are often too > general to be operational (like for example the "Open Close Principle"). > > /Str. Bottom line is - PHP's OO is sadly lacking, as it is in so many areas. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-04-10 16:04 +0100 |
| Message-ID | <timstreater-BE3CEA.16042110042012@news.individual.net> |
| In reply to | #5404 |
In article <jm178k$l6m$1@dont-email.me>, Jerry Stuckle <jstucklex@attglobal.net> wrote: > Another problem - you should NEVER call the constructor. True OO > languages do that for you as part of creating a new object. And you > never have to call the parent constructor, either. AIUI, it does call the constructor - but not the parent constructor, although you could do that yourself in the constructor if you so wished. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 12:10 -0400 |
| Message-ID | <jm1m10$e7i$2@dont-email.me> |
| In reply to | #5412 |
On 4/10/2012 11:04 AM, Tim Streater wrote: > In article <jm178k$l6m$1@dont-email.me>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: > >> Another problem - you should NEVER call the constructor. True OO >> languages do that for you as part of creating a new object. And you >> never have to call the parent constructor, either. > > AIUI, it does call the constructor - but not the parent constructor, > although you could do that yourself in the constructor if you so wished. > Yes, but the parent is also an object, and the system should call the constructor for you. Otherwise you may have an uninitialized parent. That's how it works in OO languages - and it works quite well. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 18:18 +0200 |
| Message-ID | <jm1mhc$iho$2@news.albasani.net> |
| In reply to | #5420 |
Jerry Stuckle schrieb: > Yes, but the parent is also an object, and the system should call the > constructor for you. Otherwise you may have an uninitialized parent. No. When you instantiate the child, then the child is an object, but there is no instance of a "parent object". Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-04-10 18:20 +0100 |
| Message-ID | <jm1q4q$qs6$3@news.albasani.net> |
| In reply to | #5423 |
Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> Yes, but the parent is also an object, and the system should call the >> constructor for you. Otherwise you may have an uninitialized parent. > > No. When you instantiate the child, then the child is an object, but > there is no instance of a "parent object". > Parthenogenesis? ;-) > Greetings, > Thomas > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-04-10 19:31 +0200 |
| Message-ID | <9uj92qFj2jU1@mid.uni-berlin.de> |
| In reply to | #5433 |
Am 10.04.2012 19:20, schrieb The Natural Philosopher: > Thomas Mlynarczyk wrote: >> Jerry Stuckle schrieb: >> >>> Yes, but the parent is also an object, and the system should call the constructor >>> for you. Otherwise you may have an uninitialized parent. >> >> No. When you instantiate the child, then the child is an object, but there is no >> instance of a "parent object". >> > > Parthenogenesis? > No, parent-child-identity. The concept of eternal live. /Str.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 17:20 -0400 |
| Message-ID | <jm287o$686$1@dont-email.me> |
| In reply to | #5423 |
On 4/10/2012 12:18 PM, Thomas Mlynarczyk wrote: > Jerry Stuckle schrieb: > >> Yes, but the parent is also an object, and the system should call the >> constructor for you. Otherwise you may have an uninitialized parent. > > No. When you instantiate the child, then the child is an object, but > there is no instance of a "parent object". > > Greetings, > Thomas > Although not a separate entity, the parent is still considered an object. You can, for instance, call public methods which are defined in the parent but not the child. Those methods will operate on the parent, just as if you had a parent object. So basically what you have is "dual identity" - the object is considered both a parent and a child, depending on the context. And the parent's constructor is responsible for constructing the parent object; the child is only responsible for constructing the child object. This is actually quite important. This allows you to change the implementation (code and private variables) of the parent object without affecting any child objects. Remember that the child object always has a parent object; the opposite is not necessarily true, and the parent object should not depend on anything in the child (abstract classes are a special case - but even then the parent should never depend on anything in the child). -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 23:57 +0200 |
| Message-ID | <jm2abu$1cg$1@news.albasani.net> |
| In reply to | #5442 |
Jerry Stuckle schrieb:
> Although not a separate entity, the parent is still considered an
> object. You can, for instance, call public methods which are defined in
> the parent but not the child. Those methods will operate on the parent,
> just as if you had a parent object.
Hm. Makes sense.
> So basically what you have is "dual identity" - the object is considered
> both a parent and a child, depending on the context.
Yes, thinking more about it, it becomes a bit clearer. A child is also
an instance of all of its parent classes.
> And the parent's constructor is responsible for constructing the parent
> object; the child is only responsible for constructing the child object.
So the parent has a "private part" and the child has a "private part",
but they might also have a "shared part" ("protected") and there both
child and parent are responsible.
If the child overwrites a parent method, this will also affect the
parent since $this->method() will refer to the child's method, even if
called from a method defined in the parent class.
> This is actually quite important. This allows you to change the
> implementation (code and private variables) of the parent object without
> affecting any child objects.
So if there is no "shared part" between parent and child, does that mean
the child class should not have been derived from the parent in the
first place? Like "nothing to share -- nothing to inherit"?
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 19:50 -0400 |
| Message-ID | <jm2h0o$q43$1@dont-email.me> |
| In reply to | #5448 |
On 4/10/2012 5:57 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> Although not a separate entity, the parent is still considered an
>> object. You can, for instance, call public methods which are defined
>> in the parent but not the child. Those methods will operate on the
>> parent, just as if you had a parent object.
>
> Hm. Makes sense.
>
>> So basically what you have is "dual identity" - the object is
>> considered both a parent and a child, depending on the context.
>
> Yes, thinking more about it, it becomes a bit clearer. A child is also
> an instance of all of its parent classes.
>
>> And the parent's constructor is responsible for constructing the
>> parent object; the child is only responsible for constructing the
>> child object.
>
> So the parent has a "private part" and the child has a "private part",
> but they might also have a "shared part" ("protected") and there both
> child and parent are responsible.
>
Generally, protected variables are frowned upon. Remember - ANYTHING
exposed outside the class can never be changed once the class is put
into production. You don't know how it will affect other classes.
Also, protected member variables leave the possibility open that a child
class can place an invalid value in it, potentially corrupting the base
class.
Private members (both variables and methods) and the code in the methods
are never available outside the class. As long as the result is the
same, how the class is implemented is immaterial.
This can be very handy when prototyping, for instance. You can create a
"quick and dirty" implementation of the class and use it. Later you can
come back and clean it up, making it more efficient, etc.
> If the child overwrites a parent method, this will also affect the
> parent since $this->method() will refer to the child's method, even if
> called from a method defined in the parent class.
>
Nope. If it's important to the parent, then the child's method should
call the parent's method. But many times I've had methods in the child
class which don't call the parent method for various reasons.
>> This is actually quite important. This allows you to change the
>> implementation (code and private variables) of the parent object
>> without affecting any child objects.
>
> So if there is no "shared part" between parent and child, does that mean
> the child class should not have been derived from the parent in the
> first place? Like "nothing to share -- nothing to inherit"?
>
> Greetings,
> Thomas
>
There is always something to inherit - the public interface. But the
child class should always be a more specific instance of the parent
class. For instance, Person->Employee would be ok, because Employee is
a more specific instance of Person. However, Employee->Contractor would
not - a contractor is not an employee.
The Person class can have private members for name, address, etc.
Employee would have additional fields such as start_date, employee_id, etc.
And from Employee you could derive Manager.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-04-10 17:41 +0100 |
| Message-ID | <timstreater-B0F20F.17414010042012@news.individual.net> |
| In reply to | #5420 |
In article <jm1m10$e7i$2@dont-email.me>, Jerry Stuckle <jstucklex@attglobal.net> wrote: > On 4/10/2012 11:04 AM, Tim Streater wrote: > > In article <jm178k$l6m$1@dont-email.me>, > > Jerry Stuckle <jstucklex@attglobal.net> wrote: > > > >> Another problem - you should NEVER call the constructor. True OO > >> languages do that for you as part of creating a new object. And you > >> never have to call the parent constructor, either. > > > > AIUI, it does call the constructor - but not the parent constructor, > > although you could do that yourself in the constructor if you so wished. > Yes, but the parent is also an object, and the system should call the > constructor for you. Otherwise you may have an uninitialized parent. > > That's how it works in OO languages - and it works quite well. OK. This essentially above my pay grade (but, then, everything is as I'm retired :-) -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 17:25 +0200 |
| Message-ID | <jm1jcq$bst$1@news.albasani.net> |
| In reply to | #5404 |
Jerry Stuckle schrieb:
> But you are creating an object without state. When the object state is
> serialized, by definition it is no longer an object because it has no
> behavior.
class Foo { public $bar = 42; }
$foo = new Foo;
Now, $foo has state but no behaviour. According to you, $foo is not an
object?
Look, we are all aware that a serialized object is just a dead sequence
of characters representing the state of the object and that it can be
used -- together with the class definition -- to reconstruct an object
which, to the script, will appear to be identical to the original one.
Now if we just concentrate to what's essential for our script, we can
say that we "store away" the object in that sequence of characters and
retrieve it back from there. Simplification for convenience's sake.
>> Now PDO comes in. When getting a query result as object your
>> constructor is called
>> *after* the properties are set.
>
> And exactly how is that?
Just as he said. Didn't want to believe it. Wrote a test script. It's
true. When __construct() is called, the data is already set.
> Another problem - you should NEVER call the constructor.
But he doesn't! What makes you think he called the constructor?
[with true OO languages...]
> you never have to call the parent constructor, either.
I think that's a bad idea. First: there may be no need to call the
parent constructor (the child constructor may completely replace it).
Second: When should the parent constructor be called? Before? After? Or
maybe somewhere within the child constructor? It's much better and more
flexible when the child has to call the parent constructor explicitly.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-04-10 12:16 -0400 |
| Message-ID | <jm1mdq$hqm$1@dont-email.me> |
| In reply to | #5414 |
On 4/10/2012 11:25 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> But you are creating an object without state. When the object state is
>> serialized, by definition it is no longer an object because it has no
>> behavior.
>
> class Foo { public $bar = 42; }
> $foo = new Foo;
> Now, $foo has state but no behaviour. According to you, $foo is not an
> object?
>
If you created a constructor for it, the constructor will be called. If
you don't create your own, a dummy constructor is called, which does
nothing except satisfy the requirement a constructor is called.
> Look, we are all aware that a serialized object is just a dead sequence
> of characters representing the state of the object and that it can be
> used -- together with the class definition -- to reconstruct an object
> which, to the script, will appear to be identical to the original one.
> Now if we just concentrate to what's essential for our script, we can
> say that we "store away" the object in that sequence of characters and
> retrieve it back from there. Simplification for convenience's sake.
>
It is not an object once it has been serialized. To use it, you must
create an object with the deserialized data - which means a constructor
must be called according to OO principles.
>>> Now PDO comes in. When getting a query result as object your
>>> constructor is called
>>> *after* the properties are set.
>>
>> And exactly how is that?
>
> Just as he said. Didn't want to believe it. Wrote a test script. It's
> true. When __construct() is called, the data is already set.
>
OK, not a problem. It doesn't say the constructor must be called after
some properties are set. Just the constructor must be called when the
object is being created and before it is first used.
>> Another problem - you should NEVER call the constructor.
>
> But he doesn't! What makes you think he called the constructor?
>
You have to call a parent's constructor when constructing a child.
> [with true OO languages...]
>> you never have to call the parent constructor, either.
>
> I think that's a bad idea. First: there may be no need to call the
> parent constructor (the child constructor may completely replace it).
> Second: When should the parent constructor be called? Before? After? Or
> maybe somewhere within the child constructor? It's much better and more
> flexible when the child has to call the parent constructor explicitly.
>
> Greetings,
> Thomas
>
No, the child constructor NEVER replaces the parent constructor. The
child's constructor is responsible for creating the child object. The
parent's constructor is responsible for creating the parent object.
For instance, the child can never access private members of the parent
(encapsulation - one of the four attributes of OO languages).
And if the child needs to change the parent like that, you probably have
an invalid design. The child should always extend the parent - not
replace it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> |
|---|---|
| Date | 2012-04-10 13:44 +0200 |
| Message-ID | <jm16es$gii$1@news.albasani.net> |
| In reply to | #5393 |
Jerry Stuckle schrieb: > In OO terminology, the correct term is "constructor". I'm not familiar > with Python, so I can't say what Python calls it. But the name is not > as important as the job. True. But one still has to keep in mind that the constructor is not constructing the object, but initializing it. > Initialization is NEVER harmful if it is done properly. That's the > whole purpose of initialization!. wakeup() is NOT a constructor - any > more than sleep() is a destructor. You would have to take extra measures to prevent re-initializing an already initialized object. Your constructor would need to detect what type of initialization is required (freshly created by `new`, cloned or unserialized). While certainly possible, this would be cumbersome. Different magic initializers are clearly the better way to go. > wakeup() is not a constructor. If you consider it a constructor, then > you must also consider sleep() to be a destructor - in which case it > would be illegal to call the destructor after calling sleep(). __wakeup() is an initializer, just like __construct() and __clone(). And __sleep() is still not a destructor -- see my earlier post. > It is the opposite of wakeup() - just like __construct() is the opposite > of __destruct(). You can't have it both ways. I think we do agree that __sleep() is not a destructor. And maybe we can agree that __construct(), __clone() and __wakeup() all perform initialization tasks and thus could be all called "initializers". Greetings, Thomas -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison! (Coluche)
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web