PHP and large projects

[Hayden Kirk]

I've used PHP for many smaller projects, but now im embarking on large
corporate websites.

After reading this:

http://www.ukuug.org/events/linux2002/papers/html/php/index.html

PHP does not sound like the right language for large scale sites. My main
concern was Namespaces...

What would you suggest any why?

My application is relying heavily on databases, with around 200-500
co-current people using it at any one time,

[Rutger Claes]

Re: PHP and large projects

Hayden Kirk wrote:
[color=blue]
> I've used PHP for many smaller projects, but now im embarking on large
> corporate websites.
>
> After reading this:
> http://www.ukuug.org/events/linux200...php/index.html
>
> PHP does not sound like the right language for large scale sites. My main
> concern was Namespaces...[/color]

This is fixed in PHP5, you can use Static methods as namespaces.
And you can introduce your own package naming:
class db_mysql_Connec tion is the class for connections in the mysql package,
while the mysql package is a part of the db package.
The location of this file could be:
/db/mysql/connection.clas s.php

This way you can use the auto loader function...
[color=blue]
> What would you suggest any why?
>
> My application is relying heavily on databases, with around 200-500
> co-current people using it at any one time,[/color]
--
Rutger Claes rgc@rgc.tld
Replace tld with top level domain of belgium to contact me pgp:0x3B7D6BD6
Do not reply to the from address. It's read by /dev/null and sa-learn only

[Tony Marston]

Re: PHP and large projects

I have read that article and IMHO it smacks of failures at the
designer/developer level, not the language.

(1) Separation of Presentation from Business Logic

It is not a function of PHP, or ANY language for that matter, to provide
out-of-the box separation of presentation and business logic. It is up to
the designer/developer to create his/her own infrastructure. I have built my
own which is described in
http://www.tonymarston.co.uk/php-mys...structure.html. Other people
have built their own infrastructures which work along completely different
lines. There is no "one size fits all" that is built into PHP, you have to
plug in one of your choosing.

(2) Using a Team of Developers

Just because PHP gives you the ability to redefine functions does not mean
that you HAVE to use this ability. It should be used when absolutely
necessary. Any such failures are due to lack of discipline among the
developers and NOT a failure with the language.

This so-called "namespace problem" is really getting on my wick. I have
programmed with various language over the past 25+ years and none of them
used namespaces, therefore I do not miss them. I do not see what problem is
caused by the lack of namespaces, therefore I do not see the need for a
solution. Just because a previous language you may have used had namespaces
does not mean that PHP should have exactly the ame feature which works in
exactly the same way. PHP is a diferent language. Learn the differences and
live with them, otherwise go back to your previous language.

(3) Deployment Problems

So PHP allows the developer to change configuration settings? Big deal. If a
developer screws up it is a developer problem, not a language problem.

The restriction of only one php.ini file per web server has workarounds
which are clearly documented.
- You can use ini_set() within individual scripts to change standard
settings.
- You can use .htaccess files within individual directories to change
settings.

As for the fact that you cannot rely on a particular web hosting company to
have the most current version of PHP with all the required set of extensions
loaded, this has got absolutely nothing to do with the language. If your web
hosting company cannot supply what you require then switch to a different
company.

(4) Oversimplificat ion Leading to Excessive Complexity

Every language evolves. Nothing is created perfect first time. The fact that
PHP is now a collaborative effort of many talented programmers instead of
just one or two cannot be held up as a disadvantage or a failing.

The fact that funtion names do not follow a consistent pattern is not a
problem. I agree that some tidying up may be a good idea, but it does not
stop me, or millions of other developers, from using the language to build
web pages. Different languages have different naming conventions, but that
does not prevent those languages from being used successfully.

The comments on arrays shows that you are fixated on how arrays are handled
in another language. Well, I have news for you - PHP is not that other
language. It is different. Get used to it. If you have a problem when using
arrays in PHP then the failure is yours and not a failure in the language.

This constant comparison with other languages is a waste of time. I have
used many languages in my long career, and I have had to get used to the
differences. Some things are easier to achieve, some things are harder, but
that is what you should expect from a different languages. There is a
different set of commands, a different set of capabilities. If you don't
like the differences then stick with your previous language, but for Pete's
sake STOP COMPLAINING ABOUT THE DIFFERENCES. If these differences give you a
problem then the problem lies with you, not the language.

Rant over.

--
Tony Marston

http://www.tonymarston.net

[color=blue]
> "Hayden Kirk" <hayden90@hotma il.com> wrote in message
> news:9JJId.1066 3$mo2.809748@ne ws.xtra.co.nz.. .
> I've used PHP for many smaller projects, but now im embarking on large
> corporate websites.
>
> After reading this:
> http://www.ukuug.org/events/linux200...php/index.html
>
> PHP does not sound like the right language for large scale sites. My main
> concern was Namespaces...
>
> What would you suggest any why?
>
> My application is relying heavily on databases, with around 200-500
> co-current people using it at any one time,[/color]

[Hayden Kirk]

Re: PHP and large projects

Good explanation.

Thanks.

