Greg I completly aggree, but dont miss the point that I'M adigted to OOP
WHY NOT A FRAMEWORK CLOSER TO THE REAL POINT CALLED DOM
design pattern for HTML XHTML XML SVG Database conection and retrieving.
WHY CLASSES FOR CALLERS AND RECEIVERS AND INTERPRETERS.
a <div> is it a caller? a receiver?
why there a only dom classes? why not forgetting about the tag shit and a
bunch of classes for it?
well wait I will come up with it if I find ever the time and stop learning
from this list.
I also believe that u can force a good "design patter" by supplying a some
good very well design base classes. I mean talk to an JAVA freak, I dont
think they will come up with that type of framework.
as we just talking about that when can we expect PHP to extend unlimited
classes in one class.
for the newbies following the bullheaded experts fight:
something like this
class wow extents database, users, accessright implements HTML {
}
WHEN
"Greg Beaver" <greg@xxxxxxxxxxxxxxxxx> wrote in message
news:4A84460D.3080705@xxxxxxxxxxxxxxxxxxxx
> Robert Cummings wrote:
> >
> >
> > Martin Zvarík wrote:
> >> Ralph Deffke napsal(a):
> >>> NO NO NO
> >>>
> >>> OOP is the best ever inventet !!!!!
> >>>
> >>> see my comments on this list, I will also come up with an pure oop
> >>> opensource OMS very soon.
> >>>
> >>> I just think a dam big pattern catalog like this one is like an
elephant
> >>> chacing mice. I mean I can think of customers asking for a
> >>> documentation of
> >>> course of the page u created for them calling the next day asking
> >>> wher the
> >>> hell are the code for the page are documented in the 1000 pages of
> >>> documentation u had to give them.
> >>>
> >>> I can think of two of my largest customers with their intranet
> >>> application
> >>> with 23000 members and more then 50000 hits during working hours where
I
> >>> startet sweating while figting for every 1ms.
> >>>
> >>> I'm thinking of people with even more hits a day, they even dont
> >>> start using
> >>> PHP
> >>> so I dont know if thats the right way to blow up with includes and
> >>> thousands of classes.
> >>
> >> I deeply and completely agree.
> >
> > Yes, certainly optimize on an as-needed basis. But well written PHP code
> > should certainly scale quite well horizontally. Extremely traffic laden
> > websites are quite likely to see a bottleneck at the database before a
> > bottleneck in the code.
>
> Hi,
>
> You all should understand that on high traffic sites, C or C++ is far
> more frequently used and called "PHP" because they use a whole lot of
> custom extensions to speed things up. In addition, memcached speeds up
> database access so much that the speed of PHP starts to matter. This is
> why PHP 5.3.0 is somewhere around 30% faster than any previous PHP
> version when running common applications, because the core developers
> realized that the base efficiency begins to matter and spent
> considerable effort improving basic language performance.
>
> There are a lot of ways to improve PHP's efficiency, and arguing over
> whether to use design patterns is not a particularly effective one.
> Profiling early and often to understand the slowest portions of your
> code is an effective method. There are many, many talks/videos/etc.
> that can be found via google.com which discuss these principles, but
> suffice to say that xdebug, APC, and most importantly siege and apache
> benchmark are your friends in this endeavor.
>
> For Ralph: it might help you to know that facebook.com improved their
> performance by splitting up things into lots and lots of classes, and
> using autoload. I don't have specific details because I don't work
> there, but the programmer who coded this solution was telling me the
> generalities at php|tek 2 years ago. The pages that saw improvement
> were ones with a large number of possible execution branches in
> different requests. autoload simply reduced the number of needed files
> to the bare minimum from a wide variety of choices.
>
> This surprised me, because the prevailing opinion at the time was that
> autoload always reduces performance. The point to take from this story
> is that what you think to be true doesn't matter, the only thing is
> really understanding where your bottlenecks are by profiling
> aggressively, and even more important, why its slow, so you can fix it.
>
> Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
