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
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 wo
Robert Silva wrote:
> 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),
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 aren'
On Mon, 18 Oct 2004, Ben Ramsey wrote:
> I forwarded this here because I figured it's the best place for it. This
> person will donate phpgtk.net to the PHP Group for free, so long as the
> domain name goes to the official PHP-GTK project and not to any one
> individual.
>
> Contact them for in
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 t
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 = nul
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]
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) {
>prin
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
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.
Bob
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19,
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!:
produces
1:2
Warning: Missing argument 2 for method() in /tmp/badopt.php on line 2
1:
Notice: Undefined variable: param2
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
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 hinte
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
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 ."
> Whi
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 li
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 05:
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 n
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
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
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 pr
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 t
Marcus Boerger wrote:
While [] is a nice idea for the remaining problem allowing multiple types is
a very bad idea. Instead you should use Interfaces and finally learn that
neither will we allow basetypes as typehints nor is null a type. Which
brings me back to my opinion that you should fix your c
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 sta
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 markin
26 matches
Mail list logo
