Hi,
I have promised myself to not get into this discussion for a week now,
but the smell of dead horse overwhelmed me, so here goes...
I am "guilty" of a lot of OO use in PHP related to PEAR, I think OO is a
good thing when used right, but if not.. well, as Ken said at LinuxTag,
"here, have some rope". I welcome ZE2's improvements, many of which
came to be for PEAR and similar systems, and I'm even part guilty in
some of the ZE2 design.
Anyway. In Java, you use objects on a very deep level, even strings are
objects. This makes perfect sense, because in Java creating objects is
very cheap compared to PHP. In PHP objects are expensive, so they
should be used on a much higher level. I have seen "PHP frameworks"
(well, _a_ PHP framework) with a "String" class, and that tells me that
someone has a hammer and is trying to knock in screws with it.
But I should not generalize.
There are some OO features that only make sense in combination with
others. I'll list them one by one, and even offer some alternatives:
1. Interfaces / multiple inheritance
IMHO, interfaces make little sense in a language with loose typing,
without late bindings and where code is by default compiled on every
execution.
The loosely typed nature of PHP does IMHO not fit well into the
"explicit paradigm" that interfaces represent, because they introduce
conditions that have to be met during compilation for a class to be
valid.
Also, the definition of an interface is abstract, so you would be
loading the abstract definition on every single request when PHP is used
in its "natural habitat".
The solution to this problem that was "accepted" a few months ago is
aggregates. They allow what is not too unlike runtime multiple
inheritance, but we also decided on a way to declare aggregates during
definition:
class foo aggregates bar {
}
The main difference between "extends" and "aggregate" here is that the
aggregation, created at runtime, may be removed. You may also add
additional aggregates later, as well as multiple in the class
definition. Please check the archives (there is one, right? :-) for
further details.
This does not match interfaces feature-wise because aggregates
implemented like this do not offer the explicitness. But that is a much
larger language design issue. Having a language that may both be loose
and explicit is a Bad Idea IM(NS)HO. Take a look at Perl, and see how
much fun you get when using "strict" CPAN packages (which is most) in
scripts where you don't want to bother. You end up writing only strict
code, which in practice will require the option. Doh.
2. "Optional" strong typing
When people say that being able to do
function Bar(MyClass $foo) { ... }
will not affect performance, is this based on pure wishful thinking or
real insight in the engine? I can't see how this would not have a
performance impact. I think type hints are a good idea, as long as they
are implemented with "low impact".
3. Case sensitivity
This horse is already decomposing. When you can get the "originally
cased" name of a symbol from the engine, there are no technical reasons
for introducing case sensitivity to PHP, only aesthetic and
scratchmyitchic. But alas, we try keeping to technical reasons.
Poor horsie.
- Stig
On Sat, 2002-06-08 at 03:40, Dan Hardiker wrote:
> > There are two reasons we repeat the 'PHP is not Java mantra':
> >
> > (a) Many of those requesting these changes actually DO want to see PHP
> > as a Java with PHPish syntax.
>
> Anyone wanting PHP to be a "simple" or "more flexable" Java is barking up
> the wrong tree... in fact all of the people I know who Im lobbying "better
> OO functionality in PHP" for know Java and know PHP - and use both where
> each is best. What we are requesting is that PHP expands its OO
> capabilities - not change the way it does things, not do anything
> outlandish or "stolen" from another language. Think about it - all it
> would be is like adding an extra gear to a car. Wouldnt change the
> concept, the design or the idea of the car... not the make nor model... it
> would however give it added depth and use.
>
> eg: simple db-based shopping cart web site? use PHP... complex internet
> backing system? use Java. Easy!
> > (b) Java is (so far) the best implemented OO language out there that's
> > actually being used. It symbolizes the extreme OO world, if you will.
>
> Agreed - but that doesnt mean that the people on this list are assosiating
> more OO in PHP as being one step closer to PHP being PHP-Java. If I wanted
> Java's OO implementation in PHP, Id use Java. I dont - I want OO
> implementation (not even to the extremeness of Java) put in PHP. Im not
> even sure where the issue lies of taking the step - other than "where is
> this heading in the long run".
>
> Is this all that much of an issue to implement MI, Pub/Pri/Prot
> methods/vars, possibly interfaces? Not to be Java, but to extend PHP...
> all those would help PHP as a *web based language* (hell it would help any
> language IMHO - given that its optional and not enforced). Isnt that the
> long term goal of PHP (or ZE)? To provide a most powerful backend for
> scripting languages, and to provide a RAD tool for creating websites (or
> web based systems) quickly, easily and powerfully? All the above would
> take a step closer to both those goals.
>
> Unless Im missing the mark - for which I appologise. The PHP Group as a
> whole seems to have mixed feelings on this issue - could there be some
> form of concensus so that I (and many others on this list) can work out if
> the requested extra functionality is either ruled out, in for PHP version
> x, or undecided and under continued debate. I think all sides have made
> their opinions crystal clear.
>
> Appologises for any rambling - its 2:40am heh... thanks for reading :)
>
>
> --
> Dan Hardiker [[EMAIL PROTECTED]]
> ADAM Software & Systems Engineer
> First Creative Ltd
>
>
>
> --
> 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
