Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14530 > unrolled thread

OO PHP result of new if a constructor fails

Back to article view | Back to comp.lang.php

Contents

  OO PHP result of new if a constructor fails "James Harris" <james.harris.1@gmail.com> - 2014-11-11 15:13 +0000
    Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-11 10:20 -0500
      Re: OO PHP result of new if a constructor fails "James Harris" <james.harris.1@gmail.com> - 2014-11-11 15:56 +0000
        Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-11 11:03 -0500
          Re: OO PHP result of new if a constructor fails "James Harris" <james.harris.1@gmail.com> - 2014-11-11 16:27 +0000
            Re: OO PHP result of new if a constructor fails Matthew Carter <m@ahungry.com> - 2014-11-11 12:01 -0500
              Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-11 12:56 -0500
            Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-11 12:52 -0500
    Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-11 18:12 +0100
    Re: OO PHP result of new if a constructor fails Richard Damon <Richard@Damon-Family.org> - 2014-11-11 13:03 -0500
    Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-11 23:54 +0100
      Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-12 03:00 +0100
        Re: OO PHP result of new if a constructor fails Matthew Carter <m@ahungry.com> - 2014-11-11 22:25 -0500
          Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-11 22:36 -0500
            Re: OO PHP result of new if a constructor fails Matthew Carter <m@ahungry.com> - 2014-11-12 01:30 -0500
              Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-12 07:08 -0500
              Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-12 13:30 +0100
                Re: OO PHP result of new if a constructor fails Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-12 13:52 +0000
                  Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 00:46 +0100
                    Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-12 22:28 -0500
        Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-12 21:30 +0100
          Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 01:15 +0100
            Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 04:09 +0100
              Re: OO PHP result of new if a constructor fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2014-11-13 07:42 +0000
              Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 14:11 +0100
                Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 21:40 +0100
                  Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-14 13:49 +0100
                    Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-14 23:25 +0100
            Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-12 22:29 -0500
              Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 21:45 +0100
                Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-13 15:56 -0500
                  Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 22:09 +0100
                    Re: OO PHP result of new if a constructor fails Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-13 21:03 -0500
                Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 22:47 +0100
                  Re: OO PHP result of new if a constructor fails Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 22:59 +0100
                    Re: OO PHP result of new if a constructor fails "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-18 19:02 +0100

Page 1 of 2  [1] 2  Next page →

#14530 — OO PHP result of new if a constructor fails

From what I've found I understand that PHP constructors cannot return 
anything and that leads on to a specific query: if a piece of PHP code uses 
new as in

  $a = new b();

as long as no exception is thrown is $a guaranteed to hold something after 
the statement? Is it guaranteed to hold an object of the designated type? 
What happens if b's constructor "fails" in some way for various meanings of 
failure other than throwing exceptions?

To put it another way, after the above instantiation statement which of 
these would be guaranteed to be true?
1) $a WILL contain a b object
2) $a could be NULL
3) $a might not exist (if it did not before the statement)

Or does the answer depend on the specific class or on the version of PHP?

Sorry that's a lot of questions. Just trying to make the query clear.

James

[toc] | [next] | [standalone]

#14531

On 11/11/2014 10:13 AM, James Harris wrote:
> From what I've found I understand that PHP constructors cannot return 
> anything and that leads on to a specific query: if a piece of PHP code uses 
> new as in
> 
>   $a = new b();
> 
> as long as no exception is thrown is $a guaranteed to hold something after 
> the statement? Is it guaranteed to hold an object of the designated type? 
> What happens if b's constructor "fails" in some way for various meanings of 
> failure other than throwing exceptions?
> 
> To put it another way, after the above instantiation statement which of 
> these would be guaranteed to be true?
> 1) $a WILL contain a b object
> 2) $a could be NULL
> 3) $a might not exist (if it did not before the statement)
> 
> Or does the answer depend on the specific class or on the version of PHP?
> 
> Sorry that's a lot of questions. Just trying to make the query clear.
> 
> James
> 
> 

