I first stumbled upon this problem in one of the RCs for PHP 5, but at the
time I thought I was at fault...
Consider the documentation at
http://www.php.net/manual/en/language.oop5.object-comparison.php : the
documentation is a little vague, but it does say Two object instances are
equal if they
Hello Robert,
Tuesday, October 19, 2004, 4:32:58 AM, you wrote:
On Mon, 2004-10-18 at 22:09, Robert Silva wrote:
Based on the issues you listed, how about:
function Method((MyClass) $obj);
function Method([MyClass] $obj);
Surrounding the class type in () or [] thereby marking it as
Hi All,
I could see zend_static_Allocator.c inside ZendEngine2.
I could not see this file is getting compiled in PHP-5.0.0/PHP-5.1-dev.
What is the use of this file? How to run ./configure to add this to my
Makefile?
Or is it meant for future use?
Why I am concerned about it is, in its current
Marcus Boerger wrote:
Their usage means you can rely on the fact that a certain class type
or interface is present. That means i could agree to have a way to
mark typehinted values as optional
I second that. NULL (or anything else than object of the hinted type) is
not an option.
But the
Andi Gutmans wrote:
So one suggestion (also made a few months ago) was that the following:
function method(MyClass $obj = NULL);
would mark $obj as allowing NULL parameter.
The only restrictions I see is that it makes the parameter optional as
well (something I don't consider a problem as it is
Jevon Wright wrote:
I first stumbled upon this problem in one of the RCs for PHP 5, but at the
time I thought I was at fault...
Consider the documentation at
http://www.php.net/manual/en/language.oop5.object-comparison.php : the
documentation is a little vague, but it does say Two object instances
As a point of interest, the error message you get if you pass something
to a function which has classhint on the relevant arg which is not an
object is as follows:
Fatal error: Argument 1 must not be null in .
Which is not strictly correct, but it got me thinking: maybe the guy
that wrote
On Tue, 2004-10-19 at 02:42, Christian Schneider wrote:
The only restrictions I see is that it makes the parameter optional as
well (something I don't consider a problem as it is probably desirable
in most cases anyway to be able to leave out an explicit null) and that
it only works if no
The reason is that == compares the elements as opposed to === which
compares the object handles.
We get infinite recursion comparing these two because the object points at
itself.
I'm not sure if there's a good way of solving that.
Do you really want == ordoes === do the job for you?
Andi
At
At 10:10 AM 10/19/2004 -0400, Greg Beaver wrote:
Jevon Wright wrote:
I first stumbled upon this problem in one of the RCs for PHP 5, but at the
time I thought I was at fault...
Consider the documentation at
http://www.php.net/manual/en/language.oop5.object-comparison.php : the
documentation is a
Hello Jochem,
Tuesday, October 19, 2004, 4:34:40 PM, you wrote:
As a point of interest, the error message you get if you pass something
to a function which has classhint on the relevant arg which is not an
object is as follows:
Fatal error: Argument 1 must not be null in .
Which is
Hello Christian,
we've discussed this restriction before and the more i think over the
issue the more i come to the conclusion that if at all we should provide
this exact syntax.
regards
marcus
Tuesday, October 19, 2004, 11:42:22 AM, you wrote:
Andi Gutmans wrote:
So one suggestion (also
The issues surrounding this seemed to have been muddied up a little, I'll
try to clear them up.
I see two different sets of functionality that people are asking for.
#1. The ability to pass null on a type hinted param (but still a mandatory
param)
#2. The ability to define an optional type
Hello Robert,
Tuesday, October 19, 2004, 10:20:59 PM, you wrote:
The issues surrounding this seemed to have been muddied up a little, I'll
try to clear them up.
I see two different sets of functionality that people are asking for.
#1. The ability to pass null on a type hinted param (but
People keep calling the following invalid:
function method(MyClass $param1=null, $param2)
I'm way behind the times (running 4.3.6), but take a
look at how 4.3.6 behaves!:
?
function method($param1=null,$param2) {
print $param1:$param2\n;
}
method(1,2);
method(1);
?
produces
1:2
Warning:
Hello Robert,
Tuesday, October 19, 2004, 11:33:29 PM, you wrote:
Am I just being a goofball seeing a distinction between allowing a class
hint to accept null vs. it being an optional parameter?
Both Todd's and Marcus' replies seem to indicate otherwise.
I didn't say anything else. I said we
Hello Todd,
Tuesday, October 19, 2004, 11:10:53 PM, you wrote:
People keep calling the following invalid:
function method(MyClass $param1=null, $param2)
I'm way behind the times (running 4.3.6), but take a
look at how 4.3.6 behaves!:
?
function method($param1=null,$param2) {
print
That's a really elegant solution... I'm up for trying that out. Remember to
do != too :)
Jevon
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Greg Beaver [EMAIL PROTECTED]; Jevon Wright [EMAIL PROTECTED]
Cc: Benj Carson [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent:
Marcus,
thanks for taking the time to comment. I realise that you core dev guys
have plenty to do.
if I gather correctly you do understand why people would like to do
stuff like (and indeed did in early versions of php5 - I got caught out
myself when the change was made):
myFunc(MyObj $o =
Marcus Boerger wrote:
Hello Robert,
Tuesday, October 19, 2004, 10:20:59 PM, you wrote:
The issues surrounding this seemed to have been muddied up a little, I'll
try to clear them up.
I see two different sets of functionality that people are asking for.
#1. The ability to pass null
Ok, last email then I swear I'll drop the issue and let you big dogs decide
on a solution :)
You say you are opposed to allowing null for type hinted values. Yet then
you say you would agree to optional type hinted params (which could only
default to a null value), so as a result, you really
Robert Silva wrote:
Function Equals([ZObject] $objA, [ZObject] $objB) {}
To me, it would be more readable and more closely match the traditional
documentation format people are used to if the [] encase the whole
parameter as in:
function Equals([ZObject $objA[, ZObject $objB]])
Adding this in
FYI, attached is a highly edited (for brevity) series of responses to the
SQLite mailing list, to a query about SQLite3 being included in PHP 5. My
reply is first.
D. Richard Hipp is the author of SQLite, so his response is of particular
relevance...
[EMAIL PROTECTED] writes:
julien [EMAIL
23 matches
Mail list logo
