Re: [PHP-DEV] Interfaces in PHP

2002-08-21 Thread Ben Dischinger

Thanks for all of your guys' comments on this.  Ultimately I see Zeev's 
insight of PHP not having a strong type definition totally accurate. 
 Even if we did have a mechanism to make sure that a class defined 
certain functions, we could not readily see if these functions did what 
we wanted, bringing us to the same problem.

The delegation construct looks promising for having a means of multiple 
inheretence.

Ben

Zeev Suraski wrote:

> At 09:30 21/08/2002, Ben Dischinger wrote:
>
>> You don't quite get the same functionality from extending a class as you
>> would from implementing an interface.  If I'm extending temperature what
>> keeps me as a user from not overriding any of those functions? Or 
>> what if I
>> want to extend a different class but still define my class as having 
>> those
>> functions found in temperature?  Having interfaces is a nice way to 
>> skirt
>> the issue of not having multiple inheritance built into the language.
>
>
> Interfaces, IMHO, simply do not fit the spirit of PHP.  PHP is 
> extremely loose about what it 'demands' from the programmer.  You 
> don't have types, you don't have to declare variables.  But suddenly, 
> we would have a construct that 'requires' you to implement certain 
> functions?  Ok fine, so you would have to implement a certain set of 
> functions, but given the loose typing, what does that buy you anyway?  
> You can't force him to return what you expect, or even deal with the 
> arguments you send him according to their intended type.
>
> I don't see interfaces as something which makes too much sense in the 
> context of PHP, and considering the added complexity of adding such a 
> new feature, I'm against it.  Typically, the argument is between 
> single inheritance with interfaces, and multiple inheritance.  We went 
> for a multiple-inheritancish approach with delegation, and I don't 
> think we should overcomplicate it with interfaces.
>
> Zeev
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-21 Thread Brad LaFountain


--- Tim Converse <[EMAIL PROTECTED]> wrote:
> 
> --- Brad LaFountain <[EMAIL PROTECTED]> wrote:
> 
> > 2) Interfaces as they exist in java don't really give you
> > much in a stripting
> > language but if you insist on having something like that
> > you can curently do it
> > with the zend1.
> > 
> > class temperature {
> >   function __construct($value) {}
> >   function toCelcius() {}
> >   function toFarenheight() {}
> >  }
> > 
> > just use that class and extend away
> 
> Brad ---
> 
> Not the same thing at all, as I'm sure you know.  You
> usually want interfaces in addition to whatever (single)
> inheritance structure you already have.

 Well the zend1 example I gave was a workaround. But that is why I said if the
deligation gets worked out in zend2 then you could acually do similar stuff.

BTW I do use some stuff like this in some of my classes. I'll create a function
with no implementation and any extending class can override that method and use
its functionality (usally for event like stuff), so I don't have to call
method_exists() before trying to call the method.

 - Brad



__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-21 Thread Alan Knowles

Wez Furlong wrote:

>class C {
>   delegatee $foo = new IFoo(); // "implements" IFoo by delegation
>   delegatee $bar = new IBar(); // "implements" IBar by delegation
>}
>
I didnt see anyone suggest this as an alternative to the delegatee 
syntax, - it just a bit clearer to read (to me anyway..)
class C extends something {
extends IFoo as $foo;
extends IBar as $bar;
var 
function 
}


just a thought..

regards
alan


>
>$c = new C();
>
>if (has_a($c, "IFoo"))
>   $c->foo();
>if (has_a($c, "IBar"))
>   $c->bar();
>
>This "has_a" function/operator is one of the small things missing
>from the current delegation RFC, along with an "as" operator.
>For full details on this stuff, take a look at those archives - theres
>no need to keep going round in circles :-)
>
>--Wez.
>
>  
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-21 Thread Wez Furlong

Did you guys re-read the discussion in the ZE2 archives as I suggested?

In brief:

class IFoo {
   function foo() {}
}

class IBar {
  function bar() {}
}

class C {
   delegatee $foo = new IFoo(); // "implements" IFoo by delegation
   delegatee $bar = new IBar(); // "implements" IBar by delegation
}

$c = new C();

if (has_a($c, "IFoo"))
   $c->foo();
if (has_a($c, "IBar"))
   $c->bar();