The first question is - how did the constructor "fail"?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14532

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:m3t9et$t8s$1@dont-email.me...
> On 11/11/2014 10:13 AM, James Harris wrote:
>> From what I've found I understand that PHP constructors cannot return
>> anything and that leads on to a specific query: if a piece of PHP code 
>> uses
>> new as in
>>
>>   $a = new b();
>>
>> as long as no exception is thrown is $a guaranteed to hold something 
>> after
>> the statement? Is it guaranteed to hold an object of the designated type?
>> What happens if b's constructor "fails" in some way for various meanings 
>> of
>> failure other than throwing exceptions?
>>
>> To put it another way, after the above instantiation statement which of
>> these would be guaranteed to be true?
>> 1) $a WILL contain a b object
>> 2) $a could be NULL
>> 3) $a might not exist (if it did not before the statement)
>>
>> Or does the answer depend on the specific class or on the version of PHP?
>>
>> Sorry that's a lot of questions. Just trying to make the query clear.

...

> The first question is - how did the constructor "fail"?

Any way you can imagine without throwing an exception. I was hoping there 
was a universal rule that could apply to all of PHP OO programming.

If you mean that a constructor cannot fail I don't agree. If you mean there 
are limited ways that a constructor can fail then I agree but for all and 
any of those means of failure what would be the effect on the object so 
constructed?

If you want a specific, here's one.

  $db1 = new mysqli(...);
  if ($db1->connect_errno...)

The instantiation can fail in a number of ways. Which of the scenarios 
labelled 1 to 3, above, will always be true when we reach the test 
statement? The test will baulk on two of them.

James

[toc] | [prev] | [next] | [standalone]

#14533

On 11/11/2014 10:56 AM, James Harris wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:m3t9et$t8s$1@dont-email.me...
>> On 11/11/2014 10:13 AM, James Harris wrote:
>>> From what I've found I understand that PHP constructors cannot return
>>> anything and that leads on to a specific query: if a piece of PHP code 
>>> uses
>>> new as in
>>>
>>>   $a = new b();
>>>
>>> as long as no exception is thrown is $a guaranteed to hold something 
>>> after
>>> the statement? Is it guaranteed to hold an object of the designated type?
>>> What happens if b's constructor "fails" in some way for various meanings 
>>> of
>>> failure other than throwing exceptions?
>>>
>>> To put it another way, after the above instantiation statement which of
>>> these would be guaranteed to be true?
>>> 1) $a WILL contain a b object
>>> 2) $a could be NULL
>>> 3) $a might not exist (if it did not before the statement)
>>>
>>> Or does the answer depend on the specific class or on the version of PHP?
>>>
>>> Sorry that's a lot of questions. Just trying to make the query clear.
> 
> ...
> 
>> The first question is - how did the constructor "fail"?
> 
> Any way you can imagine without throwing an exception. I was hoping there 
> was a universal rule that could apply to all of PHP OO programming.
>

No, specifically - how can it fail?

> If you mean that a constructor cannot fail I don't agree. If you mean there 
> are limited ways that a constructor can fail then I agree but for all and 
> any of those means of failure what would be the effect on the object so 
> constructed?
> 
> If you want a specific, here's one.
> 
>   $db1 = new mysqli(...);
>   if ($db1->connect_errno...)
> 
> The instantiation can fail in a number of ways. Which of the scenarios 
> labelled 1 to 3, above, will always be true when we reach the test 
> statement? The test will baulk on two of them.
> 
> James
> 
> 

Specifically, how would the constructor fail?

