Andrey Hristov wrote:
>>.
>>.
ah, the code has an error and I found more efficient way (for objects no need of string
compare):
class Fubar {
protected function doSomething_integer_integer_double($i1,$i2,$f) {
$a = func_get_args();var_dump(__METHOD__, $a);
}
protected function doSome
George Schlossnagle wrote:
>> ..
$a = new fubar();
$a->doSomething(1, 2.0);
$a->doSomething(3,4, 5.0);
?>
The problem with this is that that integer may well be a string when you
look at it. There's no good way to do this past discriminating between
scalar, array and object (by type, of course
If it makes any difference...
I would say no way to multi method dispatch. PHP, in my understanding, was
a loosely typed language, and this is straining against that very
concept. In the rare case that one needs multi-method dispatch, they can
use a format such as:
class xyz
{
public fun
Christian Schneider wrote:
Sebastian Bergmann wrote:
Since we introduce class type hints in PHP 5.0 I think it would be a
good thing [tm] to add multi-method dispatch in PHP 5.1.
Actually I think multi-method dispatching for PHP is A Bad Thing[tm].
Multi-method dispatching is necessary for
http://bugs.php.net/bug.php?id=19749
It's been playing on my mind recently that this bug
hasn't been addressed; the problem was how to guess
precisely what limit to set for mmaping when doing
something like readfile().
[note that some comments are missing from the bugdb
for that bug]
Well, we can
Sebastian Bergmann wrote:
Since we introduce class type hints in PHP 5.0 I think it would be a
good thing [tm] to add multi-method dispatch in PHP 5.1.
Actually I think multi-method dispatching for PHP is A Bad Thing[tm].
Multi-method dispatching is necessary for statically checked, inflexible
On Apr 20, 2004, at 3:18 PM, Marcus Boerger wrote:
The problem with this is that that integer may well be a string when
you look at it. There's no good way to do this past discriminating
between scalar, array and object (by type, of course). I personally
think that that is fine (adding an array
Hello George,
Tuesday, April 20, 2004, 8:57:31 PM, you wrote:
> On Apr 20, 2004, at 2:51 PM, Andrey Hristov wrote:
>> Quoting Sebastian Bergmann <[EMAIL PROTECTED]>:
>>
>>> Since we introduce class type hints in PHP 5.0 I think it would be a
>>> good thing [tm] to add multi-method dispatch i
On Apr 20, 2004, at 2:51 PM, Andrey Hristov wrote:
Quoting Sebastian Bergmann <[EMAIL PROTECTED]>:
Since we introduce class type hints in PHP 5.0 I think it would be a
good thing [tm] to add multi-method dispatch in PHP 5.1.
What I mean by this would be to allow for the following:
clas
Quoting Sebastian Bergmann <[EMAIL PROTECTED]>:
> Since we introduce class type hints in PHP 5.0 I think it would be a
> good thing [tm] to add multi-method dispatch in PHP 5.1.
>
> What I mean by this would be to allow for the following:
>
> class Foo {
> public function doSom
Done.
On Tue, 2004-04-20 at 11:43, Andi Gutmans wrote:
> I asked John to apply it. I prefer him to make sure it's OK (although I
> looked over it and it looks fine).
>
> At 04:31 PM 4/20/2004 +0100, Nuno Lopes wrote:
> >Hello,
> >
> >It seems that nobody applied my patch to tidy (maybe because o
I'm building PHP 5RC1 and 4.3.6 on a RH ES3 Linux box. 4.3.6 builds and runs
perfectly - the same configure options on PHP 5 produces a build, but gives
runtime errors about undefined symbols at PHP startup (e.g. In response to
php -v). I then failed to find any docs on differences in compile time
On Apr 20, 2004, at 11:39 AM, Ferdinand Beyer wrote:
On 20 Apr 2004 at 11:22, George Schlossnagle wrote:
PHP doesn't support this, regardless of you being able to tell them
apart, scalar types in PHP are isomorphic.
Yes, I know. This is why I am against strict parameter checking.
Everything works
I asked John to apply it. I prefer him to make sure it's OK (although I
looked over it and it looks fine).
At 04:31 PM 4/20/2004 +0100, Nuno Lopes wrote:
Hello,
It seems that nobody applied my patch to tidy (maybe because of the hot
discussion).
Please review it here:
http://news.php.net/article
On 20 Apr 2004 at 11:22, George Schlossnagle wrote:
> PHP doesn't support this, regardless of you being able to tell them
> apart, scalar types in PHP are isomorphic.
Yes, I know. This is why I am against strict parameter checking.
> > Provided that one has access to the interfaces...
>
> I mu
Hello,
It seems that nobody applied my patch to tidy (maybe because of the hot
discussion).
Please review it here:
http://news.php.net/article.php?group=php.internals&article=9338
It fixes a bug and completes the changes to the StudlyCaps convention. It
also frees up some memory, because I've rem
On Apr 20, 2004, at 11:14 AM, Ferdinand Beyer wrote:
On 20 Apr 2004 at 17:55, Stanislav Malyshev wrote:
FB>>Impl guarantees that by implementing interface A.
No. It _says_ it implements interface A, but you couldn't know if it
indeed does, if we allow your model - maybe that "dispatched"
functio
On 20 Apr 2004 at 17:55, Stanislav Malyshev wrote:
> FB>>Impl guarantees that by implementing interface A.
>
> No. It _says_ it implements interface A, but you couldn't know if it
> indeed does, if we allow your model - maybe that "dispatched"
function
> call doesn't really accept those argume
FB>>Impl guarantees that by implementing interface A.
No. It _says_ it implements interface A, but you couldn't know if it
indeed does, if we allow your model - maybe that "dispatched" function
call doesn't really accept those arguments?
FB>>What if Impl::doSomething() would accept exactly two
On Apr 20, 2004, at 10:48 AM, Ferdinand Beyer wrote:
On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote:
FB>>interface A {
FB>>public function doSomething($integer1, $integer2);
FB>>}
FB>>
FB>>interface B {
FB>> public function doSomething(MyObject $obj);
FB>>}
FB>>
FB>>class Impl implements
Since we introduce class type hints in PHP 5.0 I think it would be a
good thing [tm] to add multi-method dispatch in PHP 5.1.
What I mean by this would be to allow for the following:
class Foo {
public function doSomething(Foo $foo) {}
public function doSomething(Bar $b
On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote:
> FB>>interface A {
> FB>>public function doSomething($integer1, $integer2);
> FB>>}
> FB>>
> FB>>interface B {
> FB>> public function doSomething(MyObject $obj);
> FB>>}
> FB>>
> FB>>class Impl implements A, B
> FB>>{
> FB>>// "Overload
Andi Gutmans wrote:
> And regular old-style inheritance?
If you mean
class Foo {
public function doSomething($a, $b) {}
}
class Bar extends Foo {
public function doSomething($c, $d, $e) {}
}
by "regular old-style inheritance" then no. It would not make sense to
FB>>interface A {
FB>>public function doSomething($integer1, $integer2);
FB>>}
FB>>
FB>>interface B {
FB>> public function doSomething(MyObject $obj);
FB>>}
FB>>
FB>>class Impl implements A, B
FB>>{
FB>>// "Overloaded" - supports both doSomething() interfaces
FB>>public function doSom
On 19 Apr 2004 at 20:44, Marcus Boerger wrote:
> Simply decalre thos methos with an empty signature and use the
> appropriate functions to handle the arguments?
That does not work for foreign/internal interfaces/base classes.
Again: Why should we add this strictness? Since PHP is loosely
typed,
On Tue, 20 Apr 2004, George Schlossnagle wrote:
> On Apr 20, 2004, at 3:22 AM, Derick Rethans wrote:
>
> > On Mon, 19 Apr 2004, Sterling Hughes wrote:
> >
> >> mo compile errors mo better.
> >
> > But NOT for normal methods!
>
> I agree with Derick. Compile errors for interfaces methods good.
> C
On Apr 20, 2004, at 3:22 AM, Derick Rethans wrote:
On Mon, 19 Apr 2004, Sterling Hughes wrote:
mo compile errors mo better.
But NOT for normal methods!
I agree with Derick. Compile errors for interfaces methods good.
Compile errors for normal inherited methods bad.
Derick
--
PHP Internals -
ZS>>I believe that this behavior is wrong. I believe that classes should
ZS>>not be allowed to say they implement an interface X, unless they
ZS>>actually implement all of the methods in that interface with methods
ZS>>that are compatible with its prototypes.
I agree. Since interfaces and abstrac
On 4/20/04 11:19 AM, Andi Gutmans wrote:
Oh :) I thought that was zend_is_callable().
I'm OK with you commiting this. It's a small one and quite useful.
Thanks. Comited.
chregu
Andi
At 11:11 AM 4/20/2004 +0200, Christian Stocker wrote:
On 4/20/04 11:05 AM, Andi Gutmans wrote:
Hi,
From loo
Oh :) I thought that was zend_is_callable().
I'm OK with you commiting this. It's a small one and quite useful.
Andi
At 11:11 AM 4/20/2004 +0200, Christian Stocker wrote:
On 4/20/04 11:05 AM, Andi Gutmans wrote:
Hi,
From looking at the non-whitespace diff I don't quite understand what
you cha
On 4/20/04 11:05 AM, Andi Gutmans wrote:
Hi,
From looking at the non-whitespace diff I don't quite understand what
you changed (except for adding an error message if it's not callable).
What am I missing?
the zend_make_callable() was missing. it didn't work without that.
chregu
Andi
At 1
Hi,
From looking at the non-whitespace diff I don't quite understand what you
changed (except for adding an error message if it's not callable). What am
I missing?
Andi
At 11:00 AM 4/20/2004 +0200, Christian Stocker wrote:
Hi
I made a patch for making static php method calls (ala class::metho
Hi
I made a patch for making static php method calls (ala class::method)
work from within xslt.
(see http://slides.bitflux.ch/phpug2004_1/slide_37.html for some details
about this technique)
I'm not sure, if I can commit that now in this stage of the release
process. Would be great, if it woul
On Mon, 19 Apr 2004, Sterling Hughes wrote:
> mo compile errors mo better.
But NOT for normal methods!
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
34 matches
Mail list logo