This "has_a" function/operator is one of the small things missing
from the current delegation RFC, along with an "as" operator.
For full details on this stuff, take a look at those archives - theres
no need to keep going round in circles :-)

--Wez.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-21 Thread Zeev Suraski

At 09:30 21/08/2002, Ben Dischinger wrote:
>You don't quite get the same functionality from extending a class as you
>would from implementing an interface.  If I'm extending temperature what
>keeps me as a user from not overriding any of those functions? Or what if I
>want to extend a different class but still define my class as having those
>functions found in temperature?  Having interfaces is a nice way to skirt
>the issue of not having multiple inheritance built into the language.

Interfaces, IMHO, simply do not fit the spirit of PHP.  PHP is extremely 
loose about what it 'demands' from the programmer.  You don't have types, 
you don't have to declare variables.  But suddenly, we would have a 
construct that 'requires' you to implement certain functions?  Ok fine, so 
you would have to implement a certain set of functions, but given the loose 
typing, what does that buy you anyway?  You can't force him to return what 
you expect, or even deal with the arguments you send him according to their 
intended type.

I don't see interfaces as something which makes too much sense in the 
context of PHP, and considering the added complexity of adding such a new 
feature, I'm against it.  Typically, the argument is between single 
inheritance with interfaces, and multiple inheritance.  We went for a 
multiple-inheritancish approach with delegation, and I don't think we 
should overcomplicate it with interfaces.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Ben Dischinger

> 2) Interfaces as they exist in java don't really give you much in a
stripting
> language but if you insist on having something like that you can curently
do it
> with the zend1.
>
> class temperature {
>   function __construct($value) {}
>   function toCelcius() {}
>   function toFarenheight() {}
>  }
>
> just use that class and extend away
>
> - Brad

Brad,

You don't quite get the same functionality from extending a class as you
would from implementing an interface.  If I'm extending temperature what
keeps me as a user from not overriding any of those functions? Or what if I
want to extend a different class but still define my class as having those
functions found in temperature?  Having interfaces is a nice way to skirt
the issue of not having multiple inheritance built into the language.

Or as my example from before.  We have more advanced constructs built into
our class library.  An automatic database mirror search library, or maybe we
want to implement some sort of distributed class heirarchy across multiple
servers?  It would definetly be more reliable to require certain functions
be defined for classes which implement a certain interface rather than
assume it is there.

And finally if we have a class heirarchy that is already defined and I am
creating a new class called UserMenu and extending the class Menu.  What if
I want to make UserMenu searchable even though the class Menu is not?  I
can't extend both SearchableObject and Menu.  The only way that I can see
this working is if there was multiple inheratence or interfaces.  You can
think of it as inserting an additional branch into the class tree heirarchy.

But all of this is doable without having interfaces, it's just that they are
one of the easier ways to solve these problems.

Ben


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Tim Converse


--- Brad LaFountain <[EMAIL PROTECTED]> wrote:

> 2) Interfaces as they exist in java don't really give you
> much in a stripting
> language but if you insist on having something like that
> you can curently do it
> with the zend1.
> 
> class temperature {
>   function __construct($value) {}
>   function toCelcius() {}
>   function toFarenheight() {}
>  }
> 
> just use that class and extend away

Brad ---

Not the same thing at all, as I'm sure you know.  You
usually want interfaces in addition to whatever (single)
inheritance structure you already have.

-t

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Ben Dischinger

I'll try to explain why I feel such a feature as interfaces would be useful
to me in PHP.

This is all under the assumption that when a class is loaded into memory a
certain number of "checks" are performed to make sure it is a valid
definition. For example, You cannot extend a class which is not defined in
memory. Then we could then equally say that you cannot implement an
interface without first defining its functions. We are not violating the
precident of inappropriate access to private members not flagging an error
because this is not an object level error, but instead a class definition
error.

Now let's say that I am creating a standardized class library in which the
root class definition, Object, GUARANTEES a universal means of saving
objects to a database.  Obviously this is an easy problem to solve.
Serialize the object and save it to the database.

But now we add a new feature to our library.  Let's create a new class
called SearchableObject.  We want this to be a type of language construct in
which if I extend this SearchableObject a new table is created in the
database in which all of the variables of the class are mirrored instead of
serialized offering greater search flexibility.