I'm not trying to give you a hard time.  You can't answer what happens
in case of failure without understanding the failure itself.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14534

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:m3tc0l$8ic$1@dont-email.me...
> On 11/11/2014 10:56 AM, James Harris wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:m3t9et$t8s$1@dont-email.me...
>>> On 11/11/2014 10:13 AM, James Harris wrote:
>>>> From what I've found I understand that PHP constructors cannot return
>>>> anything and that leads on to a specific query: if a piece of PHP code
>>>> uses
>>>> new as in
>>>>
>>>>   $a = new b();
>>>>
>>>> as long as no exception is thrown is $a guaranteed to hold something
>>>> after
>>>> the statement? Is it guaranteed to hold an object of the designated 
>>>> type?
>>>> What happens if b's constructor "fails" in some way for various 
>>>> meanings
>>>> of
>>>> failure other than throwing exceptions?
>>>>
>>>> To put it another way, after the above instantiation statement which of
>>>> these would be guaranteed to be true?
>>>> 1) $a WILL contain a b object
>>>> 2) $a could be NULL
>>>> 3) $a might not exist (if it did not before the statement)
>>>>
>>>> Or does the answer depend on the specific class or on the version of 
>>>> PHP?
>>>>
>>>> Sorry that's a lot of questions. Just trying to make the query clear.
>>
>> ...
>>
>>> The first question is - how did the constructor "fail"?
>>
>> Any way you can imagine without throwing an exception. I was hoping there
>> was a universal rule that could apply to all of PHP OO programming.
>>
>
> No, specifically - how can it fail?
>
>> If you mean that a constructor cannot fail I don't agree. If you mean 
>> there
>> are limited ways that a constructor can fail then I agree but for all and
>> any of those means of failure what would be the effect on the object so
>> constructed?
>>
>> If you want a specific, here's one.
>>
>>   $db1 = new mysqli(...);
>>   if ($db1->connect_errno...)
>>
>> The instantiation can fail in a number of ways. Which of the scenarios
>> labelled 1 to 3, above, will always be true when we reach the test
>> statement? The test will baulk on two of them.

...

> Specifically, how would the constructor fail?
>
> I'm not trying to give you a hard time.