"Tony Marston" <tony@NOSPAM.de mon.co.uk> wrote in message
news:ct0306$l4h $1$8302bc10@new s.demon.co.uk.. .[color=blue]
>I have read that article and IMHO it smacks of failures at the
>designer/developer level, not the language.
>
> (1) Separation of Presentation from Business Logic
>
> It is not a function of PHP, or ANY language for that matter, to provide
> out-of-the box separation of presentation and business logic. It is up to
> the designer/developer to create his/her own infrastructure. I have built
> my own which is described in
> http://www.tonymarston.co.uk/php-mys...structure.html. Other people
> have built their own infrastructures which work along completely different
> lines. There is no "one size fits all" that is built into PHP, you have to
> plug in one of your choosing.
>
> (2) Using a Team of Developers
>
> Just because PHP gives you the ability to redefine functions does not mean
> that you HAVE to use this ability. It should be used when absolutely
> necessary. Any such failures are due to lack of discipline among the
> developers and NOT a failure with the language.
>
> This so-called "namespace problem" is really getting on my wick. I have
> programmed with various language over the past 25+ years and none of them
> used namespaces, therefore I do not miss them. I do not see what problem
> is caused by the lack of namespaces, therefore I do not see the need for a
> solution. Just because a previous language you may have used had
> namespaces does not mean that PHP should have exactly the ame feature
> which works in exactly the same way. PHP is a diferent language. Learn the
> differences and live with them, otherwise go back to your previous
> language.
>
> (3) Deployment Problems
>
> So PHP allows the developer to change configuration settings? Big deal. If
> a developer screws up it is a developer problem, not a language problem.
>
> The restriction of only one php.ini file per web server has workarounds
> which are clearly documented.
> - You can use ini_set() within individual scripts to change standard
> settings.
> - You can use .htaccess files within individual directories to change
> settings.
>
> As for the fact that you cannot rely on a particular web hosting company
> to have the most current version of PHP with all the required set of
> extensions loaded, this has got absolutely nothing to do with the
> language. If your web hosting company cannot supply what you require then
> switch to a different company.
>
> (4) Oversimplificat ion Leading to Excessive Complexity
>
> Every language evolves. Nothing is created perfect first time. The fact
> that PHP is now a collaborative effort of many talented programmers
> instead of just one or two cannot be held up as a disadvantage or a
> failing.
>
> The fact that funtion names do not follow a consistent pattern is not a
> problem. I agree that some tidying up may be a good idea, but it does not
> stop me, or millions of other developers, from using the language to build
> web pages. Different languages have different naming conventions, but that
> does not prevent those languages from being used successfully.
>
> The comments on arrays shows that you are fixated on how arrays are
> handled in another language. Well, I have news for you - PHP is not that
> other language. It is different. Get used to it. If you have a problem
> when using arrays in PHP then the failure is yours and not a failure in
> the language.
>
> This constant comparison with other languages is a waste of time. I have
> used many languages in my long career, and I have had to get used to the
> differences. Some things are easier to achieve, some things are harder,
> but that is what you should expect from a different languages. There is a
> different set of commands, a different set of capabilities. If you don't
> like the differences then stick with your previous language, but for
> Pete's sake STOP COMPLAINING ABOUT THE DIFFERENCES. If these differences
> give you a problem then the problem lies with you, not the language.
>
> Rant over.
>
> --
> Tony Marston
>
> http://www.tonymarston.net
>
>
>[color=green]
>> "Hayden Kirk" <hayden90@hotma il.com> wrote in message
>> news:9JJId.1066 3$mo2.809748@ne ws.xtra.co.nz.. .
>> I've used PHP for many smaller projects, but now im embarking on large
>> corporate websites.
>>
>> After reading this:
>> http://www.ukuug.org/events/linux200...php/index.html
>>
>> PHP does not sound like the right language for large scale sites. My main
>> concern was Namespaces...
>>
>> What would you suggest any why?
>>
>> My application is relying heavily on databases, with around 200-500
>> co-current people using it at any one time,[/color]
>
>[/color]

[Colin McKinnon]

Re: PHP and large projects

Tony Marston wrote:
[color=blue]
> I have read that article and IMHO it smacks of failures at the
> designer/developer level, not the language.
>[/color]

hehe

Just what I was going to say.

The only problem I have using PHP compared to other languages is that of
collisions in the namespace (use of 'namespaces' is just one solution to
this). It's far from insurmountable - strict rules on coding style will
solve it.

I'm sure some smrty will point out that this makes conformance optional -
but if you don't enforce coding standards in ANY language you're storing up
problems anyway.

Hayden Kirk wrote:[color=blue]
>
> My application is relying heavily on databases, with around 200-500
> co-current people using it at any one time,[/color]

....which has nothing to do with namespace problems, and everything to do
with scalability. PHP is the dog's danglies for this.

C.

(3 million hits/day, ~600000 lines of PHP code)

[Chung Leong]

Re: PHP and large projects


"Hayden Kirk" <hayden90@hotma il.com> wrote in message
news:9JJId.1066 3$mo2.809748@ne ws.xtra.co.nz.. .[color=blue]
>After reading this:
>http://www.ukuug.org/events/linux200...php/index.html
>
>PHP does not sound like the right language for large scale sites. My main
>concern was Namespaces...[/color]

Don't tell me you actually agree with this guy that the use of namespace
promotes teamwork? If Bob won't walk over to Joe to tell him that "hey, I
got a function that does this already," then Bob and Joe are not much of a
team.

Forget namespace and abstract stuff like separation of logic. Base your
decision on more concrete factors. I way I see it, it's a question of
performance vs. time to delivery. A site built using a more robust
technology like JSP will probably perform better and more stably. On the
other hand, building it with PHP will be a whole lot quicker.
[color=blue]
>My application is relying heavily on databases, with around 200-500
>co-current people using it at any one time,[/color]

Hmmm. That would give me some pause about using PHP. What is the nature of
this application? How many actual page hits are you expecting? 500
concurrent could mean 1 hit per second, or it could be 100.