PHP5 object model
8 отговора
489 прегледа
Re: PHP5 object model
e aide sega, bez izhwyrlqne
pyrwo nqma kak da e taka (celite, nujdite i specifikata na ezicite sa sywsem razlichni) i wtoro, poradi pyrwoto, mnogo neshta nqma da gi ima (kakto se widq, poradi problemi w implementaciqta, primerno, otpadnaha namespace definiciite)
pyrwo nqma kak da e taka (celite, nujdite i specifikata na ezicite sa sywsem razlichni) i wtoro, poradi pyrwoto, mnogo neshta nqma da gi ima (kakto se widq, poradi problemi w implementaciqta, primerno, otpadnaha namespace definiciite)
Re: PHP5 object model
razbiram, che mnogo ti se iska da e kato C++, ama nqma kak da stane
( ako iskash neshto po-taka, pisha na Python, Ruby, Java ili .... C++ ;) )
shte ti postna malko citati ot samiq zeev, koito mojesh i sam da otkriesh na zend.com
"
Will the new focus on object-oriented advancements pull PHP away from it's procedural roots?
No. Since PHP started out as a procedural language, it will always stay that way. The new objects abilities are being added because that's what the PHP user base it looking for right now.
Will there be a PHP 5.NET language (like VB.NET C#.NET) for Microsoft .NET Platform in the nearby future ?
Dynamic scripting languages such as PHP don't map well into Microsoft's IL. While it may be possible to come up with such an implementation, it will most probably not include all of the features of PHP, and will be very inefficient. It all boils down to a simple answer - 'no'.
Will PHP target enterprise level application architectures? E.g. will a PHP application server to maintain a persistent object model be available, releasing PHP from it's tightly bound CGI-lifecycle?
We don't plan to come up with a J2EE-like application server that's based on PHP. Certain elements in the Zend Engine 2 make it easier to write persistency frameworks for objects, so these are bound to show up sooner or later. You can also try and take a look at SRM ([линк]), although it's not production quality at this point.
Will PHP 5 incorporate multithreading or multiprocessing like Java does with Threads? This will certainly be a very hand feature for CLI based applications, especially server type software.
We don't plan to add threading support to PHP at this point. The focus of PHP remains dynamic web pages. Several people have experimented with adding threading support for PHP - you can test it yourself by trying PECL/threads (experimental).
Is it true that you have decided not to include namespaces, and will you reconsider implementing namespaces at some later date?
Namespaces as well as nested classes were secluded from PHP 5 because they don't map well to PHP, and the gain they bring is not significant, versus the amount of complexity they add to the language. Since I don't expect this to change at a later date, I don't expect to see namespaces in PHP in the future.
Are you considering allowing developers to strongly type (optional!) so that one can force a class to have a member variable that must be an integer, character or some class, but not necessarily be instantiated?
class something {
private string status
private int count
}
We won't have strong typing in PHP, ever, but we do have 'type hints' in PHP 5 for function arguments. I doubt they'll extend to object members, but we need to think about it.
The method _set and _get looks like the properties construct in C#, a data member overload. Is there a way in PHP 5 to overload operator and indexes? I think it would be a nice feature to build easy to use classes
Example:
class MyClass { // overload the + operator
public function _plus(){
return new
MyClass(+);
} // overload index operator
public function _index() {
return [];
}
}
=new MyClass(); =+; =;
PHP is not going to have operator overloading, so something like _plus or operator+ is not going to exist in PHP. As for being able to intercept index references - we still haven't decided how to do it exactly, but we do expect to have a solution for that by the time PHP 5 ships.
I noticed you mentioned that PHP does NOT have plans to incorporate any kind of overloading. Are you saying that function overloading is never going to be implemented? This is very dissappointing if it is the case.
Never is a long time, but yes, we don't have plans to ever support function overloading in PHP.
"
There are dozens of different features that don't exist in PHP, and for each such feature, I'm sure you'd find a bunch of people that will be disappointed to see that PHP doesn't have them. It doesn't mean that all of those features will make it into PHP - PHP is a language at its own merit, and like with any other language - we make choices as to what to include in it and what not to include. Polymorphism through function overloading doesn't map well to PHP because of its dynamic nature. Operator overloading, if that's what you meant, is a battered subject over which there are big debates. We decided that we acknowledge the disadvantages of operator overloading more than we buy into their benefits, especially in the context of web programming.
t.e. ne ostana mnogo ot c++, wypreki towa wsichki prodyljawame da si hareswame i polzwame PHP, zashtoto si wyrshi dobre rabotata za "obshtite mi prikazki"
( ako iskash neshto po-taka, pisha na Python, Ruby, Java ili .... C++ ;) )
shte ti postna malko citati ot samiq zeev, koito mojesh i sam da otkriesh na zend.com
"
Will the new focus on object-oriented advancements pull PHP away from it's procedural roots?
No. Since PHP started out as a procedural language, it will always stay that way. The new objects abilities are being added because that's what the PHP user base it looking for right now.
Will there be a PHP 5.NET language (like VB.NET C#.NET) for Microsoft .NET Platform in the nearby future ?
Dynamic scripting languages such as PHP don't map well into Microsoft's IL. While it may be possible to come up with such an implementation, it will most probably not include all of the features of PHP, and will be very inefficient. It all boils down to a simple answer - 'no'.
Will PHP target enterprise level application architectures? E.g. will a PHP application server to maintain a persistent object model be available, releasing PHP from it's tightly bound CGI-lifecycle?
We don't plan to come up with a J2EE-like application server that's based on PHP. Certain elements in the Zend Engine 2 make it easier to write persistency frameworks for objects, so these are bound to show up sooner or later. You can also try and take a look at SRM ([линк]), although it's not production quality at this point.
Will PHP 5 incorporate multithreading or multiprocessing like Java does with Threads? This will certainly be a very hand feature for CLI based applications, especially server type software.
We don't plan to add threading support to PHP at this point. The focus of PHP remains dynamic web pages. Several people have experimented with adding threading support for PHP - you can test it yourself by trying PECL/threads (experimental).
Is it true that you have decided not to include namespaces, and will you reconsider implementing namespaces at some later date?
Namespaces as well as nested classes were secluded from PHP 5 because they don't map well to PHP, and the gain they bring is not significant, versus the amount of complexity they add to the language. Since I don't expect this to change at a later date, I don't expect to see namespaces in PHP in the future.
Are you considering allowing developers to strongly type (optional!) so that one can force a class to have a member variable that must be an integer, character or some class, but not necessarily be instantiated?
class something {
private string status
private int count
}
We won't have strong typing in PHP, ever, but we do have 'type hints' in PHP 5 for function arguments. I doubt they'll extend to object members, but we need to think about it.
The method _set and _get looks like the properties construct in C#, a data member overload. Is there a way in PHP 5 to overload operator and indexes? I think it would be a nice feature to build easy to use classes
Example:
class MyClass { // overload the + operator
public function _plus(){
return new
MyClass(+);
} // overload index operator
public function _index() {
return [];
}
}
=new MyClass(); =+; =;
PHP is not going to have operator overloading, so something like _plus or operator+ is not going to exist in PHP. As for being able to intercept index references - we still haven't decided how to do it exactly, but we do expect to have a solution for that by the time PHP 5 ships.
I noticed you mentioned that PHP does NOT have plans to incorporate any kind of overloading. Are you saying that function overloading is never going to be implemented? This is very dissappointing if it is the case.
Never is a long time, but yes, we don't have plans to ever support function overloading in PHP.
"
There are dozens of different features that don't exist in PHP, and for each such feature, I'm sure you'd find a bunch of people that will be disappointed to see that PHP doesn't have them. It doesn't mean that all of those features will make it into PHP - PHP is a language at its own merit, and like with any other language - we make choices as to what to include in it and what not to include. Polymorphism through function overloading doesn't map well to PHP because of its dynamic nature. Operator overloading, if that's what you meant, is a battered subject over which there are big debates. We decided that we acknowledge the disadvantages of operator overloading more than we buy into their benefits, especially in the context of web programming.
t.e. ne ostana mnogo ot c++, wypreki towa wsichki prodyljawame da si hareswame i polzwame PHP, zashtoto si wyrshi dobre rabotata za "obshtite mi prikazki"
Re: PHP5 object model
> razbiram, che mnogo ti se iska da e kato C++, ama nqma kak da stane
ГОворих за обектния модел че _вече_ е като този на C++.
"
> Will the new focus on object-oriented advancements pull PHP away from it's
> procedural roots?
> No. Since PHP started out as a procedural language, it will always stay that way.
> The new objects abilities are being added because that's what the PHP user
> base it looking for right now.
Тoва по никакъв начин не пречи обектите на PHP да са като тези на C++
> Will there be a PHP 5.NET language (like VB.NET C#.NET) for Microsoft .NET
> Platform in the nearby future ?
> Dynamic scripting languages such as PHP don't map well into Microsoft's IL. While
> it may be possible to come up with such an implementation, it will most probably
> not include all of the features of PHP, and will be very inefficient. It all boils down > to a simple answer - 'no'.
Това няма нищо общо с обектния модел на C++.
> Will PHP target enterprise level application architectures? E.g. will a PHP
> application server to maintain a persistent object model be available, releasing
> PHP from it's tightly bound CGI-lifecycle?
> We don't plan to come up with a J2EE-like application server that's based on
> PHP. Certain elements in the Zend Engine 2 make it easier to write persistency
> frameworks for objects, so these are bound to show up sooner or later. You can
> also try and take a look at SRM ([линк]), although it's not
> production quality at this point.
C++ също няма "persistent object model", т.е. един C++ CGI скрипт има същите проблеми както и един PHP скрипт. Що се отнася до наличието на persistent обекти за PHP, то няма нужда да са част от езика, достатъчно е че има деструктори, и ще се появят готови библиотеки, които да позволят persistent обекти.
> Will PHP 5 incorporate multithreading or multiprocessing like Java does with
> Threads? This will certainly be a very hand feature for CLI based applications,
> especially server type software.
> We don't plan to add threading support to PHP at this point. The focus of PHP
> remains dynamic web pages. Several people have experimented with adding
> threading support for PHP - you can test it yourself by trying PECL/threads
> (experimental).
Многонишковостта също няма нищо общо с обектния модел. Двете са просто независими едно от друго. C++ стандарта също не споменава нищо за нишките, а сано загатва на 1-2 места за тях.
> Is it true that you have decided not to include namespaces, and will you
> reconsider implementing namespaces at some later date?
> Namespaces as well as nested classes were secluded from PHP 5 because they
> don't map well to PHP, and the gain they bring is not significant, versus the
> amount of complexity they add to the language. Since I don't expect this to
> change at a later date, I don't expect to see namespaces in PHP in the future.
Тук не съм убеден, но мисля, че по стандарт неймспейсовете пак са независими от обектния модел във C++. Вложените класове са единствената разлика, която виждам досега между PHP и C++.
> Are you considering allowing developers to strongly type (optional!) so that one
> can force a class to have a member variable that must be an integer, character
> or some class, but not necessarily be instantiated?
> class something {
> private string status
> private int count
> }
> We won't have strong typing in PHP, ever, but we do have 'type hints' in PHP 5
> for function arguments. I doubt they'll extend to object members, but we need
> to think about it.
Строгото типизиране при C++ пак не е част от обектния модел.
> The method _set and _get looks like the properties construct in C#, a data
> member overload. Is there a way in PHP 5 to overload operator and indexes? I
> think it would be a nice feature to build easy to use classes
> Example:
> class MyClass { // overload the + operator
> public function _plus(){
> return new
> MyClass(+);
> } // overload index operator
> public function _index() {
> return [];
> }
> }
> =new MyClass(); =+; =;
> PHP is not going to have operator overloading, so something like _plus or
> operator+ is not going to exist in PHP. As for being able to intercept index
> references - we still haven't decided how to do it exactly, but we do expect to
> have a solution for that by the time PHP 5 ships.
Липсата на предефиниране на оператори е втора разлика.
> I noticed you mentioned that PHP does NOT have plans to incorporate any kind
> of overloading. Are you saying that function overloading is never going to be
> implemented? This is very dissappointing if it is the case.
> Never is a long time, but yes, we don't have plans to ever support function
> overloading in PHP.
Aха. То преди време някои разработчици бяха казали че и деструктори няма да има а се оказа, че все пак добавиха.
"
> Polymorphism through function overloading doesn't map well to PHP because of
> its dynamic nature.
И със сегашните възможности на езика не е никакъв проблем да се симулира полиморфизъм така, че според мен това не е никакъв недостатък.
> t.e. ne ostana mnogo ot c++,
Видях само 2 съществени разлики, за сметка на всички други характеристики които съвпадат - наследяване (включително и множествено ако смятаме интерфейсите), полиморфизъм, public/protected/private капсулиране, конструктори/деструктори, накратко почти всичко, което го има и в C++ обектите.
> wypreki towa wsichki prodyljawame da si
> hareswame i polzwame PHP, zashtoto si wyrshi dobre rabotata za "obshtite mi
> prikazki"
Приказките са си приказки, работата си е работа :-> На мен примерно деструкторите ми вършат чудесна работа и няма нужда да се мъча със симулирането им чрез регистриране на shutdown функции.
ГОворих за обектния модел че _вече_ е като този на C++.
"
> Will the new focus on object-oriented advancements pull PHP away from it's
> procedural roots?
> No. Since PHP started out as a procedural language, it will always stay that way.
> The new objects abilities are being added because that's what the PHP user
> base it looking for right now.
Тoва по никакъв начин не пречи обектите на PHP да са като тези на C++
> Will there be a PHP 5.NET language (like VB.NET C#.NET) for Microsoft .NET
> Platform in the nearby future ?
> Dynamic scripting languages such as PHP don't map well into Microsoft's IL. While
> it may be possible to come up with such an implementation, it will most probably
> not include all of the features of PHP, and will be very inefficient. It all boils down > to a simple answer - 'no'.
Това няма нищо общо с обектния модел на C++.
> Will PHP target enterprise level application architectures? E.g. will a PHP
> application server to maintain a persistent object model be available, releasing
> PHP from it's tightly bound CGI-lifecycle?
> We don't plan to come up with a J2EE-like application server that's based on
> PHP. Certain elements in the Zend Engine 2 make it easier to write persistency
> frameworks for objects, so these are bound to show up sooner or later. You can
> also try and take a look at SRM ([линк]), although it's not
> production quality at this point.
C++ също няма "persistent object model", т.е. един C++ CGI скрипт има същите проблеми както и един PHP скрипт. Що се отнася до наличието на persistent обекти за PHP, то няма нужда да са част от езика, достатъчно е че има деструктори, и ще се появят готови библиотеки, които да позволят persistent обекти.
> Will PHP 5 incorporate multithreading or multiprocessing like Java does with
> Threads? This will certainly be a very hand feature for CLI based applications,
> especially server type software.
> We don't plan to add threading support to PHP at this point. The focus of PHP
> remains dynamic web pages. Several people have experimented with adding
> threading support for PHP - you can test it yourself by trying PECL/threads
> (experimental).
Многонишковостта също няма нищо общо с обектния модел. Двете са просто независими едно от друго. C++ стандарта също не споменава нищо за нишките, а сано загатва на 1-2 места за тях.
> Is it true that you have decided not to include namespaces, and will you
> reconsider implementing namespaces at some later date?
> Namespaces as well as nested classes were secluded from PHP 5 because they
> don't map well to PHP, and the gain they bring is not significant, versus the
> amount of complexity they add to the language. Since I don't expect this to
> change at a later date, I don't expect to see namespaces in PHP in the future.
Тук не съм убеден, но мисля, че по стандарт неймспейсовете пак са независими от обектния модел във C++. Вложените класове са единствената разлика, която виждам досега между PHP и C++.
> Are you considering allowing developers to strongly type (optional!) so that one
> can force a class to have a member variable that must be an integer, character
> or some class, but not necessarily be instantiated?
> class something {
> private string status
> private int count
> }
> We won't have strong typing in PHP, ever, but we do have 'type hints' in PHP 5
> for function arguments. I doubt they'll extend to object members, but we need
> to think about it.
Строгото типизиране при C++ пак не е част от обектния модел.
> The method _set and _get looks like the properties construct in C#, a data
> member overload. Is there a way in PHP 5 to overload operator and indexes? I
> think it would be a nice feature to build easy to use classes
> Example:
> class MyClass { // overload the + operator
> public function _plus(){
> return new
> MyClass(+);
> } // overload index operator
> public function _index() {
> return [];
> }
> }
> =new MyClass(); =+; =;
> PHP is not going to have operator overloading, so something like _plus or
> operator+ is not going to exist in PHP. As for being able to intercept index
> references - we still haven't decided how to do it exactly, but we do expect to
> have a solution for that by the time PHP 5 ships.
Липсата на предефиниране на оператори е втора разлика.
> I noticed you mentioned that PHP does NOT have plans to incorporate any kind
> of overloading. Are you saying that function overloading is never going to be
> implemented? This is very dissappointing if it is the case.
> Never is a long time, but yes, we don't have plans to ever support function
> overloading in PHP.
Aха. То преди време някои разработчици бяха казали че и деструктори няма да има а се оказа, че все пак добавиха.
"
> Polymorphism through function overloading doesn't map well to PHP because of
> its dynamic nature.
И със сегашните възможности на езика не е никакъв проблем да се симулира полиморфизъм така, че според мен това не е никакъв недостатък.
> t.e. ne ostana mnogo ot c++,
Видях само 2 съществени разлики, за сметка на всички други характеристики които съвпадат - наследяване (включително и множествено ако смятаме интерфейсите), полиморфизъм, public/protected/private капсулиране, конструктори/деструктори, накратко почти всичко, което го има и в C++ обектите.
> wypreki towa wsichki prodyljawame da si
> hareswame i polzwame PHP, zashtoto si wyrshi dobre rabotata za "obshtite mi
> prikazki"
Приказките са си приказки, работата си е работа :-> На мен примерно деструкторите ми вършат чудесна работа и няма нужда да се мъча със симулирането им чрез регистриране на shutdown функции.
Re: PHP5 object model
ufff, shte otgoworq za posledno, che ei tyi minawam, sha zema da se registriram sledwashtiq pyt, a i neshto izbiva na karanica, koeto ne mi hareswa
pyrwo ti kaza, che PHP clasowete bili srawnimi po mosht sys c++ klasowete, a posle, che obektniq model bil kato na c++ (ako stava za wypros, horata priznawat, che wzimat ot model-a na java, a ne na c++)
znachi, wqrno che paste-nah nqkolko neshta ne po temata, no gi smetnah za interesni - smqtam go kato moq greshka
ta sega za c++, da ne prawim summary na towa, koeto sym pisal, a na towa, koeto e:
w PHP5 (za momenta, spored twoite pisanici, i za w bydeshte, spored Zeev) nqma
slednite neshta, koito sa zalojeni w c++ standards (ne goworim za emulirane obache, tyi kato towa ne e zalojeno w samoto PHP):
1. polimorphism
2. multiple inheritance (interface-ite sa java model, a ne c++)
3. namespaces
4. overloading
5. friendly neshtata
6. templates
7. virtual neshtata (ako ima final, to pak e wzeto ot java-ta)
e, mnogo e spored mene
towa e, koeto se seshtam w momenta, a i da ima oshte neshto, edwa li e fatalno
drug wypros e, che realiziraneto na povecheto ot tqh edwa li ima nqkakyw smisyl, koeto ot swoq strana me nawejda na misylta, che ot tolkowa izpisani prikazki pomejdu ni, edwa li ima nqkakyw smisyl ot tqh - kakto kazah celite i specifikata na php sa sywsem razlichni ot tezi na c++
pyrwo ti kaza, che PHP clasowete bili srawnimi po mosht sys c++ klasowete, a posle, che obektniq model bil kato na c++ (ako stava za wypros, horata priznawat, che wzimat ot model-a na java, a ne na c++)
znachi, wqrno che paste-nah nqkolko neshta ne po temata, no gi smetnah za interesni - smqtam go kato moq greshka
ta sega za c++, da ne prawim summary na towa, koeto sym pisal, a na towa, koeto e:
w PHP5 (za momenta, spored twoite pisanici, i za w bydeshte, spored Zeev) nqma
slednite neshta, koito sa zalojeni w c++ standards (ne goworim za emulirane obache, tyi kato towa ne e zalojeno w samoto PHP):
1. polimorphism
2. multiple inheritance (interface-ite sa java model, a ne c++)
3. namespaces
4. overloading
5. friendly neshtata
6. templates
7. virtual neshtata (ako ima final, to pak e wzeto ot java-ta)
e, mnogo e spored mene
towa e, koeto se seshtam w momenta, a i da ima oshte neshto, edwa li e fatalno
drug wypros e, che realiziraneto na povecheto ot tqh edwa li ima nqkakyw smisyl, koeto ot swoq strana me nawejda na misylta, che ot tolkowa izpisani prikazki pomejdu ni, edwa li ima nqkakyw smisyl ot tqh - kakto kazah celite i specifikata na php sa sywsem razlichni ot tezi na c++
Защо се карате ?
Или по-точно защо се заяждате за дреболии. Въпроса е, че PHP със всяка версия става все по-добър и по-хубав - е това трябва само да ни радва. Това, че е различен от Java и C++ е безспорен факт, но и огромните прилики, понеже са на еднакви основи - пак е безспорен факт (никой не отрича че "тези" от Java 
пък взимат от модела на C++ ).
Та обектите стават по-мощни - СУПЕР !!!
Време е да им използваме мощта (стана като лозунг)
пък взимат от модела на C++ ).
Та обектите стават по-мощни - СУПЕР !!!
Време е да им използваме мощта
(стана като лозунг) Re: PHP5 object model
> a i neshto izbiva na karanica
Не и според мен. Ако някоя от репликите ми е прозвучала като караница не е било преднамерено.
Както и да е спирам със спора дотук, защото нямам времето да отговарям на всяка точка. Може би някой път ще продължа спора... Трябва да боря последния CVS snapshot на PHP5. Успешно писане на код на всички в клуба :-)
Не и според мен. Ако някоя от репликите ми е прозвучала като караница не е било преднамерено.
Както и да е спирам със спора дотук, защото нямам времето да отговарям на всяка точка. Може би някой път ще продължа спора... Трябва да боря последния CVS snapshot на PHP5. Успешно писане на код на всички в клуба :-)