Are you sure? .... :-(

>  You can't answer what happens
> in case of failure without understanding the failure itself.

I think you may be talking about something else. I guess there are lots of 
ways a constructor can fail: out of memory, no access to a resource, invalid 
parameter value, incompatible parameters, disk IO error, network outage, 
invalid credentials, faulty program etc etc. Without knowing the internals 
of a particular constructor (not a good idea) your question about how that 
constructor can fail cannot be answered. Even if it could the answer(s) 
might change when a new version of that constructor is released. So there is 
no way to sensibly enumerate all potential causes of failure and derive 
findings from that.

So rather than asking about a specific constructor I was looking to see if 
there was a PHP rule that could always be applied.

If that's not what you mean can you explain what you have in mind? I cannot 
understand your meaning from what you have said so far.

James

[toc] | [prev] | [next] | [standalone]

#14535

"James Harris" <james.harris.1@gmail.com> writes:

> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:m3tc0l$8ic$1@dont-email.me...
>> On 11/11/2014 10:56 AM, James Harris wrote:
>>
>> No, specifically - how can it fail?
>>
>
> ...
>
>> Specifically, how would the constructor fail?
>>
>> I'm not trying to give you a hard time.
>
> Are you sure? .... :-(
>
>>  You can't answer what happens
>> in case of failure without understanding the failure itself.
>
> I think you may be talking about something else. I guess there are lots of 
> ways a constructor can fail: out of memory, no access to a resource, invalid 
> parameter value, incompatible parameters, disk IO error, network outage, 
> invalid credentials, faulty program etc etc. Without knowing the internals 
> of a particular constructor (not a good idea) your question about how that 
> constructor can fail cannot be answered. Even if it could the answer(s) 
> might change when a new version of that constructor is released. So there is 
> no way to sensibly enumerate all potential causes of failure and derive 
> findings from that.
>
> So rather than asking about a specific constructor I was looking to see if 
> there was a PHP rule that could always be applied.
>
> If that's not what you mean can you explain what you have in mind? I cannot 
> understand your meaning from what you have said so far.
>
> James
>
>

Hi James,

Please see/run the snippet:

<?php

class foo
{
  public function __construct()
    {
      $pdo = new PDO('mysql:host=localhost;dbname=fail', 'fail', 'fail');
    }
}

try
{
  $a = new foo();
}
catch(Exception $e)
{
  // Catching what will be a PDO exception
}

var_dump($a);
?>

You will notice that $a is simply undefined (and if you do not have the
try/catch block, you won't make it that far, as your uncaught exception
will bubble up and terminate the script).

Most things that would cause an aspect of php to 'fail' are just built
in exceptions (or for something like divide by zero, a notice will be
thrown but $a will still be the class instance).

I'm not sure how else you could cause a construct to 'fail'.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14538

On 11/11/2014 12:01 PM, Matthew Carter wrote:
> "James Harris" <james.harris.1@gmail.com> writes:
> 
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:m3tc0l$8ic$1@dont-email.me...
>>> On 11/11/2014 10:56 AM, James Harris wrote:
>>>
>>> No, specifically - how can it fail?
>>>
>>
>> ...
>>
>>> Specifically, how would the constructor fail?
>>>
>>> I'm not trying to give you a hard time.
>>
>> Are you sure? .... :-(
>>
>>>  You can't answer what happens
>>> in case of failure without understanding the failure itself.
>>
>> I think you may be talking about something else. I guess there are lots of 
>> ways a constructor can fail: out of memory, no access to a resource, invalid 
>> parameter value, incompatible parameters, disk IO error, network outage, 
>> invalid credentials, faulty program etc etc. Without knowing the internals 
>> of a particular constructor (not a good idea) your question about how that 
>> constructor can fail cannot be answered. Even if it could the answer(s) 
>> might change when a new version of that constructor is released. So there is 
>> no way to sensibly enumerate all potential causes of failure and derive 
>> findings from that.
>>
>> So rather than asking about a specific constructor I was looking to see if 
>> there was a PHP rule that could always be applied.
>>
>> If that's not what you mean can you explain what you have in mind? I cannot 
>> understand your meaning from what you have said so far.
>>
>> James
>>
>>
> 
> Hi James,
> 
> Please see/run the snippet:
> 
> <?php
> 
> class foo
> {
>   public function __construct()
>     {
>       $pdo = new PDO('mysql:host=localhost;dbname=fail', 'fail', 'fail');
>     }
> }
> 
> try
> {
>   $a = new foo();
> }
> catch(Exception $e)
> {
>   // Catching what will be a PDO exception
> }
> 
> var_dump($a);
> ?>
> 
> You will notice that $a is simply undefined (and if you do not have the
> try/catch block, you won't make it that far, as your uncaught exception
> will bubble up and terminate the script).
>

But in this case the assignment to $a will not occur due to the
exception being thrown.  So of course $a will contain the previous value
or, as in your example, not being previously defined, is undefined.

> Most things that would cause an aspect of php to 'fail' are just built
> in exceptions (or for something like divide by zero, a notice will be
> thrown but $a will still be the class instance).
> 

Actually, it's a warning, not a notice.

> I'm not sure how else you could cause a construct to 'fail'.
> 

Which is the root of my question.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14537

On 11/11/2014 11:27 AM, James Harris wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:m3tc0l$8ic$1@dont-email.me...
>> On 11/11/2014 10:56 AM, James Harris wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> news:m3t9et$t8s$1@dont-email.me...
>>>> On 11/11/2014 10:13 AM, James Harris wrote:
>>>>> From what I've found I understand that PHP constructors cannot return
>>>>> anything and that leads on to a specific query: if a piece of PHP code
>>>>> uses
>>>>> new as in
>>>>>
>>>>>   $a = new b();
>>>>>
>>>>> as long as no exception is thrown is $a guaranteed to hold something
>>>>> after
>>>>> the statement? Is it guaranteed to hold an object of the designated 
>>>>> type?
>>>>> What happens if b's constructor "fails" in some way for various 
>>>>> meanings
>>>>> of
>>>>> failure other than throwing exceptions?
>>>>>
>>>>> To put it another way, after the above instantiation statement which of
>>>>> these would be guaranteed to be true?
>>>>> 1) $a WILL contain a b object
>>>>> 2) $a could be NULL
>>>>> 3) $a might not exist (if it did not before the statement)
>>>>>
>>>>> Or does the answer depend on the specific class or on the version of 
>>>>> PHP?
>>>>>
>>>>> Sorry that's a lot of questions. Just trying to make the query clear.
>>>
>>> ...
>>>
>>>> The first question is - how did the constructor "fail"?
>>>
>>> Any way you can imagine without throwing an exception. I was hoping there
>>> was a universal rule that could apply to all of PHP OO programming.
>>>
>>
>> No, specifically - how can it fail?
>>
>>> If you mean that a constructor cannot fail I don't agree. If you mean 
>>> there
>>> are limited ways that a constructor can fail then I agree but for all and
>>> any of those means of failure what would be the effect on the object so
>>> constructed?
>>>
>>> If you want a specific, here's one.
>>>
>>>   $db1 = new mysqli(...);
>>>   if ($db1->connect_errno...)
>>>
>>> The instantiation can fail in a number of ways. Which of the scenarios
>>> labelled 1 to 3, above, will always be true when we reach the test
>>> statement? The test will baulk on two of them.
> 
> ...
> 
>> Specifically, how would the constructor fail?
>>
>> I'm not trying to give you a hard time.
> 
> Are you sure? .... :-(
> 
>>  You can't answer what happens
>> in case of failure without understanding the failure itself.
> 
> I think you may be talking about something else. I guess there are lots of 
> ways a constructor can fail: out of memory, no access to a resource, invalid 
> parameter value, incompatible parameters, disk IO error, network outage, 
> invalid credentials, faulty program etc etc. Without knowing the internals 
> of a particular constructor (not a good idea) your question about how that 
> constructor can fail cannot be answered. Even if it could the answer(s) 
> might change when a new version of that constructor is released. So there is 
> no way to sensibly enumerate all potential causes of failure and derive 
> findings from that.
> 
> So rather than asking about a specific constructor I was looking to see if 
> there was a PHP rule that could always be applied.
> 
> If that's not what you mean can you explain what you have in mind? I cannot 
> understand your meaning from what you have said so far.
> 
> James
> 
> 

As I said - it all depends on the mode of failure.  Things like a disk
IO error will cause a system error, and probably terminate the script
(depending on the error).  Faulty programming which causes a run-time
error will terminate the script.

Things like invalid credentials are not a constructor failure.  They may
be a failure to access a resource, but that's up to the constructor to
determine whether it is to be considered a non-recoverable error.  If it
is, the constructor should throw an exception.

As I said - it all depends on the cause of the error.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14536

James Harris wrote:

> From what I've found I understand that PHP constructors cannot return 
> anything and that leads on to a specific query: if a piece of PHP code uses 
> new as in
> 
>   $a = new b();
> 
> as long as no exception is thrown is $a guaranteed to hold something after 
> the statement? Is it guaranteed to hold an object of the designated type? 
> What happens if b's constructor "fails" in some way for various meanings of 
> failure other than throwing exceptions?

I can only see two other kinds of failure except exceptions: errors and
failure to accomplish to properly initialize the new instance.  In the
former case the assignment to $a doesn't happen, because the script
exists beforehand.  In the latter case the constructor is faulty,
because it doesn't accomplish what it is supposed to do (it ought to
throw an exception in this case).

