Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90696 invoked by uid 1010); 12 Oct 2004 16:15:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 86294 invoked from network); 12 Oct 2004 16:14:32 -0000 Received: from unknown (HELO student.gvsu.edu) (148.61.7.113) by pb1.pair.com with SMTP; 12 Oct 2004 16:14:32 -0000 Received: from [192.168.1.101] FARRELJA [148.61.220.192] by student.gvsu.edu with NetMail SMTP Agent $Revision: 1.1.1.1 $ on Novell NetWare; Tue, 12 Oct 2004 12:14:31 -0400 Message-ID: <416C0322.6030804@student.gvsu.edu> Date: Tue, 12 Oct 2004 12:15:30 -0400 User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net Content-Type: multipart/mixed; boundary="------------040709010409070706080307" Subject: [Fwd: Re: [PHP-DEV] Bug: Can't inherit abstract function] From: farrelja@student.gvsu.edu (Jason Farrell) --------------040709010409070706080307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------040709010409070706080307 Content-Type: message/rfc822; name="Re: [PHP-DEV] Bug: Can't inherit abstract function" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [PHP-DEV] Bug: Can't inherit abstract function" Message-ID: <416C02BB.4000300@student.gvsu.edu> Date: Tue, 12 Oct 2004 12:13:47 -0400 From: Jason Farrell User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jochem Maas CC: internals@php.net Subject: Re: [PHP-DEV] Bug: Can't inherit abstract function References: <5.1.0.14.2.20041011150822.03fe31b0@localhost> <416B88E8.6080207@iamjochem.com> <4e89b4260410120420783dd09a@mail.gmail.com> <416BD23F.30801@iamjochem.com> In-Reply-To: <416BD23F.30801@iamjochem.com> Content-Type: multipart/alternative; boundary="------------010905050203090402070407" This is a multi-part message in MIME format. --------------010905050203090402070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jochem Maas wrote: > Wez Furlong wrote: > >> An interface is a *public* contract by definition; PPP specifiers just >> don't make sense there. > > > out of curiosity: > would that be a definition at the PHP level (i.e. decided by php-devs) > or is that definition more widely acknowledged (for want of a better > word) (e.g. php-devs used the definition as used in C). > > anyway...thanks for knowledge-boost! > >> >> Neither does static, since interfaces are instance based. > > > where as the argument for PPP is wholly understandable, I can't see > the logic in saying that interfaces are per-definition instance based. > It is the class that implements the interface, but assuming that > indeed interface should be instance based then would it not be correct > to assume that interface implementation should only be checked if and > when a class is initialized (i.e. so a class is used _only_ statically > any interfaces it implements should be ignored), as per the following > example (which only works if the 'abstract' is uncommented): > > > interface Foo { function foofoo(); } > > /* abstract */ class Bar implements Foo > { > public static function barbar() > { > echo "bar bar black sheep"; > } > } > > Bar::barbar(); > > ?> > > I can understand that interfaces more naturally lean towards use with > instances rather than static classes - but it seems to me that forcing > that is a case of telling users how they must program (I have always > had the impression that PHP tried never to force a particular way of > doing things) - not that its a big deal, because in the end a > non-static method can be called statically if the user/programmer > wishes (and then its his problem to make sure the method in question > can handle being called that way, i.e. no refs to $this). > > Anyway, thanks very much for taking the time to broaden (at least) my > knowledge of PHP. > > rgds, > jochem > >> >> --Wez. >> >> On Tue, 12 Oct 2004 09:34:00 +0200, Jochem Maas >> wrote: >> >>> I would be very grateful if you could explain the logic behind not >>> being >>> able to define public/protected/private/static access modifiers for >>> interface methods (obviously they are abstract by definition). >>> >>> AFAICS (not that far I admit!) not being able to define >>> public/protected/private/static for interface methods removes a lot of >>> the power of interfaces (in terms of being able to define specifics) >> >> >> > No you will find that definition consistent in any language that uses interfaces, most notably C# and Java. As Wez alluded to, it is a **public** contract by its very definition. Cheers, Jason --------------010905050203090402070407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jochem Maas wrote:
Wez Furlong wrote:

An interface is a *public* contract by definition; PPP specifiers just
don't make sense there.

out of curiosity:
would that be a definition at the PHP level (i.e. decided by php-devs) or is that definition more widely acknowledged (for want of a better word) (e.g. php-devs used the definition as used in C).

anyway...thanks for knowledge-boost!


Neither does static, since interfaces are instance based.

where as the argument for PPP is wholly understandable, I can't see the logic in saying that interfaces are per-definition instance based. It is the class that implements the interface, but assuming that indeed interface should be instance based then would it not be correct to assume that interface implementation should only be checked if and when a class is initialized (i.e. so a class is used _only_ statically any interfaces it implements should be ignored), as per the following example (which only works if the 'abstract' is uncommented):

<?php

interface Foo { function foofoo(); }

/* abstract */ class Bar implements Foo
{
    public static function barbar()
    {
        echo "bar bar black sheep";
    }
}

Bar::barbar();

?>

I can understand that interfaces more naturally lean towards use with instances rather than static classes - but it seems to me that forcing that is a case of telling users how they must program (I have always had the impression that PHP tried never to force a particular way of doing things) - not that its a big deal, because in the end a non-static method can be called statically if the user/programmer wishes (and then its his problem to make sure the method in question can handle being called that way, i.e. no refs to $this).

Anyway, thanks very much for taking the time to broaden (at least) my knowledge of PHP.

rgds,
jochem


--Wez.

On Tue, 12 Oct 2004 09:34:00 +0200, Jochem Maas <jochem@iamjochem.com> wrote:

I would be very grateful if you could explain the logic behind not being
able to define public/protected/private/static access modifiers for
interface methods (obviously they are abstract by definition).

AFAICS (not that far I admit!) not being able to define
public/protected/private/static for interface methods removes a lot of
the power of interfaces (in terms of being able to define specifics)



No you will find that definition consistent in any language that uses interfaces, most notably C# and Java.  As Wez alluded to, it is a *public* contract by its very definition.

Cheers,
Jason
--------------010905050203090402070407-- --------------040709010409070706080307--