Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] RE:[PHP-DEV] oo != php
Alex Black wrote:
class foo aggregates bar {
}
I think that is a nice solution.
It's not, because it's static. Multiple iheritance is flawed, because
it's static.
Have a look at my RfC for delegation:
RfC: http://cvs.php.net/co.php/ZendEngine2/RFCs/004.txt
Further reading: http://javalab.cs.uni-bonn.de/research/darwin/
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
Stig S. Bakken wrote:
1. Interfaces / multiple inheritance
[snip]
I totally agree that those two don't belong into PHP.
class foo aggregates bar {
}
Please see my other reply (RfC on Delegation).
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] RE:[PHP-DEV] oo != php
At 10:19 AM 6/11/2002, Sebastian Bergmann wrote:
Alex Black wrote:
class foo aggregates bar {
}
I think that is a nice solution.
It's not, because it's static. Multiple iheritance is flawed, because
it's static.
That's hardly considered a flaw almost anywhere, even in the studies that
tear MI down to pieces. Being able to aggregate at class declaration time
or at the object instantiation time should be well more than enough - being
able to switch aggregated objects after instantiation is not very helpful IMHO.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [ZendEngine 2] RE:[PHP-DEV] oo != php
Zeev Suraski wrote:
able to switch aggregated objects after instantiation is not very
helpful IMHO.
Strategy Design Pattern
?php
class aStrategy {
// ...
}
class anotherStrategy {
// ...
}
class Foo {
delegatee $strategy;
function setStrategy($strategy) {
$this-strategy = $strategy;
}
}
?
This way, an object of Foo can dynamically change behaviour in a very
elegant way.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [ZendEngine 2] RE:[PHP-DEV] oo != php
At 11:23 AM 6/11/2002, Sebastian Bergmann wrote: This way, an object of Foo can dynamically change behaviour in a very elegant way. I'm well aware of the strategy design pattern, but it existed before 'Lava' (I use it in Java all the time)... You can just as easily do this by creating a new object with the requested strategy. The added mess that dynamically changing the aggregated objects gives you is not worth the benefit, IMHO. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
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
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] RE:[PHP-DEV] oo != php
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...
heh.
class foo aggregates bar {
}
I think that is a nice solution.
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.
All of my arguments for this are qualified by that. If there is a
significant performance impact it should not be done. If there is not, it
should.
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.
I gave this one up. In theory I would like it, in practice I don't actually
care that much :)
I would still like Private methods, and real MI.
Anyway all, I think the middle ground is what everyone really wants: more
features, but not blindly: we don't want to screw up BC, we don't want to
change the engine hugely... where there are advantages to be had, let's take
'em... if there's a good justification against let's accept that and move
on.
_a
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
At 05:02 AM 6/8/2002 +0100, Michael Dransfield wrote: At 02:40 08/06/2002 +0100, you 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. I agree completely, for what its worth ;) I have a question about this whole debate. If PHP's core goal is to provide easy quick development for 'dynamic pages' , then why is there no built-in template engine? Having this would solve many of the niggling problems that are associated with current PHP-written (OO) template engines. Is it that there is no desire for such an extension? Please read the archives on this issue because I wouldn't want yet another long thread to start on php-dev. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] oo != php
i don't get it, ze2 introduces private members, consts, statics, namespaces, delegation (and thus mi), class in class. and all this stuff because it don't wants to be another java sebastian is currently working on a book for php-oo, wants to show us how design patterns are realized with php, even how php-projects are designed using uml... and here i must read you want real oo, take java... i know i'm penetrating you again with this worn-out shoes, anyhow, last postings (especially the php future thread) showed me i'm not the only one begging you for real oo to be added *as an option* to php. i'm quite new to this list, so please excuse if i had been sticking on a topic already shot down. and for gods sake (if you've been reading till here) - ***this will be my definitive last posting regarding this issue***. thank you for your patience, in case i'm struggling on you. however, i'm quite disappointed and demotivated by some of your opinions, stating to keep php simple and easy, not to go for a messy java-derivate, not to make things too complicated aso aso please notice, this is no offense, but after getting known of the ze2 features, i personally saw php finally growing out of that php, language for kiddies-image. imho php is a real good language for its target purpose, but it has potential to be much better. i'm not in too deep in php and its history, just following (and had been infrequently using) it since v3. but nearly every one of my collegues and friends said to me forget php for serious things. again, since getting known of ze2, i dreamt of php being not only cheap, easy, fast and extensible, but comprehensive, guiding, more explicit, powerful so it could compete against others in valueable markets like eai, ecommerce, eprocurement and all that funny buzzwords starting with e. not only being the first choice language for so called self-made web designers/developers/admins, *nix freaks, small we rule the world and make best web-applications internet e-startup and one year later f**kup companies. please don't misunderstand me, i don't want to offend anyone by writing down such statements. i'm also a selfmade man and respect all of you and your work - anyhow - realize it's the reality (at least in my special environment it is). again, yes, the're hundreds and thousands of cool applications written in php - really good stuff. but couldn't it be better once php improves and extends to a mature oo-functionality ? imho, what php currently supports regarding oo is the lowest level of integration (eg like javascript and as of flash), and ze2 is currently supporting the very very most basics of oo (classing, private members, somehow overloading, statics) and is (probably) going to support multiple inheritance, synchronized delegation, namespaces... that's imho really a very big step towards real language improvement. serious respect. however, i think it's not enough to say php is a language for easily creating good small and mid-sized web-applications *as well as* building up professional, powerful, extensible and complex applications at enterprise level. yes, indeed there's java on the market for this, there's cf, there's .net, wo aso aso... but who cares? would you really loose your community by expanding the community ? would you kick off all that guys coding php for their own website by giving companies and professionals at least the chance to get things done with php? wouldn't you inspire your existing userland to code better applications ? sorry, i don't get it - i know there has to be some cut at some point - but making oo-imrovements incomplete is worse than not making it at all. having monitored this list now for some weeks and in consequence of the recent discussions, i personally realized that my efforts towards php (time, projects, code, ideas aso aso) were not for nothing but for a language having its own life and own rules, not addressing the state-of-the-art, academically satisfied, commonly used, professional language constraints like object-orientation and explicit variable declaration. my 2c and may this topic never arise again, regards ilker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] oo != php
From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] [snip] but after getting known of the ze2 features, I personally saw PHP finally growing out of that PHP, language for kiddies-image. IMHO PHP is a real good language for its target purpose, but it has potential to be much better. PHP is a nicely done scripting language. Scripting languages tend to be easier to get into, easier to make changes with, and do a good job of gluing disparate components together. Java is a compiled language. Good for building complex tightly knit applications at the higher end of the performance spectrum. For tasks that could be done with a scripting language, the implementation cost is usually higher in Java. C++ is a lower level compiled language. Good for getting every last bit of performance possible out of the hardware. Also good for complex tightly knit applications - but at an even higher development cost. Think of each as a different tool in your toolbox. You choose the tool to fit the job at hand. A screwdriver is not a kiddie hammer. Each is well suited for different kinds of tasks. To extend the metaphor - think of an all-in-one tool - a combination of hammer and screwdriver, say. In trying to combine the two tools meant for different purposes you end up with something that is neither a particularly good hammer, or a particularly good screwdriver. So the focus on improving PHP in the role as a scripting language (not trying to make PHP into Java or C++) makes a great deal of sense. my 2c and may this topic never arise again, Amen :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] oo != php
--- Preston L. Bannister [EMAIL PROTECTED] wrote: From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] [snip] but after getting known of the ze2 features, I personally saw PHP finally growing out of that PHP, language for kiddies-image. IMHO PHP is a real good language for its target purpose, but it has potential to be much better. PHP is a nicely done scripting language. Scripting languages tend to be easier to get into, easier to make changes with, and do a good job of gluing disparate components together. Java is a compiled language. Good for building complex tightly knit applications at the higher end of the performance spectrum. For tasks that could be done with a scripting language, the implementation cost is usually higher in Java. C++ is a lower level compiled language. Good for getting every last bit of performance possible out of the hardware. Also good for complex tightly knit applications - but at an even higher development cost. Think of each as a different tool in your toolbox. You choose the tool to fit the job at hand. A screwdriver is not a kiddie hammer. Each is well suited for different kinds of tasks. To extend the metaphor - think of an all-in-one tool - a combination of hammer and screwdriver, say. In trying to combine the two tools meant for different purposes you end up with something that is neither a particularly good hammer, or a particularly good screwdriver. So the focus on improving PHP in the role as a scripting language (not trying to make PHP into Java or C++) makes a great deal of sense. OO IS OO... JUST BECAUSE JAVA IS OO DOESN'T MEAN WE ARE SUGGESTING MAKING JAVA AGAIN. WE ARE SUGGESTING MORE OO FEATURES. Please Pleas Please realize the difference. Im sick of people associating oo features as java features! Making php more like java would be suggesting making a public static void main(String args[]) in a class, and that gets run when a class with that name is loaded. Now this is stuff specfic to java! Not MI or public/private members these features have been around way before java was ever thought of!!! - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] oo != php
OO IS OO... JUST BECAUSE JAVA IS OO DOESN'T MEAN WE ARE SUGGESTING MAKING JAVA AGAIN. WE ARE SUGGESTING MORE OO FEATURES. Please Pleas Please realize the difference. Im sick of people associating oo features as java features! Making php more like java would be suggesting making a public static void main(String args[]) in a class, and that gets run when a class with that name is loaded. Now this is stuff specfic to java! Not MI or public/private members these features have been around way before java was ever thought of!!! I completely agree here. Having some extra OO features would be nice. There are a few conditions: - Using them must be optional - Performance should not suffer too much - A clean implementation is possible If adding a few OO features for the people who want (or even need) them can be done under these conditions, I think it should be considered seriously... If one of these conditions can not be met for a certain feature, it won't be worth adding IMHO. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
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. (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. Zeev At 08:41 PM 6/7/2002, brad lafountain wrote: --- Preston L. Bannister [EMAIL PROTECTED] wrote: From: Ilker Cetinkaya [mailto:[EMAIL PROTECTED]] [snip] but after getting known of the ze2 features, I personally saw PHP finally growing out of that PHP, language for kiddies-image. IMHO PHP is a real good language for its target purpose, but it has potential to be much better. PHP is a nicely done scripting language. Scripting languages tend to be easier to get into, easier to make changes with, and do a good job of gluing disparate components together. Java is a compiled language. Good for building complex tightly knit applications at the higher end of the performance spectrum. For tasks that could be done with a scripting language, the implementation cost is usually higher in Java. C++ is a lower level compiled language. Good for getting every last bit of performance possible out of the hardware. Also good for complex tightly knit applications - but at an even higher development cost. Think of each as a different tool in your toolbox. You choose the tool to fit the job at hand. A screwdriver is not a kiddie hammer. Each is well suited for different kinds of tasks. To extend the metaphor - think of an all-in-one tool - a combination of hammer and screwdriver, say. In trying to combine the two tools meant for different purposes you end up with something that is neither a particularly good hammer, or a particularly good screwdriver. So the focus on improving PHP in the role as a scripting language (not trying to make PHP into Java or C++) makes a great deal of sense. OO IS OO... JUST BECAUSE JAVA IS OO DOESN'T MEAN WE ARE SUGGESTING MAKING JAVA AGAIN. WE ARE SUGGESTING MORE OO FEATURES. Please Pleas Please realize the difference. Im sick of people associating oo features as java features! Making php more like java would be suggesting making a public static void main(String args[]) in a class, and that gets run when a class with that name is loaded. Now this is stuff specfic to java! Not MI or public/private members these features have been around way before java was ever thought of!!! - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
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-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] RE:[PHP-DEV] oo != php
eg: simple db-based shopping cart web site? use PHP... complex internet backing system? use Java. Easy! Use PHP! Easier. Look, I've built hideously complex things with PHP - commerce systems that do stream encryption on a per-field basis, complex interconnected process stuff, large APIs, everything. PHP is _already_ serious, it is being used for large, complex applications with deep APIs. 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. Well said. I think the core of everyone's argument is that we're not asking for java, we don't want java. We're asking for some incremental _additions_ to PHP OO that do not break BC, that will help us work with more advanced PHP OO systems. That's it. I don't want to see PHP turn into java because I dislike java intensely. I like the freedom given to me by PHP. 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. yes, I think some sort of clear vision of what you guys would like to see happen over the next year would help us all and likely end this thread. best, -alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
Dan Hardiker [EMAIL PROTECTED] wrote: 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. 'The PHP Group' does not control the vision for what will go into php version x. people actually willing to pitch in and do the work do. 'The PHP Group' has absolutely zero leverage to get anybody to do any work. i think people who think that 'The PHP Group' is some grand leadership council that is plotting the technical direction of the php project would be sorely disappointed if they were to read all of the mail traded over [EMAIL PROTECTED] over the last year. the vast majority of it is dealing with sysadmin stuff, and there was some discussion around adopting smarty as a subproject within the php project (and how we want to handle future projects that ask for that consideration). i can't remember the last time we've had a technical discussion of any real substance on [EMAIL PROTECTED] we've basically moved all of those discussions here. i think the resistance that people think they feel with regard to things like making more php have more oo features has more to do with some developers not willing to be told what features to implement than a notion of those features being a terrible idea. (some of us may think some are a bad idea, but working code can be very persuasive. lots of arguing and handwaving isn't.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
At 02:40 08/06/2002 +0100, you 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. I agree completely, for what its worth ;) I have a question about this whole debate. If PHP's core goal is to provide easy quick development for 'dynamic pages' , then why is there no built-in template engine? Having this would solve many of the niggling problems that are associated with current PHP-written (OO) template engines. Is it that there is no desire for such an extension? Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