> To put it another way, after the above instantiation statement which of 
> these would be guaranteed to be true?
> 1) $a WILL contain a b object
> 2) $a could be NULL
> 3) $a might not exist (if it did not before the statement)

Statement 1) is true, unless the constructor throws an error or an
exception, or is faulty.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14539

On 11/11/14, 10:13 AM, James Harris wrote:
>  From what I've found I understand that PHP constructors cannot return
> anything and that leads on to a specific query: if a piece of PHP code uses
> new as in
>
>    $a = new b();
>
> as long as no exception is thrown is $a guaranteed to hold something after
> the statement? Is it guaranteed to hold an object of the designated type?
> What happens if b's constructor "fails" in some way for various meanings of
> failure other than throwing exceptions?
>
> To put it another way, after the above instantiation statement which of
> these would be guaranteed to be true?
> 1) $a WILL contain a b object
> 2) $a could be NULL
> 3) $a might not exist (if it did not before the statement)
>
> Or does the answer depend on the specific class or on the version of PHP?
>
> Sorry that's a lot of questions. Just trying to make the query clear.
>
> James
>
>

If a constructor "returns" then it is considered to have created an 
object, and that is returned by new. If a constructor doesn't want the 
object to be considered created, then it needs to either throw, or 
terminate (the script), perhaps via an error.