It's funny that you mention private variables in the Zend2 Engine because
that's exactly where my problem arises.  If my class, let's call it Person,
in which I'm extending SearchableObject has private variables (such as name,
address, password).  Obviously we can't make these variables public because
then anyone could change their value.  How do I automagically save them to
the database from within the base class definition?  This is an interesting
problem.  We can't access these variables directly from a method call say,
get_object_vars($this).

One way I've found to do this is with an accessor function getVars.  Here's
an example of what it might look like:

//$child is a double hash as defined below
function getVars($child=""){
   return parent::getVars($child[$this->getClass()] =
array(var_1=>$this->var_1 ... var_n=>var_n)); //Where var_1..n are the class
variable names
}

This function provides a way of passing private variable values to the base
class without compromise of security or loss of redundant variables (i.e.
having the same variable name in the parent and child).  Now if you extend
SearchableObject we can detect it within our database save routine, but
there is still no way for us to know that you have implemented the function
getVars, therefore not guarantying that all objects can be saved
automatically.

If SearchableObject were instead an interface we could put the stub for
getVars within it, and then guarantee that any class which implemented
SearchableObject had the function getVars.  That would bring us one step
closer to our goal.

I'm sorry for the long explanation but I couldn't find a better way to
explain how interfaces could be useful without going a little in depth.  If
you have any suggestions how one would go about requiring a function be
defined in a class without using interfaces please let me know.

Thanks,

Ben Dischinger

- Original Message -
From: "Brad LaFountain" <[EMAIL PROTECTED]>
To: "Alan Knowles" <[EMAIL PROTECTED]>; "Wez Furlong" <[EMAIL PROTECTED]>
Cc: "Ben Dischinger" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, August 21, 2002 1:05 AM
Subject: Re: [PHP-DEV] Interfaces in PHP


>
> --- Alan Knowles <[EMAIL PROTECTED]> wrote:
> >  From my reading of delegation, it's really overloading, worded slightly
> > differently.. - but not that related to interfaces...
> >
> > In the example below, which is a php'ized version of a C# demo, the
> > advantages of using interfaces (as far as I know) are primarly useful
> > for COM or CORBA, where it would be possible to generate all the
> > components for a CORBA/COM/.NET, or even java binding by reading the
> > interfaces.
> >
> > A .NET binding would effectively define all the available interfaces and
> > classes, with strong typing!, and then when called (from C# or .NET)
> > invoke a C call to call_user_function, to run php exectuter
> > (probably the best way to implement a .NET server in php, - compiling a
> > loosely typed language into .NET bytecodes, from reading about
> > python,perl etcs. experience is not the way to go..)
> >
> > Other than being nice for documentation, in pure PHP, I cant really see
> > them being much use...
> >
> > Interesting subject anyway..
> >
> > Regards
> > Alan
> >
> > called from C#
> >
> > PHP_Celcius c = new PHP_Celcius(12.9);
> > system.out(c.toFarenheight().toString());
> >
> >
> >
> >
>

Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Brad LaFountain


--- Alan Knowles <[EMAIL PROTECTED]> wrote:
>  From my reading of delegation, it's really overloading, worded slightly 
> differently.. - but not that related to interfaces...
> 
> In the example below, which is a php'ized version of a C# demo, the 
> advantages of using interfaces (as far as I know) are primarly useful 
> for COM or CORBA, where it would be possible to generate all the 
> components for a CORBA/COM/.NET, or even java binding by reading the 
> interfaces.
> 
> A .NET binding would effectively define all the available interfaces and 
> classes, with strong typing!, and then when called (from C# or .NET) 
> invoke a C call to call_user_function, to run php exectuter 
> (probably the best way to implement a .NET server in php, - compiling a 
> loosely typed language into .NET bytecodes, from reading about 
> python,perl etcs. experience is not the way to go..)
> 
> Other than being nice for documentation, in pure PHP, I cant really see 
> them being much use...
> 
> Interesting subject anyway..
> 
> Regards
> Alan
> 
> called from C#
> 
> PHP_Celcius c = new PHP_Celcius(12.9);
> system.out(c.toFarenheight().toString());
> 
> 
> 
> 
> Interface temperature {
>  function __construct(float $value);
>  float function toCelcius();
>  float function toFarenheight();
> }

 There really are two different things here..

1) "Type Hints" meaning you can define the types of variables
 This has been discussed before it hasn't been turned down or implemented.

2) Interfaces as they exist in java don't really give you much in a stripting
language but if you insist on having something like that you can curently do it
with the zend1.

