RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
At 16:46 07.06.2002, Joseph Tate wrote: How much of C has been reused, and reused and reused again? There is no oo in stdlib. Ah come on there is no oo in c. You should have asked for C++ and STL (and that is very much of code reuse even though its pro is its main foe: it is so much of reuse that nearly none understands it). To add something here from my point: - When working alone PHP is fine and Java is oversized. - However i do like the PHP API very much because a) it is very powerfull and b) it does not use oo where that is not needed. - People here are mixing up thinks they do not really understand: Java is class based OO -MI +Interfaces C++ is class based OO JavaScript is OO without classes but with prototypes. PHP is something between Java/JavaScript -Interfaces +Aggregation (added by module). It has classes but allows dynamically adding of members. - When people here ask for private/protected/public this means they want to hide some class internal realisation aspects from derived classes. This is mostly used by workgroups where everyone has his own part and a class protocol (some meber functions and their interaction) is designed to allow every group member to code happily for his own in his area and knowing how to interact correctly with the others. - The above does not affect the ability to dynamically add members. However in some cases it offends class design and in other cases it is a greatly welcomed ability. (...) bla bla we had that already - FIRST: Do we want a language that can be used by workgroups? - FIRST conclusion (for me): YES if we do not make the language more complex to everybody. Here i must repeat (just follow up the thread and did not remeber who wrote it): AN EXTENSION TO THE LANGUAGE CAN BE IGNORED by those who do - not like it - not understand it It would not be Java because in Java you have no procedural paradigm and therefore you are forced to know every little OO aspect in Java before beeing able to use any part of its api. In PHP oo is only a goodie that can be used so why not making it a good one? - SECOND: We want to integrate XML/SOAP (SRM) and so on: Does anybody who endores this (nearly all here do) believe this is of any sense when not allowing more than one programmer working on the same project? I mean hey both are very complex and it is nonsense believing those features can be used alone in acceptable time. - SECOND conclusion (for me): We need some more OO features. marcus -- 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] PHP in the future
On Fri, Jun 07, 2002 at 09:27:13AM -0500, Jason T. Greene wrote: IMO, one of the big reasons for having a powerful OO mode, and continually evolving php to have a bigger target than just a web programming language, is code re-usability. You do not need OO for this. OO just helps you to manage your namespaces better. The rest is just good coding practice and a little bit of organisation. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- 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] PHP in the future
On Fri, Jun 07, 2002 at 09:27:13AM -0500, Jason T. Greene wrote: IMO, one of the big reasons for having a powerful OO mode, and continually evolving php to have a bigger target than just a web programming language, is code re-usability. You do not need OO for this. OO just helps you to manage your namespaces better. The rest is just good coding practice and a little bit of organisation. OO also helps with instancing, code organsiation, etc ... but thats not specific to more OO (as we are suggesting) ... thats also true to the existing OO capabilities PHP has. We are not asking for anything more than to extend PHP's OO capabilities (which is what this thread is all about). However you look at it - the rest of the points made on this list still stand. Extra OO does not detract from the purpose / goals of PHP nor the ZE. For census purposes (so I know weither Id be wasting my time writing a patch) can I get a karma rating (++/--) on adding extra OO capabilities reasons would also be nice (not to provoke yet more debate but to see peoples over all views). -- 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
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Am Donnerstag, 6. Juni 2002 19:59 schrieb Dan Hardiker: I sit in many PHP channels (IRC), and observe many class-based PHP networks (php-classes.org is one I monitor closely) and can say definatly that the majority of PHP users want *more* OO capabilities in PHP. From a marketing POV, what most people want is NOT more OOP in PHP, but actually a hostable Java. PHP is everywhere and pretty much free, when it comes to webspace hosting. Java usually isn't, because it has certain requirements for its execution environment that cannot be met in cheap hosting environments. So when users ask for more OO in PHP, they usually want Java and Java capabilities for the price of their current PHP site, and a migration path towards this. Since there is no such thing, they end up trying to turn PHP into Java. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Am Donnerstag, 6. Juni 2002 19:59 schrieb Dan Hardiker: I sit in many PHP channels (IRC), and observe many class-based PHP networks (php-classes.org is one I monitor closely) and can say definatly that the majority of PHP users want *more* OO capabilities in PHP. [..] So when users ask for more OO in PHP, they usually want Java and Java capabilities for the price of their current PHP site, and a migration path towards this. Since there is no such thing, they end up trying to turn PHP into Java. I disagree *very* strongly with this statement. When people ask for more OO they want more OO! Its like saying that if people wanted VC++ to be more OOed then they would just be wanting Delphi... which is just untrue. The masses are asking for more flexability and expanded capabilities - not to turn PHP into anything its not already. PHP is a partially OOed language currently, extending it into other OO areas (public/private/protected methods variables) is not altering the language structure, aim or purpose. What the masses are *not* asking for is for PHP to do things the java way. That has never been suggested or hinted at... anyone wanting this can go use Java. I dont want to use java for my current projects - there is JSP but it doesnt fit for the majority of the projects I do (right tool for the right job). Giving PHP extra OOP capabilities would extend what I can do with PHP and where I can use it. This isnt about cost of using PHP over Java its about the right tool for the right job to complete at the right speed. -- 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
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
--- Dan Hardiker [EMAIL PROTECTED] wrote: Am Donnerstag, 6. Juni 2002 19:59 schrieb Dan Hardiker: I sit in many PHP channels (IRC), and observe many class-based PHP networks (php-classes.org is one I monitor closely) and can say definatly that the majority of PHP users want *more* OO capabilities in PHP. [..] So when users ask for more OO in PHP, they usually want Java and Java capabilities for the price of their current PHP site, and a migration path towards this. Since there is no such thing, they end up trying to turn PHP into Java. I disagree *very* strongly with this statement. When people ask for more OO they want more OO! Its like saying that if people wanted VC++ to be more OOed then they would just be wanting Delphi... which is just untrue. The masses are asking for more flexability and expanded capabilities - not to turn PHP into anything its not already. PHP is a partially OOed language currently, extending it into other OO areas (public/private/protected methods variables) is not altering the language structure, aim or purpose. What the masses are *not* asking for is for PHP to do things the java way. That has never been suggested or hinted at... anyone wanting this can go use Java. I dont want to use java for my current projects - there is JSP but it doesnt fit for the majority of the projects I do (right tool for the right job). Giving PHP extra OOP capabilities would extend what I can do with PHP and where I can use it. This isnt about cost of using PHP over Java its about the right tool for the right job to complete at the right speed. Ex-friggin-actly, i couldn't agree with this more. - 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] Re: [Zend Engine 2] PHP in the future
How much of C has been reused, and reused and reused again? There is no oo in stdlib. -Original Message- Code reusability is a psychological issue. You can reuse code in PHP 4, and it'll be even better in 5 - PEAR is a clear demonstration of this. Whether people actually end up reusing code depends on the way they code, very little does it depend on the language. -- 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] PHP in the future
At 05:46 PM 6/7/2002, Joseph Tate wrote: How much of C has been reused, and reused and reused again? There is no oo in stdlib. Exactly. C is one of the easiest languages for code reuse, but it totally depends on your programming habits and skill. As a matter of fact, I find Java to be one of the most problematic languages for code reuse in certain cases. Zeev -- 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] PHP in the future
At 06:14 PM 6/7/2002, Jason T. Greene wrote: True, I hear it is even possible to reuse code in COBOL : ) I believe that the ease of maintenance depends purely on the language. i.e. using a strictly procedural language for a large framework can be quite messy. Have you ever seen large libraries written in perl that consistently call require on a million files. PEAR is a good example of a framework that ran into a lot of limitations of the language, which ZE2 will provide a great deal of help in. I agree with everything you said, just thought it'd be cool to point that out :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
At 07:01 PM 6/6/2002, brad lafountain wrote: Please don't reply to this email saying Use Java... Because php is different than java and always will be even with these new features. Brad, I beg you, there's nothing anybody can say on this list that would lead this to closure. Nothing. I believe that adding the things you mentioned does indeed turn PHP into Java, just a messy Java, Java which is worse at being Java than the real one is, and torn apart when compared against it. Many others feel the same way. You don't think that way, and I respect it, and there are also others who feel the same way too. If you, or others, want to take PHP into that direction - non-web-centric, more complicated language - it's your right, and you can do it outside the scope of PHP (or fork). I believe it's a bad thing for PHP (both having these patches in general and forking), but you don't necessarily share this belief. There's one thing that is clear to me - there's no way to 'find a solution', because we don't, at all, agree about the existence of the problem. If you believe these features belong in PHP and that it should import all (or most) of Java's features, we (and many others) have a fundamental gap in our perception of what PHP should be, and how it can stay competitive. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 07:01 PM 6/6/2002, brad lafountain wrote:
Please don't reply to this email saying Use Java... Because php is different
than java and always will be even with these new features.
Brad, I beg you, there's nothing anybody can say on this list that would
lead this to closure. Nothing. I believe that adding the things you
mentioned does indeed turn PHP into Java, just a messy Java, Java which is
worse at being Java than the real one is, and torn apart when compared
against it.
Why do you think it would be messy.
Many others feel the same way. You don't think that way, and
I respect it, and there are also others who feel the same way too. If you,
or others, want to take PHP into that direction - non-web-centric, more
complicated language - it's your right, and you can do it outside the scope
of PHP (or fork). I believe it's a bad thing for PHP (both having these
patches in general and forking), but you don't necessarily share this belief.
I do believe that making a fork or patches for php is a bad thing. It would
lead into a big mess. But at the same time i believe more strongly that cs is a
good thing, types are a good thing and stronger oo support is a good thing. To
me these are more important.
There's one thing that is clear to me - there's no way to 'find a
solution', because we don't, at all, agree about the existence of the
problem. If you believe these features belong in PHP and that it should
import all (or most) of Java's features, we (and many others) have a
fundamental gap in our perception of what PHP should be, and how it can
stay competitive.
This is exactly true. I really feel that php/zend engine could be a alot more
than you must think it can be.
The thing is the stuff that I/many people have in mind won't harm php as it
is, its just that some people don't want these new features.
Types:
?
string $var;
int $int;
$var = 123; // var will be a string
$int = $var; // int will be a int
$var2 = $var; // will be string NOTE: var2 wasn't declared
$var2 = $int; // will be int
// this is almost like a auto conversion... nothing more nothing less
$ret = doSomething($var2, $var2);
function doSomething(string $str, int $int)
{
}
?
OO Support:
interface thread
{
function run();
}
class MyClass implements thread
{
function run()
{
yeahRight();
}
function setSomething(string $test)
{
$this-something = $test;
}
opperator +(MyClass $class)
{
$this-something = $class-something;
}
opperator +(MyOtherClass $class)
{
$this-something = $class-otherSomething;
}
}
class MyOtherClass extends MyClass
{
}
MI:
Someone posted a good mi example i don't recall where it may be
class Person
{
function hello()
{
}
}
class OtherPerson
{
function hello()
{
}
}
class MulitPersonalites extends Person, otherPerson
{
var $currPerson;
function MulitPersonalites()
{
parent::Person(Jake);
parent::OtherPerson(Miles);
}
function Person::hello()
{
return super() . from multi;
}
function hello()
{
if($this-currPerson == Jake)
$this-Person::hello();
else
$this-OtherPerson::hello();
}
}
what ever the syntax should be
don't forget about the public private
Multi threading:
I know this is a huge change but.. again i think it is a good thing.
Case Sensitive:
I know the reasons for and against this and i agree with both of them. But I
would rather see CS.
For the most part the only argument against these is do we need it and it
will make things slower. Maybe somepeople do maybe somepeople don't but if
someone thinks they need it then probally others do too, how much slower will
some of these changes make the engine? Maybe not much at all. True these kinda
things will make the languge more complicated and some people don't think that
php should get complicated but I do, I think that making these kinda changes
can only make php better.
Again the point of this email isn't to change authors/founders minds its just
my point of view.
- 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
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
Brad, I beg you, there's nothing anybody can say on this list that would
lead this to closure. Nothing. I believe that adding the things you
mentioned does indeed turn PHP into Java, just a messy Java, Java which is
worse at being Java than the real one is, and torn apart when compared
against it.
Why do you think it would be messy.
Actually, given the changes I'm seeing in ZE2, and given our attempts at
building proper applications (though they are web applications) with PHP
(binarycloud), I have to agree with Brad: I don't see how they would be
messy.
I know this is a very dead horse, but I do think that PHP would benefit
greatly from just a few features:
explicit variable typing
case sensitivity (because it's confusing not to have it)
truly private methods
and a couple other things..
note though that _all_ of that can be added with minimal pain, except for
case sensitivity. (i.e. you can allow vars to be whatever if the user
doesn't preface the declaration with a type, etc).
Many others feel the same way. You don't think that way, and
Actually Zeev, everyone I talk to (and it's a freaking lot of people) likes
the idea of a tad more beefyness in PHP so long as it doesn't come at
much cost.
I do believe that making a fork or patches for php is a bad thing. It would
lead into a big mess. But at the same time i believe more strongly that cs is
a
good thing, types are a good thing and stronger oo support is a good thing. To
me these are more important.
yes. and to many other people.
remember Zeev that most people don't even understand OO concepts - so adding
cool stuff for the serious people doesn't hurt the little guy writing
procedural code in HTML one bit.
There's one thing that is clear to me - there's no way to 'find a
solution', because we don't, at all, agree about the existence of the
That's bull. We could quite reasonably expect to see some things added to
the language that would not turn it into a messy java. There are plenty of
simple additions that would benefit more sophisticated developers a great
deal.
I don't want to use Java. It sucks. I like PHP. I would like to see PHP gain
just a little more ground with OO, that's it.
fundamental gap in our perception of what PHP should be, and how it can
stay competitive.
This is exactly true. I really feel that php/zend engine could be a alot more
than you must think it can be.
I think I'm in the it could be so much more camp. I'm not hard-core about
this stuff, I don't think PHP will be useless without more advanced OO...
but I don't think it hurts anyone to add some more advanced features that
are not used by newbies. The problem with Java is that it forces developers
to code a certain way: PHP is good precisely because it _doesn't_. You can
improve PHP without sacrificing flexibility.
The thing is the stuff that I/many people have in mind won't harm php as it
is, its just that some people don't want these new features.
Types:
?
string $var;
int $int;
In fact, you could even have:
$var = crap; // standard floating type
or
string $var = 123;
$ret = doSomething($var2, $var2);
function doSomething(string $str, int $int)
{
yep.
that could be _optional_ and not change a single line of syntax in existing
code bases.
}
?
OO Support:
interface thread
{
function run();
}
class MyClass implements thread
{
function run()
{
yeahRight();
}
I don't see the need here..
function setSomething(string $test)
{
$this-something = $test;
}
opperator +(MyClass $class)
{
$this-something = $class-something;
}
opperator +(MyOtherClass $class)
{
$this-something = $class-otherSomething;
}
}
Sitto.
class MyOtherClass extends MyClass
{
}
yes :)
don't forget about the public private
Case Sensitive:
I know the reasons for and against this and i agree with both of them. But I
would rather see CS.
Ditto. If there's a time to do this it's now.
php should get complicated but I do, I think that making these kinda changes
I think we can add some of the basic necessities without impacting the
complexity of the lauguage, see above.
Again the point of this email isn't to change authors/founders minds its just
my point of view.
Mine is.
I'd love to see case sensitivity, multiple inheritance, private methods, and
optional typed variables. Except case sensitivity, all of those features can
be implemented with ZERO impact on existing users and code.
:)
_alex
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
At 08:26 PM 6/6/2002, brad lafountain wrote: --- Zeev Suraski [EMAIL PROTECTED] wrote: At 07:01 PM 6/6/2002, brad lafountain wrote: Please don't reply to this email saying Use Java... Because php is different than java and always will be even with these new features. Brad, I beg you, there's nothing anybody can say on this list that would lead this to closure. Nothing. I believe that adding the things you mentioned does indeed turn PHP into Java, just a messy Java, Java which is worse at being Java than the real one is, and torn apart when compared against it. Why do you think it would be messy. See Kristian's letters to php-dev. I really don't want to get into it at this point, mental exhaustion :) I do believe that making a fork or patches for php is a bad thing. It would lead into a big mess. But at the same time i believe more strongly that cs is a good thing, types are a good thing and stronger oo support is a good thing. To me these are more important. I don't think I can add anything about CS that I haven't already said. Adding type hints is something that we have talked about in the past, and haven't ruled out - we need to think much more about the implications. I believe the OO level we have in ZE2 is the upper limit of what a scripting language should have. There's no doubt in my mind that going beyond that is going to complicate the language beyond what our average users want. There's one thing that is clear to me - there's no way to 'find a solution', because we don't, at all, agree about the existence of the problem. If you believe these features belong in PHP and that it should import all (or most) of Java's features, we (and many others) have a fundamental gap in our perception of what PHP should be, and how it can stay competitive. This is exactly true. I really feel that php/zend engine could be a alot more than you must think it can be. No, it's not a matter of me settling for little, and you thinking we can do much better. Not at all. While I don't think we can become a better Java than Java, this is not the reason I'm so much against going down this path. If that was it, I would have said 'let's give it a try, what's the worse that can happen?' But that's not the case. I believe that by going down that route we're going to ruin PHP where it is already established as one of the most popular web platforms out there, and that's a price I'm not willing to pay. For the most part the only argument against these is do we need it and it will make things slower. Maybe somepeople do maybe somepeople don't but if someone thinks they need it then probally others do too, how much slower will some of these changes make the engine? Maybe not much at all. True these kinda things will make the languge more complicated and some people don't think that php should get complicated but I do, I think that making these kinda changes can only make php better. FWIW, I think that performance only plays a second role in such decisions. It can indeed rule out certain features if they really slow things down without giving a significant benefit, but generally, functionality is more important than performance (good functionality does not necessarily mean more features but a good, usable platform, even if it means less features). For me, the key questions are Does that belong in the language?, i.e., would adding this feature to PHP make it a stronger/more popular/easier to use web platform than it already is, and Is it worth the price (if any)?. For the CS argument, my gut feeling was 'yes' for the first question (a long time ago) but when I tried to quantify it, it occurred to me that it doesn't really make it stronger/more popular/easier, and it was a clear 'no' for the second question. In my opinion, we should ask ourselves these questions about every new language-level feature. Of course, even if we agree on the questions, it doesn't mean we'll agree about the answers - but it would at least be a good start, and a good change from Why not add it?, which many people use today. 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] PHP in the future
I believe the OO level we have in ZE2 is the upper limit of what a scripting language should have. There's no doubt in my mind that going beyond that is going to complicate the language beyond what our average users want. I would have to disagree to this statement extremly. It would not complicate the language as those not interested would just ignore the new options and go along as normal. (i.e. all methods and variables being public by default) I sit in many PHP channels (IRC), and observe many class-based PHP networks (php-classes.org is one I monitor closely) and can say definatly that the majority of PHP users want *more* OO capabilities in PHP. Interfaces provide a simple framework for expansive web scripts, which currently can only be botched with extends... and multiple inheritance would help my current PHP (web-based) project. If these features are too complex for you to understand - ignore them! In my opinion the demand is certainly there, if a subset of people dont want to use it - we're not asking them to. What the masses are calling for (and they obviously are with the frequency of this kind of post appearing) is the option to decide. Although Im no expert on the PHP source code and the underlying ZE - is it really that complex to please everyone and give a choice? [for those concerned about the proposed stuff having performance impacts - then make it a configure option... --with-more-oop (or whatever)] -- 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] PHP in the future
--- Zeev Suraski [EMAIL PROTECTED] wrote: At 08:26 PM 6/6/2002, brad lafountain wrote: --- Zeev Suraski [EMAIL PROTECTED] wrote: At 07:01 PM 6/6/2002, brad lafountain wrote: Please don't reply to this email saying Use Java... Because php is different than java and always will be even with these new features. Brad, I beg you, there's nothing anybody can say on this list that would lead this to closure. Nothing. I believe that adding the things you mentioned does indeed turn PHP into Java, just a messy Java, Java which is worse at being Java than the real one is, and torn apart when compared against it. Why do you think it would be messy. See Kristian's letters to php-dev. I really don't want to get into it at this point, mental exhaustion :) I do believe that making a fork or patches for php is a bad thing. It would lead into a big mess. But at the same time i believe more strongly that cs is a good thing, types are a good thing and stronger oo support is a good thing. To me these are more important. I don't think I can add anything about CS that I haven't already said. Adding type hints is something that we have talked about in the past, and haven't ruled out - we need to think much more about the implications. This is good to hear. I was totally against types, then i started thinking that it would acually be eaiser to use. But i wouldn't want to loose the floating types too. I believe the OO level we have in ZE2 is the upper limit of what a scripting language should have. There's no doubt in my mind that going beyond that is going to complicate the language beyond what our average users want. Average user.. maybe this is true.. but if you want to target more advance developers then you need to go the extra step and do some of the stuff. There's one thing that is clear to me - there's no way to 'find a solution', because we don't, at all, agree about the existence of the problem. If you believe these features belong in PHP and that it should import all (or most) of Java's features, we (and many others) have a fundamental gap in our perception of what PHP should be, and how it can stay competitive. This is exactly true. I really feel that php/zend engine could be a alot more than you must think it can be. No, it's not a matter of me settling for little, and you thinking we can do much better. Not at all. While I don't think we can become a better Java than Java, this is not the reason I'm so much against going down this path. If that was it, I would have said 'let's give it a try, what's the worse that can happen?' But that's not the case. I believe that by going down that route we're going to ruin PHP where it is already established as one of the most popular web platforms out there, and that's a price I'm not willing to pay. But you have one market.. Why not go for another.. You aren't going to loose the market that you have. I don't think people will stop using php for the web just because it has more options. For the most part the only argument against these is do we need it and it will make things slower. Maybe somepeople do maybe somepeople don't but if someone thinks they need it then probally others do too, how much slower will some of these changes make the engine? Maybe not much at all. True these kinda things will make the languge more complicated and some people don't think that php should get complicated but I do, I think that making these kinda changes can only make php better. FWIW, I think that performance only plays a second role in such decisions. It can indeed rule out certain features if they really slow things down without giving a significant benefit, but generally, functionality is more important than performance (good functionality does not necessarily mean more features but a good, usable platform, even if it means less features). For me, the key questions are Does that belong in the language?, i.e., would adding this feature to PHP make it a stronger/more popular/easier to use web platform than it already is, and Is it worth the price (if any)?. Why settle for just web platform. It has the potental to be any platform. So here is the question again. Does adding (some feature) to php make it a stronger/more popular/eaiser to use development platform than it already is. Does adding (more oo features) to php make it a stronger/more popular/eaiser to use development language? Yes. Does adding (types) to php make it a stronger/more popular/eaiser to use development language? Yes. ( i think this is true for the web-centric php too) Does adding (CS) to php make it a stronger/more popular/eaiser to use development language? Yes/Maybe. For the CS argument, my gut feeling was 'yes' for the first question (a long time ago) but when I tried to quantify it, it occurred to me that it
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
A couple of months ago it was agreed on how to get multiple inheritance
like behavior in a way which could work with PHP. I just haven't had time
to implement it yet.
The talk was about aggregation of instances of classes with auto-proxy.
So you'd do something like:
class foo extends bar contains barbara, foobar {
}
$obj = new foo();
$obj-method(); /* would check foo and if method doesn't exist will
auto-proxy to objects barbara and foobar in that order whatever matches
first.*/
You could access the specific object by $obj-classname or $obj-barbara.
Try and find it in the archives.
Andi
At 06:59 PM 6/6/2002 +0100, Dan Hardiker wrote:
I believe the OO level we have in ZE2 is the upper limit
of what a scripting language should have. There's no doubt in my mind
that going beyond that is going to complicate the language beyond what
our average users want.
I would have to disagree to this statement extremly. It would not
complicate the language as those not interested would just ignore the new
options and go along as normal. (i.e. all methods and variables being
public by default)
I sit in many PHP channels (IRC), and observe many class-based PHP
networks (php-classes.org is one I monitor closely) and can say definatly
that the majority of PHP users want *more* OO capabilities in PHP.
Interfaces provide a simple framework for expansive web scripts, which
currently can only be botched with extends... and multiple inheritance
would help my current PHP (web-based) project. If these features are too
complex for you to understand - ignore them!
In my opinion the demand is certainly there, if a subset of people dont
want to use it - we're not asking them to. What the masses are calling for
(and they obviously are with the frequency of this kind of post appearing)
is the option to decide. Although Im no expert on the PHP source code and
the underlying ZE - is it really that complex to please everyone and give
a choice? [for those concerned about the proposed stuff having performance
impacts - then make it a configure option... --with-more-oop (or
whatever)]
--
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
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Andi,
Before you go ahead with this I would like to discuss it some more too. I'm
wondering if we can fully support MI but i don't want to start this
conversation now.
btw: i like the contains better than aggergates.
- brad
--- Andi Gutmans [EMAIL PROTECTED] wrote:
A couple of months ago it was agreed on how to get multiple inheritance
like behavior in a way which could work with PHP. I just haven't had time
to implement it yet.
The talk was about aggregation of instances of classes with auto-proxy.
So you'd do something like:
class foo extends bar contains barbara, foobar {
}
$obj = new foo();
$obj-method(); /* would check foo and if method doesn't exist will
auto-proxy to objects barbara and foobar in that order whatever matches
first.*/
You could access the specific object by $obj-classname or $obj-barbara.
Try and find it in the archives.
Andi
At 06:59 PM 6/6/2002 +0100, Dan Hardiker wrote:
I believe the OO level we have in ZE2 is the upper limit
of what a scripting language should have. There's no doubt in my mind
that going beyond that is going to complicate the language beyond what
our average users want.
I would have to disagree to this statement extremly. It would not
complicate the language as those not interested would just ignore the new
options and go along as normal. (i.e. all methods and variables being
public by default)
I sit in many PHP channels (IRC), and observe many class-based PHP
networks (php-classes.org is one I monitor closely) and can say definatly
that the majority of PHP users want *more* OO capabilities in PHP.
Interfaces provide a simple framework for expansive web scripts, which
currently can only be botched with extends... and multiple inheritance
would help my current PHP (web-based) project. If these features are too
complex for you to understand - ignore them!
In my opinion the demand is certainly there, if a subset of people dont
want to use it - we're not asking them to. What the masses are calling for
(and they obviously are with the frequency of this kind of post appearing)
is the option to decide. Although Im no expert on the PHP source code and
the underlying ZE - is it really that complex to please everyone and give
a choice? [for those concerned about the proposed stuff having performance
impacts - then make it a configure option... --with-more-oop (or
whatever)]
--
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
__
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
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
On Thu, 6 Jun 2002, Alex Black wrote: then PHP is pretty schitzo because someone made a GTK extensions for it that seems to be supported by the core group. That's for building GUI applications last I checked. (Actually the model was so good we're using it in binarycloud!) GTK is just a cute exception of the rule. :) I think it's time for PHP-core to make a decision: is this just a web scripting language or is is an application development language? This I think that decision was made already in another thread this week on php-dev list. You won't get any exact definition what PHP's vision/future is as it has to evolve like it has done so far: By people who contribute to it. (that's basically the answer I got to this question..or at least how I understood it) I think it's already an Application Development language but some people are having trouble letting go :) It's propably because they're not using PHP to write such application themselves..? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Andi Gutmans wrote: The talk was about aggregation of instances of classes with auto-proxy. I think that's called delegation, not aggregation. Have a look at what the JavaLab guys at my University are doing under the term delegation: http://javalab.cs.uni-bonn.de/research/darwin/ and http://javalab.cs.uni-bonn.de/research/darwin/delegation_eng.html It'd be cool to have something like that in PHP :-) -- 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
[PHP-DEV] Re: [Zend Engine 2] PHP in the future
i really agree with brad.
actually,
im the kind of person that would like php to turn into java while still
having the php look and feel.
i did a few courses of java my employer send me to and i really appreciate
OO now that i got a taste of it.
because of these courses i started programingen OO in php, as much as this
is possible and soon stumbled across al of php's short commings on this
subject :(
i don't think it will have any negative effects on php implementing more OO
stuff.
lots of people out there don't even know what it is and they will code just
as happily as they were before.
still you could say that those people would have problems reading other
peoples code because it would be OO written,
but than again,
already lots of code is being written in php in an OO way so one could say
that OO shouldn't have been implemented, however simple, in the first place
as it has been.
but the php devolopers did.
so,
in holland we have a saying:
who says A must say B ;)
in other words,
if you give people a taste of the goodies they'll be banging on your door
for more in no time...
so here i am ;)
At 10:26 6-6-2002 -0700, brad lafountain wrote:
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 07:01 PM 6/6/2002, brad lafountain wrote:
Please don't reply to this email saying Use Java... Because php is
different
than java and always will be even with these new features.
Brad, I beg you, there's nothing anybody can say on this list that would
lead this to closure. Nothing. I believe that adding the things you
mentioned does indeed turn PHP into Java, just a messy Java, Java which is
worse at being Java than the real one is, and torn apart when compared
against it.
Why do you think it would be messy.
Many others feel the same way. You don't think that way, and
I respect it, and there are also others who feel the same way too. If
you,
or others, want to take PHP into that direction - non-web-centric, more
complicated language - it's your right, and you can do it outside the
scope
of PHP (or fork). I believe it's a bad thing for PHP (both having these
patches in general and forking), but you don't necessarily share this
belief.
I do believe that making a fork or patches for php is a bad thing. It
would
lead into a big mess. But at the same time i believe more strongly that cs
is a
good thing, types are a good thing and stronger oo support is a good thing. To
me these are more important.
There's one thing that is clear to me - there's no way to 'find a
solution', because we don't, at all, agree about the existence of the
problem. If you believe these features belong in PHP and that it should
import all (or most) of Java's features, we (and many others) have a
fundamental gap in our perception of what PHP should be, and how it can
stay competitive.
This is exactly true. I really feel that php/zend engine could be a alot
more
than you must think it can be.
The thing is the stuff that I/many people have in mind won't harm php as it
is, its just that some people don't want these new features.
Types:
?
string $var;
int $int;
$var = 123; // var will be a string
$int = $var; // int will be a int
$var2 = $var; // will be string NOTE: var2 wasn't declared
$var2 = $int; // will be int
// this is almost like a auto conversion... nothing more nothing less
$ret = doSomething($var2, $var2);
function doSomething(string $str, int $int)
{
}
?
OO Support:
interface thread
{
function run();
}
class MyClass implements thread
{
function run()
{
yeahRight();
}
function setSomething(string $test)
{
$this-something = $test;
}
opperator +(MyClass $class)
{
$this-something = $class-something;
}
opperator +(MyOtherClass $class)
{
$this-something = $class-otherSomething;
}
}
class MyOtherClass extends MyClass
{
}
MI:
Someone posted a good mi example i don't recall where it may be
class Person
{
function hello()
{
}
}
class OtherPerson
{
function hello()
{
}
}
class MulitPersonalites extends Person, otherPerson
{
var $currPerson;
function MulitPersonalites()
{
parent::Person(Jake);
parent::OtherPerson(Miles);
}
function Person::hello()
{
return super() . from multi;
}
function hello()
{
if($this-currPerson == Jake)
$this-Person::hello();
else
$this-OtherPerson::hello();
}
}
what ever the syntax should be
don't forget about the public private
Multi threading:
I know this is a huge change but.. again i think it is a good thing.
Case Sensitive:
I know the reasons for and against this and i agree with both of them. But I
would rather see CS.
For the most part the only argument against these is do we need it and it
will make things slower. Maybe somepeople do maybe somepeople don't but if
someone thinks they need it then probally others do too, how much slower
will
some of these changes make the engine?
Re: [PHP-DEV] Re: [Zend Engine 2] PHP in the future
Aggregation sometimes involves delegation. The 'parent' object delegates requests to the right aggregated objects (in other cases, the 'parent' object returns its aggregated objects and you use them directly). Zeev At 10:43 PM 6/6/2002, Sebastian Bergmann wrote: Andi Gutmans wrote: The talk was about aggregation of instances of classes with auto-proxy. I think that's called delegation, not aggregation. Have a look at what the JavaLab guys at my University are doing under the term delegation: http://javalab.cs.uni-bonn.de/research/darwin/ and http://javalab.cs.uni-bonn.de/research/darwin/delegation_eng.html It'd be cool to have something like that in PHP :-) -- 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