It is possible for a constructor to "create" an object, but perhaps in 
some way it wants to consider the object to be a "failure" (bad 
credentials for example). That sort of failure is totally up to the 
class to handle in the way it wants.

[toc] | [prev] | [next] | [standalone]

#14540

James Harris wrote:

> From what I've found

Where?

> I understand that PHP constructors cannot return anything

Doubtful.

> and that leads on to a specific query: if a piece of PHP code uses new as
> in
> 
>   $a = new b();
> 
> as long as no exception is thrown is $a guaranteed to hold something after
> the statement?

Yes, of course.

> Is it guaranteed to hold an object of the designated type?

Doubtful.  Can you imagine why?

> What happens if b's constructor "fails" in some way for various meanings
> of failure other than throwing exceptions?

Anything can happen.
 
> To put it another way, after the above instantiation statement which of
> these would be guaranteed to be true?
> 1) $a WILL contain a b object
> 2) $a could be NULL
> 3) $a might not exist (if it did not before the statement)

Do your own homework.
 
> Or does the answer depend on the specific class or on the version of PHP?

Possible.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14541

Thomas 'PointedEars' Lahn wrote:

> James Harris wrote:
> 
>> I understand that PHP constructors cannot return anything
> 
> Doubtful.

AIUI, a PHP constructor is the method __construct, and that does not
create an object, but merely initializes it, so the constructor can be
thought of as a command (opposed to a query), and as such would never
return anything (at least when properly called within a /new/ statement).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14542

"Christoph M. Becker" <cmbecker69@arcor.de> writes:

> Thomas 'PointedEars' Lahn wrote:
>
>> James Harris wrote:
>> 
>>> I understand that PHP constructors cannot return anything
>> 
>> Doubtful.
>
> AIUI, a PHP constructor is the method __construct, and that does not
> create an object, but merely initializes it, so the constructor can be
> thought of as a command (opposed to a query), and as such would never
> return anything (at least when properly called within a /new/ statement).

Although you can return any value you like when an extending class calls
it via a parent::__construct() call.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14543

On 11/11/2014 10:25 PM, Matthew Carter wrote:
> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>
>>> James Harris wrote:
>>>
>>>> I understand that PHP constructors cannot return anything
>>>
>>> Doubtful.
>>
>> AIUI, a PHP constructor is the method __construct, and that does not
>> create an object, but merely initializes it, so the constructor can be
>> thought of as a command (opposed to a query), and as such would never
>> return anything (at least when properly called within a /new/ statement).
> 
> Although you can return any value you like when an extending class calls
> it via a parent::__construct() call.
> 

Although PHP may not complain (I don't know, I've never tried it),
returning a value from a __construct() method is documented as invalid.
 See http://php.net/manual/en/language.oop5.decon.php.  The return value
of the function is void (no return value).


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14544

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 11/11/2014 10:25 PM, Matthew Carter wrote:
>> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
>> 
>>> Thomas 'PointedEars' Lahn wrote:
>>>
>>>> James Harris wrote:
>>>>
>>>>> I understand that PHP constructors cannot return anything
>>>>
>>>> Doubtful.
>>>
>>> AIUI, a PHP constructor is the method __construct, and that does not
>>> create an object, but merely initializes it, so the constructor can be
>>> thought of as a command (opposed to a query), and as such would never
>>> return anything (at least when properly called within a /new/ statement).
>> 
>> Although you can return any value you like when an extending class calls
>> it via a parent::__construct() call.
>> 
>
> Although PHP may not complain (I don't know, I've never tried it),
> returning a value from a __construct() method is documented as invalid.
>  See http://php.net/manual/en/language.oop5.decon.php.  The return value
> of the function is void (no return value).

So would this be a case of a bug in PHP or a bug in the documentation?

<?php

class foo
{
  public function __construct ()
  {
    return 42;
  }
}

class bar extends foo
{
  public function __construct ()
  {
    $z = parent::__construct ();
    var_dump ($z);
  }
}

