hi,
My two cents:
For one I do think that enforcing strictness, or as I see it, clean
code and implementation, should be done in php. We did not do that in
the past and it has created more issues than anything else in the long
run.
One solution to solve the need of having different methods or
co
Hi !
> For one I do think that enforcing strictness, or as I see it, clean
> code and implementation, should be done in php. We did not do that in
> the past and it has created more issues than anything else in the long
> run.
+1.
> One solution to solve the need of having different methods or
>
Hi:
if this change will not revert, I will ask a more clearly error
message for this,
I report a req, https://bugs.php.net/bug.php?id=55719,
which is, the error message should told user what the correct
argument list is.
and also submitted a patch for this req.
thanks
2011/9/1
On Sat, 17 Sep 2011, Stas Malyshev wrote:
> On 9/17/11 6:27 AM, Richard Quadling wrote:
> > With the recent BC with regard the locking of the constructor's
> > signature for subclasses, what is the expected mechanism for allowing
> > a subclass to have additional parameters?
>
> I think the whole
On 09/12/2011 05:54 AM, Pierre Joye wrote:
hi!
On Mon, Sep 12, 2011 at 2:29 AM, Avi Brender wrote:
Hi,
Please see if the attached patch better addresses your concerns.
Regarding the variable name, the PHP_FTP_OPT_USEPASVADDRESS is only internal
and is modeled after the other variables PHP_F
On Sun, Sep 18, 2011 at 5:09 PM, Derick Rethans wrote:
> On Sat, 17 Sep 2011, Stas Malyshev wrote:
>
>> On 9/17/11 6:27 AM, Richard Quadling wrote:
>> > With the recent BC with regard the locking of the constructor's
>> > signature for subclasses, what is the expected mechanism for allowing
>> > a
Hi!
On 9/18/11 8:09 AM, Derick Rethans wrote:
If you don't want those warnings, turn them off! That's why there is a
specific error level for it.
1. It's not possible to turn these specific warnings off. The error
level turns off all warnings on the level, not just specific ones.
2. These w
On Sun, Sep 18, 2011 at 8:01 PM, Stas Malyshev wrote:
> 3. Some of them aren't actually a warnings but fatal errors. Example:
>
> abstract class BaseClass {
> abstract public function foo(Type1 $foo, Type2 $bar);
> }
>
> class ExtendedClass extends BaseClass {
> public function foo() {
> }
Hi!
On 9/18/11 11:23 AM, Nikita Popov wrote:
I didn't see any complaints about this "feature", so I don't really
see a reason why we should break BC with 5.3 here and drop the error
message.
There's no matter of "breaking BC" - there's no BC issues with dropping
error messages, nobody's code
hi,
On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev wrote:
> There's no matter of "breaking BC" - there's no BC issues with dropping
> error messages, nobody's code relies on generating fatal errors for specific
> code.
Btw, afair there is and was no BC as it was introduced with the
abstract sup
On Mon, Sep 19, 2011 at 1:21 AM, Pierre Joye wrote:
> hi,
>
> On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev wrote:
>
>> There's no matter of "breaking BC" - there's no BC issues with dropping
>> error messages, nobody's code relies on generating fatal errors for specific
>> code.
>
> Btw, afair
Hi!
On 9/18/11 4:21 PM, Pierre Joye wrote:
The key word missing here is "compatible". We enforce (or should)
compatible signatures. And that makes totally sense.
foo() is compatible with foo($a, $b) - since anywhere you can call
function declared as foo($a, $b) you can also successfully call
On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev wrote:
> foo() is compatible with foo($a, $b) - since anywhere you can call function
> declared as foo($a, $b) you can also successfully call one declared as
> foo(), it'd just ignore extra parameters - but it is not allowed (I gave an
> example). I
Hi!
On 9/18/11 5:24 PM, Pierre Joye wrote:
class foo{
function __construct(){}
}
class bar extends foo{
function__construct($a, $b){}
}
Come on. This is not my example. My example was:
class foo{
function __construct($a, $b){}
}
class bar extends foo{
function__construct(){}
}
I woul
On Mon, Sep 19, 2011 at 2:24 AM, Pierre Joye wrote:
> On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev wrote:
>
>> foo() is compatible with foo($a, $b) - since anywhere you can call function
>> declared as foo($a, $b) you can also successfully call one declared as
>> foo(), it'd just ignore extra p
On Mon, Sep 19, 2011 at 2:27 AM, Stas Malyshev wrote:
> Hi!
>
> On 9/18/11 5:24 PM, Pierre Joye wrote:
>>
>> class foo{
>> function __construct(){}
>> }
>> class bar extends foo{
>> function__construct($a, $b){}
>> }
>
> Come on. This is not my example. My example was:
>
> class foo{
> functio
On Mon, Sep 19, 2011 at 2:42 AM, Pierre Joye wrote:
> But this exact example works, only the similar case using abstract
> will fail, and it makes to fail here as an abstract method is only the
> declaration, the implementation being done in the child class (bar
> extends foo). This is the concep
Hi!
On 9/18/11 5:42 PM, Pierre Joye wrote:
But this exact example works, only the similar case using abstract
will fail, and it makes to fail here as an abstract method is only the
It produces E_STRICT for regular functions, but for some reason not for
ctors, but fatal error for abstract ctor
Developing the PHP runtime
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 19.09.2011 03:00, schrieb Stas Malyshev:
> The example without abstract works, but produces E_STRICT which is useless too
right - because the following code is totally valid and reasonable even if
"my_function" will later get a fourth param $d='default' and the strict warnings
here forcing y
20 matches
Mail list logo
