Re: [PHP-DEV] Proposal for aggregation vs. MI
On Wed, 2002-04-10 at 22:58, Andi Gutmans wrote:
I still prefer to keep PHP a relatively easy to learn, simple yet powerful
language.
I think this is a huge overkill and prefer going with something like I
proposed.
Anyway the inheritance debates have been going on for years and I doubt
we'll solve all possible scenarios for the first time in programming
language history. Also historically the languages which do try and solve
lots of scenarios end up having extremely complex mechanisms to do so.
I'll sum up my proposal again.
Support the following:
class MyClass extends MyParent aggregates Timer, FooBar
{
}
$obj = new MyClass; // Creates $obj-Timer and $obj-FooBar
$obj-method(); // Searches MyClass, MyParent if not found tries to call
the method on $obj-Timer followed by $obj-FooBar
In my head there was always a method_name = object hash in the
aggregating object, but then you can't deal with an aggregated object
aggregating another object. Search every time it must be.
If you want to access an aggregated object directly you can do:
$obj-Timer-method();
Actually, even if class != type in PHP, I think Wez's suggestion is a
better way of expressing this:
($obj as Timer)-method();
However, your $obj-Timer-method() can be implemented with overloading,
so it would make the implementation less complex.
There's one important thing missing in your suggestion though: the
runtime aggregate() function. We also need aggregate_info($this) for
listing aggregated classes, deaggregate($this, class) and
serialization support (you mentioned that didn't you?)
Some issues I thought of that need to be resolved:
* Which methods should be skipped? IMHO it makes sense to skip
ZE1-style constructors and methods starting with at least one
underscore. Those starting with two underscores are reserved, while it
is common practice to use one underscore for declaring a method as
private.
* Should it be possible to have multi-level aggregation?
class a aggregates b {}
class b aggregates c {}
class c { function foo() {} }
$a = new a;
$a-foo();
IMHO, the only sensible thing would be for this to call c::foo(), or
else objects would get different interfaces in different contexts.
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
It can't really be detected but it's the same as doing:
class foo {
function foo()
{
$this-bar = new foo();
}
}
There are lots of ways of shooting yourself in the foot. Simple recursion
will do the trick too.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On Fri, 2002-04-12 at 00:42, Andi Gutmans wrote:
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
It can't really be detected but it's the same as doing:
class foo {
function foo()
{
$this-bar = new foo();
}
}
There are lots of ways of shooting yourself in the foot. Simple recursion
will do the trick too.
Fair enough. :-)
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
and how does this consern serilization. Would it need to be change do designate
which objects are aggregated?
- Brad
What would happen is that 'a' will hold an instance of 'b' and an instance
of 'c' like the old historic meaning of aggregation.
However, when a method is called on 'a' and is not found we would
automatically proxy the method call to these instances (in the order of
their aggregation) and call the first existing one.
The plus is that you get something very similar to MI without having to
deal with namespace clashes such as problems when b and c have the same
variable name. Each object lives on its own but you get a central object
which reflects the interfaces of all three objects.
This is a very elegant and simple IMO. It should answer most needs.
I hope I explained it well. Let me know if you have any questions.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right one.
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would
move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
:)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to
call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right one.
hmm what would this look like?
$a-c::print();
i guess that's not that bad. and its kinda consistant
but i do like
$a-c-print();
too..
and would we treat member of b and c the same way
$a-member_of_c = false;
then the collision again
$a-same_name_var = false;
$a-c::same_name_var = false;
$a-b::same_name_var = false;
or
$a-c-same_name_var = false;
$a-b-same_name_var = false;
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
I wasn't thinking it would be a problem but the serialization could would need
to change to handle this type of change.
BTW:
Have you looked at my patch to handle method calls differently?
- Brad
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
By the way, the aggregating class could also define it's own proxy
a_print() and c_print() methods.
I don't think it's very important because it will usually not happen and is
easy to solve if it happens.
With MI this kind of stuff stinks too.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
BTW:
Have you looked at my patch to handle method calls differently?
Yes and I don't like it. I haven't had time to do timings yet. I was very
busy and will try and do it in the next few days.
hmm
The patch wasn't just for speed it was more for sloving 2 main problems.
class a
{
function foo();
function foo();
}
and for sloving
class blah extends Java (and other 'c' overloaded classes);
the speed was just a added bonus.
- Brad
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 13:07 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on
aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
PHP
very nicely.
My main concern with MI is that there are many problems with it
including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would
move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the
original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
:)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to
call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right
one.
hmm what would this look like?
$a-c::print();
i guess that's not that bad. and its kinda consistant
but i do like
$a-c-print();
too..
and would we treat member of b and c the same way
$a-member_of_c = false;
then the collision again
$a-same_name_var = false;
$a-c::same_name_var = false;
$a-b::same_name_var = false;
or
$a-c-same_name_var = false;
$a-b-same_name_var = false;
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
I wasn't thinking it would be a problem but the serialization could
would need
to change to handle this type of change.
Sure it needs to be changed.
BTW:
Have you looked at my patch to handle method calls differently?
Yes and I don't like it. I haven't had time to do timings yet. I was very
busy and will try and do it in the next few days.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
some thoughts concerning member name collisions:
(i will also demonstrate a common shortcoming that i personally
consider a design flaw that exists both in C++ and in Java - it sure
would be good to avoid the same flaw in PHP - even if MI doesn't
get into ZE2, keep this in mind for the future)
simply put, the multiple interface paradigm says that a class can provide
an unlimited number of interfaces for already-existing and / or future clients
to operate on. an interface is a contract and it is preferably immutable -
once defined, it is not a good practice to change it. additions and changes
can be accommodated by creating new interfaces. this assures consistency -
you are less likely to break something that relies on a contract if it's final.
but it seems that there is one thing some language designers have overlooked:
two methods with identical signatures (identical names) may have a totally different
meaning in different interfaces, yet it should be possible to multiply implement
both of those in one class. to achieve this, the class implementation has to know
from which interface that ambiguos method was called from. as far as i know,
this is impossible to accomplish in C++ as well as in Java (correct me if i'm wrong).
let me demonstrate (C++, with virtual destructors omitted for simplicity):
// implementation of an animated athlete running,
// so that the result is both an athlete and an animation.
// note that stopping (pausing) the animation is different from
// stopping the athlete from running...
class IAnimation { // the animation interface
public:
virtual void run() = 0;
virtual void stop() = 0;
};
class IAthlete { // the athlete interface
public:
virtual void run() = 0;
virtual void stop() = 0;
};
// so far so good...
class CAthlete: public IAthlete, public IAnimation {
public:
virtual void run() { // now what?
indeed, now what? there's no way to tell which interface we were
being cast up to when run() was called... yet as long as the Virtual
Method Table mechanism is concerned, it would actually be possible
to override such ambiguos methods multiply so that they would depend
on the upcast used - in case of non-virtual multiple inheritance as in the
example above the number of VTBL's equals the number of base classes -
the VTBL of the derived class is shared with the first base class and
the rest base classes get one VTBL each. so it would be technically
possible to allow language constructs such as:
class CAthlete: public IAthlete, public IAnimation {
public:
virtual void run() {}; // shared between derived class and first base
virtual void IAnimation::run() {}; // called when upcast to second base
in case of virtual inheritance it would even be possible to differentiate
between all three possible upcasts. however, sadly, C++ does not
allow to explicitly differentiate overrides in different VTBL's. a similar
equivalent seems to be missing from Java, too, if i'm not horribly mistaken...
the effect of this flaw is that developers have to keep track on interface
method names of all interfaces concurrently and manually avoid conflicts.
this is, of course, a big heavy rock on shoulders. all of this also applies
when multiply inheriting implementation, but i chose interfaces so that
my example would make sense in Java.
in PHP we would, of course, only find use for inheriting implementations,
not interfaces. i suggest the following syntax for resolving ambiguities:
class A {
function foo() {}
}
class B {
function foo() {}
}
class MI extends A, B {
function foo() {} // *must* exist, throw compiler fatal otherwise
function A::foo() {} // may exist, up to the programmer
function B::foo() {} // may exist, up to the programmer
}
$mi = new MI();
$a = (A)$mi; // explicit upcast
$b = (B)$mi; // explicit upcast
$mi-foo(); // calls MI::foo()
$a-foo(); // calls MI::A::foo() if exists, MI::foo() otherwise
$b-foo(); // calls MI::B::foo() if exists, MI::foo() otherwise
since all objects are passed by reference in ZE2, this would
work as expected, that is, quite reasonably well. but what if
someone inherits from MI? let me list the possibilities:
class X extends MI {
function foo() {}
function MI::foo() {}
function MI::A::foo() {}
function MI::B::foo() {}
}
anybody can see that this syntax would bring *polymorphism* to
a new level and open up neverbeforeseen doors in sense of code reuse.
why should we give up on MI and keep all those doors closed?
i see no harm caused by such syntax to neither compatibility with
single inheritance nor to novice / non-expert PHP programmers -
if they simply don't use features they do not comprehend then PHP
looks like plain-vanilla good-old single-inheritance PHP as they've
always known it. but for the wonderers out there, we would give
a whole new world to explore... and finally, the only certain way
to find out whether a product is successful is to put it on the market...
any comments / corrections are most welcome,
lauri
Re: [PHP-DEV] Proposal for aggregation vs. MI
If you want to access an aggregated object directly you can do: $obj-Timer-method(); well, that's exactly what shouldn't be done and what polymorphism is trying to eliminate... consider a huge code library which operates on an object of class Timer and that we want to reuse this library. now if we hand it an aggregated object whose method() points to the wrong method() we would have to search-and-replace, that is, more or less manually change all occurences of -method(); into -Timer-method(); - would you say this is feasible?? the whole idea of polymorphism is to allow both implicit reuse and implicit growth of code base. if a technique that is supposed to head towards code reuse requires a single implicit call to be manually hunt down and changed into an explicit one, then it's quite useless i'd say... having MI and casts you would simply: big_hairy_library_call( (Timer) $MI_obj ); ...and be done with it. as a bonus, you get to sleep the whole night instead of searching-and-replacing text in somebody else's library till the early morning... nothing personal, just trying to provide a scenario :) lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
PHP isn't a compiled language and we aren't going to start adding casting, v-tables and so on. PHP is extremely loosely typed and doing $obj-foo calls the method foo on $obj. This also allows for things like: $blah = foo; $obj-$blah; and so on. I really think that people who are looking for strict typing, v-tables, and so on should be looking at languages such as Java, C# and C++. (Although each one of these also has their quirks). Sorry to be so blunt but I don't want to see PHP changed into yet another hard to use strongly typed compiled language. I want to keep its spirit. Andi At 00:25 11/04/2002 +0300, Lauri Liinat wrote: If you want to access an aggregated object directly you can do: $obj-Timer-method(); well, that's exactly what shouldn't be done and what polymorphism is trying to eliminate... consider a huge code library which operates on an object of class Timer and that we want to reuse this library. now if we hand it an aggregated object whose method() points to the wrong method() we would have to search-and-replace, that is, more or less manually change all occurences of -method(); into -Timer-method(); - would you say this is feasible?? the whole idea of polymorphism is to allow both implicit reuse and implicit growth of code base. if a technique that is supposed to head towards code reuse requires a single implicit call to be manually hunt down and changed into an explicit one, then it's quite useless i'd say... having MI and casts you would simply: big_hairy_library_call( (Timer) $MI_obj ); ...and be done with it. as a bonus, you get to sleep the whole night instead of searching-and-replacing text in somebody else's library till the early morning... nothing personal, just trying to provide a scenario :) lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote: big_hairy_library_call( (Timer) $MI_obj ); (insert_the_name_of_your_class_here) might be tricky to implement in the ZE, but I agree with the principle, hence my suggestion for: big_hairy_library_call($MI_obj as Timer); Same thing, slightly different syntax. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Marcus Börger [EMAIL PROTECTED] wrote: At 23:25 10.04.2002, Lauri Liinat wrote: If you want to access an aggregated object directly you can do: $obj-Timer-method(); big_hairy_library_call( (Timer) $MI_obj ); Where is the big difference (first is postfix syntax, second is prefix syntax). And as we have no typesystem we cannot use typecasting but another solution. The problem is that if $MI_obj is_a Timer, $MI_obj-Timer isn't the correct thing to do. I still think we need an as operator to perform this casting, or a has_as operator/function so that an as operator could be coded as a function. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
i'll try to answer both Marcus and Wez here: Where is the big difference (first is postfix syntax, second is prefix syntax). the difference is between whether you have to change *lots* of existing code or do exactly *one* cast in new code while you write it: $timer = (Timer) $MI_obj; library_call_1 ($timer); library_call_2 ($timer); library_call_3 ($timer); etc... what i am proposing here is that the cast would stick when object references are passed around or assigned to. the reference $var would implicitly remember the class it has been cast up to. reasonable enough? And as we have no typesystem we cannot use typecasting but another solution. no typesystem huh? we do have classes, right? so we do have a typesystem, and just because a variable's type is hidden from the programmer most of the time doesn't mean it isn't there. btw, PHP already has the (new_type)$var cast syntax - you can do $var = (int)$var for example. so we wouldn't really be adding a new construct, but rather extending an existing one. so, Wez - why would you want to introduce yet another cast operator - the as keyword? while PHP already has adopted the C-style (new_type)... operator? lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote: so, Wez - why would you want to introduce yet another cast operator - the as keyword? while PHP already has adopted the C-style (new_type)... operator? Since we don't have a real type system, (type) casting doesn't actually do what you were thinking. (Look for ZEND_CAST in zend_execute.c). My thought for having a different operator from (cast) was that it avoids possible ambiguities when we have an object class and try (object)$obj. All this would do is return $obj as-is, since it is already a PHP object, and not return a class object representation of it. Likewise for the other basic type names. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
I was looking at other languages that are loosely typed like PHP to see how
they implemented their classes. A good example that is known by a lot of
people is Javascript. Here are some things I gathered:
Class-based object-oriented languages, such as Java and C++, are founded on
the concept of two distinct entities: classes and instances.
A prototype-based language, such as JavaScript, does not make this
distinction: it simply has objects. A prototype-based language has the
notion of a prototypical object, an object used as a template from which to
get the initial properties for a new object. Any object can specify its own
properties, either when you create it or at run time. In addition, any
object can be associated as the prototype for another object, allowing the
second object to share the first object's properties.
JavaScript implements inheritance by allowing you to associate a
prototypical object with any constructor function. So, you can create
exactly the Employee-Manager example, but you use slightly different
terminology. First you define the Employee constructor function, specifying
the name and dept properties. Next, you define the Manager constructor
function, specifying the reports property. Finally, you assign a new
Employee object as the prototype for the Manager constructor function. Then,
when you create a new Manager, it inherits the name and dept properties from
the Employee object.
function Employee () {this.name = ;this.dept = general;}
function Manager () {this.reports = [];}Manager.prototype = new
Employee;function WorkerBee () {this.projects = [];}WorkerBee.prototype
= new Employee;
In JavaScript, at run time you can add or remove properties from any object.
If you add a property to an object that is used as the prototype for a set
of objects, the objects for which it is the prototype also get the new
property.
So I was wondering if we could use that type of stuff for php, not using
functions to define classes though.
I got the info from
http://developer.netscape.com/docs/manuals/js/core/jsguide/obj2.htm#1008342
where it goes in more details.
Fab.
- Original Message -
From: Lauri Liinat [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, April 10, 2002 6:15 PM
Subject: Re: [PHP-DEV] Proposal for aggregation vs. MI
i'll try to answer both Marcus and Wez here:
Where is the big difference (first is postfix syntax, second is prefix
syntax).
the difference is between whether you have to change *lots* of existing
code
or do exactly *one* cast in new code while you write it:
$timer = (Timer) $MI_obj;
library_call_1 ($timer);
library_call_2 ($timer);
library_call_3 ($timer);
etc...
what i am proposing here is that the cast would stick when object
references are passed around or assigned to. the reference $var would
implicitly remember the class it has been cast up to. reasonable enough?
And as we have no typesystem we cannot use typecasting but another
solution.
no typesystem huh? we do have classes, right? so we do have a
typesystem, and just because a variable's type is hidden from the
programmer most of the time doesn't mean it isn't there. btw, PHP
already has the (new_type)$var cast syntax - you can do $var = (int)$var
for example. so we wouldn't really be adding a new construct, but rather
extending an existing one.
so, Wez - why would you want to introduce yet another
cast operator - the as keyword? while PHP already has
adopted the C-style (new_type)... operator?
lauri
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
