On Sun, 2004-11-14 at 13:27, -{ Rene Brehmer }- wrote:
> At 17:14 14-11-2004, Robert Cummings wrote:
> >On Sun, 2004-11-14 at 09:30, -{ Rene Brehmer }- wrote:
> > > Just remember that PHP isn't a true OOP language, so going OOP may not
> >
> >Please define "true OOP" language and provide a few examples that meet
> >your criteria. Then show how other examples like PHP fail to meet your
> >true OOP criteria. Don't forget, if a language has OOP as a subset, it
> >still has true OOP capabilities. Also it might help to clarify if you
> >mean PHP in general or PHP4 and below.
>
> "True" as in parts of the OOP not being optional, like it is in PHP. You
> can fudge around the OOP principle in PHP and still get it working.
"True OOP" is a programming paradigm you can choose or not choose to
adhere to. Even in a purist OOP model, some person could implement their
entire application in a procedural manner by creating a single "Program"
object and using that object's methods as though they were non OOP
procedures. So thusly, if I choose to only use OOP features in my code,
then PHP is as pure as any other pure OOP model, by your own
understanding. Thus the ability of PHP to be OOP is entirely dependent
on the developer.
> > > necessarily be the best solution always. OOP makes certain types of
> > > projects easier to code, and some projects would be almost impossible
> > to do
> > > without OOP (like anything you wanna do where you need to use scope to
> > > avoid major headaches), but because PHP isn't compiled or a true OOP
> >
> >PHP is runtime compiled to bytecode. It's just as compiled as any other
> >language. With a good compiler cache it's just as compiled as java.
>
> Compiled to byte-code is only the same as pre-compiled in most other
> programming languages.
Semantics. Until any langiage compiles to pure 1s and 0s, it's all about
bytecode. Even C compiles to assembler which is really just a low level
bytecode.
> > > language, OOP in PHP hampers performance, and that hampering is
> > exponential
> > > with the complexity of the objects.
> >
> >You're shitting us all right? Exponential? Really? could you show us
> >some benchmarks on how it's exponential?
>
> Dynamic object creation will always hamper performance relative to the
> object complexity. It's true for all languages ... it's within seconds
> though on a non-dedicated server, but depending on what you do, it's not
> that hard to break 30 secs exec time on PHP that way.
There is a performance loss in any OOP system over a non OOP system,
because the great things like polymorphism have a pricetag. However,
your original comment specifically narrowed the field of attention to
PHP, which is not valid narrowing since it makes it seem like there are
OOP implementations that do not have performance overhead for such
features. If there are, I'm sure you can tell me a few.
>
> >Let's not be sowing seeds of FUD on the PHP general list.
>
> Then it might be good to read instead of interpret.
To read is to interpret. Otherwise you're just looking. You moment you
give anything meaning you have made an interpretation. Albeit the
interpretation may be based on globally shared rules, or personal
subjective ideals. Either way, your writing was not IMHO based on
globally shared rules, but rather on your own personal subjective
ideals, which again IMHO, were promoting FUD for PHP OOP.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