class temperature {
  function __construct($value) {}
  function toCelcius() {}
  function toFarenheight() {}
 }

just use that class and extend away



but this does bring up an intresting thing... To really implement interfaces
when/if delegation is implemented would be easy.

1) create a interface keyword : which is easy
2) in that state allow only function (name)(params)(semi) : i believe this is
easy
3) internally compile them as normal functions with no implemntation or see if
an e_notice can be thrown. : pretty sure this is easy as well

Im not saying that we should but it doesn't seem to be very hard at all. I
think it exists as neat vs usefull issues.

- Brad

__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Alan Knowles

 From my reading of delegation, it's really overloading, worded slightly 
differently.. - but not that related to interfaces...

In the example below, which is a php'ized version of a C# demo, the 
advantages of using interfaces (as far as I know) are primarly useful 
for COM or CORBA, where it would be possible to generate all the 
components for a CORBA/COM/.NET, or even java binding by reading the 
interfaces.

A .NET binding would effectively define all the available interfaces and 
classes, with strong typing!, and then when called (from C# or .NET) 
invoke a C call to call_user_function, to run php exectuter 
(probably the best way to implement a .NET server in php, - compiling a 
loosely typed language into .NET bytecodes, from reading about 
python,perl etcs. experience is not the way to go..)

Other than being nice for documentation, in pure PHP, I cant really see 
them being much use...

Interesting subject anyway..

Regards
Alan

called from C#

PHP_Celcius c = new PHP_Celcius(12.9);
system.out(c.toFarenheight().toString());




Interface temperature {
 function __construct(float $value);
 float function toCelcius();
 float function toFarenheight();
}

class Celcius {
Implements temperature;
var $value=0;
function __construct($value) {
$this->value =0;
}

function toCelcius() {
return $this->value;
}
function toFarenheight($value) {
return $this->value * 1.5;
}
}

class Farenheight{
Implements temperature;
var $value=0;
function __construct($value) {
$this->value =0;
}
function toCelcius() {
return $this->value / 1.5;
}
function toFarenheight($value) {
return $this->value;
}
}
Wez Furlong wrote:

>Hi Ben,
>
>ZE2 will implement something that can used much like interfaces;
>Please see this RFC on Delegation; something very similar to the syntax
>described there will be in PHP 5.
>
>http://cvs.php.net/co.php/ZendEngine2/RFCs/004.txt?r=1.2
>
>Also, review the archives for [EMAIL PROTECTED] list for more
>information about the (long) discussion on the subject.
>(http://zend.com/lists/engine2/200206/maillist.html is a rough start).
>
>--Wez.
>
>On 08/20/02, "Ben Dischinger" <[EMAIL PROTECTED]> wrote:
>  
>
>>What are the thoughts on implementing interfaces (as in object) within 
>>PHP?  Does the work outweigh the benefits?
>>
>>Ben Dischinger
>>
>>
>>-- 
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
>
>  
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Interfaces in PHP

2002-08-20 Thread Wez Furlong

Hi Ben,

ZE2 will implement something that can used much like interfaces;
Please see this RFC on Delegation; something very similar to the syntax
described there will be in PHP 5.

http://cvs.php.net/co.php/ZendEngine2/RFCs/004.txt?r=1.2

Also, review the archives for [EMAIL PROTECTED] list for more
information about the (long) discussion on the subject.
(http://zend.com/lists/engine2/200206/maillist.html is a rough start).

--Wez.

On 08/20/02, "Ben Dischinger" <[EMAIL PROTECTED]> wrote:
> What are the thoughts on implementing interfaces (as in object) within 
> PHP?  Does the work outweigh the benefits?
> 
> Ben Dischinger
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Interfaces in PHP

2002-08-20 Thread Ben Dischinger

What are the thoughts on implementing interfaces (as in object) within 
PHP?  Does the work outweigh the benefits?

Ben Dischinger


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php