$a = new bar ();
$b = new foo ();
var_dump ($b->__construct ());

Produces output (with all warnings turned on):
int(42)
int(42)

Obviously magically calling/running the __construct via a new class
instance disregards the return result though.





-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#14547

On 11/12/2014 1:30 AM, Matthew Carter wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 11/11/2014 10:25 PM, Matthew Carter wrote:
>>> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
>>>
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>
>>>>> James Harris wrote:
>>>>>
>>>>>> I understand that PHP constructors cannot return anything
>>>>>
>>>>> Doubtful.
>>>>
>>>> AIUI, a PHP constructor is the method __construct, and that does not
>>>> create an object, but merely initializes it, so the constructor can be
>>>> thought of as a command (opposed to a query), and as such would never
>>>> return anything (at least when properly called within a /new/ statement).
>>>
>>> Although you can return any value you like when an extending class calls
>>> it via a parent::__construct() call.
>>>
>>
>> Although PHP may not complain (I don't know, I've never tried it),
>> returning a value from a __construct() method is documented as invalid.
>>  See http://php.net/manual/en/language.oop5.decon.php.  The return value
>> of the function is void (no return value).
> 
> So would this be a case of a bug in PHP or a bug in the documentation?
> 
> <?php
> 
> class foo
> {
>   public function __construct ()
>   {
>     return 42;
>   }
> }
> 
> class bar extends foo
> {
>   public function __construct ()
>   {
>     $z = parent::__construct ();
>     var_dump ($z);
>   }
> }
> 
> $a = new bar ();
> $b = new foo ();
> var_dump ($b->__construct ());
> 
> Produces output (with all warnings turned on):
> int(42)
> int(42)
> 
> Obviously magically calling/running the __construct via a new class
> instance disregards the return result though.
> 
> 

I would say a bug in PHP.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14548

Matthew Carter wrote:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> Although PHP may not complain (I don't know, I've never tried it),
>> returning a value from a __construct() method is documented as invalid.
>>  See http://php.net/manual/en/language.oop5.decon.php.  The return value
>> of the function is void (no return value).
> 
> So would this be a case of a bug in PHP or a bug in the documentation?

<snipped code sample>

You could even do:

  class Foo {
      function __construct() {
          return 42;
      }
  }
  echo (new Foo)->__construct(); // prints 42

I don't consider this behavior to be a bug in the implementation or the
documentation, because the documentation states, that you should not
return anything from a __constructor() function.  If you nonetheless do
so, you are violating the contract.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14549

On Wed, 12 Nov 2014 13:30:51 +0100, Christoph M. Becker wrote:

> ... the documentation states that you should not
> return anything from a __constructor() function.  If you nonetheless do
> so, you are violating the contract.

Then at least a notice or warning should be raised.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14552

Denis McMahon wrote:

> On Wed, 12 Nov 2014 13:30:51 +0100, Christoph M. Becker wrote:
> 
>> ... the documentation states that you should not
>> return anything from a __constructor() function.  If you nonetheless do
>> so, you are violating the contract.
> 
> Then at least a notice or warning should be raised.

That might be a good idea, but for the sake of consistency this would
have to be done in other places as well.  Consider, for instance:

  $a = [1, 2, 3];
  array_walk($a, function ($el) {return 42;});

The returned value is silently discarded.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14555

On 11/12/2014 6:46 PM, Christoph M. Becker wrote:
> Denis McMahon wrote:
> 
>> On Wed, 12 Nov 2014 13:30:51 +0100, Christoph M. Becker wrote:
>>
>>> ... the documentation states that you should not
>>> return anything from a __constructor() function.  If you nonetheless do
>>> so, you are violating the contract.
>>
>> Then at least a notice or warning should be raised.
> 
> That might be a good idea, but for the sake of consistency this would
> have to be done in other places as well.  Consider, for instance:
> 
>   $a = [1, 2, 3];
>   array_walk($a, function ($el) {return 42;});
> 
> The returned value is silently discarded.
> 

What's wrong with discarding the returned value?  You aren't assigning
it to anything, so I would expect it to be discarded.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web