PHP6 - Comments?

[R. Rajesh Jeba Anbiah]

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

[Aidan]

"R. Rajesh Jeba Anbiah" <ng**********@rediffmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

PHP6? WTF?

People have barely begun moving to PHP5... I mean, the latest stable version
is 5.0.4... four point releases since the major verion. I can't imagine
that there a good reason to start getting worked up about PHP6... I can't
even find a single reference to it on php.net.

Is this a troll, or FUD?

[Dimitry Rybkin]

TROLL.

Aidan wrote:

"R. Rajesh Jeba Anbiah" <ng**********@rediffmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

PHP6? WTF?

People have barely begun moving to PHP5... I mean, the latest stable version
is 5.0.4... four point releases since the major verion. I can't imagine
that there a good reason to start getting worked up about PHP6... I can't
even find a single reference to it on php.net.

Is this a troll, or FUD?

[Erwin Moller]

R. Rajesh Jeba Anbiah wrote:

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

Hi,

Thanks but that is old news.
We are releasing PHP 9.3 beta right now!

Get it here:
http://www.disneyland.com

Regards,
Erwin Moller

[Peter van Schie]

Aidan wrote:

People have barely begun moving to PHP5... I mean, the latest stable version
is 5.0.4... four point releases since the major verion. I can't imagine
that there a good reason to start getting worked up about PHP6... I can't
even find a single reference to it on php.net.

Is this a troll, or FUD?

Even though I agree that it's a little bit early to discuss PHP 6 when
PHP 5 is still wearing diapers, I don't think it's a troll.
If you do a Google search on "PHP 6" you'll find several references to
discussions about it.

Peter.
--
http://www.phpforums.nl

[Chung Leong]

I don't like the direction PHP is going. It seems to focus has shifted
from making a useful tool for building web sites to making a better
language. The two goals are not mutually exclusive, of course, but nor
do they completely overlap. As the cliche goes, people want
solutions--not technology. PHP seems to be going down the path of ASP,
where a simple useful tool become a hideous monster.

[Don Freeman]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I don't like the direction PHP is going. It seems to focus has shifted
from making a useful tool for building web sites to making a better
language. The two goals are not mutually exclusive, of course, but nor
do they completely overlap. As the cliche goes, people want
solutions--not technology. PHP seems to be going down the path of ASP,
where a simple useful tool become a hideous monster.

Agreed, the last thing I need is another language written by academics for
academics. When I discovered PHP, after struggling with Java for so long, I
was enamored with the joining of simplicity and functionality that PHP gave
me. If I want OOP I'll write a Java program, I don't need it in PHP also.

-Don

[Junx]

As far as I can tell, PHP 6 is basically just the "trunk" for
development right now. If they used the usual x.y.z naming convention,
it'd probably be PHP 5.3.x or something.

[R. Rajesh Jeba Anbiah]

Chung Leong wrote:

I don't like the direction PHP is going. It seems to focus has shifted
from making a useful tool for building web sites to making a better
language. The two goals are not mutually exclusive, of course, but nor
do they completely overlap. As the cliche goes, people want
solutions--not technology. PHP seems to be going down the path of ASP,
where a simple useful tool become a hideous monster.

I don't understand what are you referring. But, I don't see it's
getting monster anyway; many extensions have been moved to PECL. IMHO,
it is still to be tuned--even if you're solution centric. Say for
example, the function aliases are more redundant. I'm also for removal
of magic quotes and register globals.

[p.s. Will be away for next couple of days. And may not be able to
follow-up]

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

[R. Rajesh Jeba Anbiah]

Erwin Moller wrote:

R. Rajesh Jeba Anbiah wrote:

Nowadays in PHP world, the "noise" is about upcoming PHP6

<snip> Thanks but that is old news.
We are releasing PHP 9.3 beta right now!

You're humor is Greek and geek for me to grab:(

[p.s. Will be away for next couple of days. And may not be able to
follow-up]

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

[Lisa Pearlson]

Yes, I'm sure eventually there willbe PHP7, 8, 9 and 10 too.
The problem with wanting to move to the latest version, is that the latest
version is always the version after which the product gets discontinued :)

Not very attractive foresight. I'll stick to PHP 1.0
It's small footprint is ideal for "hello world" apps.. and that's all I ever
want to develop in any programming language hehe.

"R. Rajesh Jeba Anbiah" <ng**********@rediffmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

[NC]

Chung Leong wrote:

I don't like the direction PHP is going.
Neither do I. PHP used to be a tidy language for structured
programming where everything centered on strings. Then
someone decided it has to have OOP (although no one ever
bothered to explain why). In retrospect, I'd much rather
have a set of good quantitative libraries and a mechanism
for writing PHP extensions in PHP...
It seems to focus has shifted from making a useful tool
for building web sites to making a better language.
I'd say, PHP is getting "modern" (translation: more
fashionable), not necesarily better...
PHP seems to be going down the path of ASP, where a simple
useful tool become a hideous monster.

Fortunately, we are not there yet. OOP can still be avoided
if necessary. Reading a remote file still can be done in a
single file_get_contents(), as opposed to spawning a
HttpWebRequest/WebResponse pair in VB.NET. Most importantly,
string is still not an object.

Cheers,
NC

[Chung Leong]

I just think it's a good approach when you aim is improving the
language as opposed to increasing its usefulness. There is a subtle
difference. Removing function aliases, for example, improves the
language's consistency but doesn't make it more useful. I would say the
same thing about variable visibility and exception as well.

[Erwin Moller]

R. Rajesh Jeba Anbiah wrote:

Erwin Moller wrote:

R. Rajesh Jeba Anbiah wrote:

> Nowadays in PHP world, the "noise" is about upcoming PHP6

<snip>

Thanks but that is old news.
We are releasing PHP 9.3 beta right now!

You're humor is Greek and geek for me to grab:(

[p.s. Will be away for next couple of days. And may not be able to
follow-up]

Hehe, OK.
I was just being silly and wasting bandwidth.
I'll try to restrain myself in future, and first sit on my hands and wonder
for 1 minute if anybody actually want to read my comment before submitting.
:P

So consider my response as noise. ;-)

Regards,
Erwin Moller

[Erwin Moller]

Chung Leong wrote:

I just think it's a good approach when you aim is improving the
language as opposed to increasing its usefulness. There is a subtle
difference. Removing function aliases, for example, improves the
language's consistency but doesn't make it more useful. I would say the
same thing about variable visibility and exception as well.

Yes Chung, I 100% agree.
Who excactly is bothered by the fact that print and echo do the same thing?
Who? really?

I think the succes of PHP was caused excactly by its simplicity.
I come from Java (J2EE), and needed some time to get used to the 'loose
style' of PHP, but now I love it.
I hope the decisionmakers of PHP will focus on keeping it a simple and
easy-to-learn language.
An extensionmechanism is enough to cover a lot of 'complex requests' for
additional functionality (PECL/PEAR).
Please leave PHP roughly as it is, and just make nice classes.
The day PHP forces me to strongtype my variables, I might just switch back
to Java. :-/

Just my 2 cents.

Regards,
Erwin Moller

[Chung Leong]

The fact that they haven't rolled the Hardened PHP project into the
main project tells you something. For example, there is zero reason for
require/include to work with remote files. It is only useful for
hackers trying to break into poorly coded sites. AFAIK, it still works
in PHP 5.

The development of PHP should be guided by how it's used by PHP
developers, and not other languages. IMHO they're spending too much
time trying to please Java trolls.

[Csaba Gabor]

R. Rajesh Jeba Anbiah wrote:

Nowadays in PHP world, the "noise" is about upcoming PHP6
<http://phplens.com/phpeverywhere/?q=node/view/212>
<http://www.planet-php.net/>. Do c.l.php readers have any comments or
suggestions?

I've been using PHP 5 for about a year now. And there are some new
features that I find really useful:
A. SQLite, the built in database for small to midsized projects. This
simplifies security concerns (cause you don't have an extra server),
reduces overhead (cause you don't have an extra server), and each
database is self contained in a single file (portability) and not
reliant on additional installed software (mySql, for example).

B. Expanded features in array handling. Now many of the ways that I
want to handle array transformations / access are built in.
Admittedly, each of these routines is fairly easy to write, but it's
nice that PHP has reduced my overhead and provides them standard.

C. COM handling has really come a long way. I can get IE to display
an event driven interactive dialog box when I use CLI php.

But it is time to move on - there are still functional improvements
that I'd like to see in PHP 6. These are on my list of items that I
hope will make it in:

1. Top of the list: the ability to call Win API directly from PHP.
This is split up into two parts: a declare statement so that PHP will
build the "structure" to enable the call, and then the actual calls.
As with the revised COM functionality, PHP will hide most of the dirty
work in declaring / passing the variables. For server side PHP, each
Win API has to be specifically enabled and not available in safe mode

2. Ability to view the call stack and associated variables.
caller($n) returns an associative array of references to those
variables defined with the scope of the caller $n levels up the call
stack. Use 0 for the current function, 1 for the function that called
this one, -1 for the top level function. Within caller(),
__FUNCTION__, __FILE__, __LINE__, etc. are as you'd expect, where line
indicates the line that the function call happened on. Thus, if
$aStack1 = caller(1);, then $aStack1["__LINE__"] is the line of the
call to the current function and $aStack1["__FUNCTION__"] is the
function name that the call happened within.

3. Exporting PHP objects natively from running code. A class can be
designated as a COM server object (supporting events) so that it can be
instantiated with new COM("progID") from other (external) apps,
including distinct PHP instances. This allows interprocess PHP
communication on a native level. This type of interprocess
communication is already available via PHPScript or IE, but it would be
useful and more efficient to have it built into PHP instead of having
to simulate it.
Csaba Gabor from Vienna

[Oliver Grätz]

Chung Leong schrieb:

I don't like the direction PHP is going. It seems to focus has shifted
from making a useful tool for building web sites to making a better
language. The two goals are not mutually exclusive, of course, but nor
do they completely overlap. As the cliche goes, people want
solutions--not technology. PHP seems to be going down the path of ASP,
where a simple useful tool become a hideous monster.

The developers are well aware, that PHP has to be easy for starters.
Keeping it simple was a primary design goal for version 5. Things like
multiple inheritance of classes and namespaces were not added in PHP5,
because they complicate things.

Instead, the developers improved the performance of the Zend Engine and
added fun stuff like __call to the classes, that are almost "too
result-oriented" for academics. It's interpreted, we can do it, so let's
do it!

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name. The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.

Multiple inheritance will - as I guess - never be a part of PHP. It's a
concept that C++ programmers miss, since they're not following the basic
rule "favour composition over inheritance". OK, I think this sounds too
academic, so I'm not getting deeper into this issue.

And: Version 6 is not as far away as one might think since the
developers will directly go from version 5.1 to 6.0. The version after
5.1 will be a major release because great parts of the functions have to
be rewritten from scratch. PHP6 will feature transparent support for
Unicode which - because it has to stay simple - nobody will notice
unless he or she uses it.
AllOLLi

[Oliver Grätz]

NC schrieb:

Fortunately, we are not there yet. OOP can still be avoided
if necessary. Reading a remote file still can be done in a
single file_get_contents(),
OOP always seems to be "the bad guy". Sure, I like file_get_contents(),
especially if it's "file_get_contents('http://www.google.com');", but
what is so bad with

$myfile=new File('my-article.txt');
foreach($myfile as $line)
{
// do stuff
}
as opposed to spawning a
HttpWebRequest/WebResponse pair in VB.NET. Most importantly,
string is still not an object.

What is so bad about

$s=new String('this is a test');
echo $s->reverse();

against

$s='this is a test';
echo strrev($s);

It's absolutely the same. But the String class could tell you about it's
capabilities:

print_r(get_class_methods('String'));

The only thing bad about strings being objects is having to write more
code. In Ruby this isn't true, since strings are first class objects and
you can actually call methods on the strings:

print "this is a test".reverse

Even numbers are objects and they've got handy methods:

5.times print "Hello."

Objects are good. Period.
AllOLLi

[Chung Leong]

Oliver Grätz wrote:

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name. The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.

A symptom of what I was describing. Those who frequent this newsgroup
can testify to this, namespace collision is not a problem PHP
programmers are facing. Hell, I don't recall the last time someone
asked a PEAR related question--and that's the best known class library.
They are wasting their time pursuing the pipe dream of component
programming, which while sounding good in theory, is always thwarted by
programmers' tendency to write rubbish documentation.

I for one would rather have a new built-in datetime type that doesn't
suffer from the limitation of Unix timestamp. Now that is a real
problem.

[Ramon]

I completely agree! Name spaces? What? I the only person in my
development unit that actually came in with experience in OO PHP. The
rest are scripters. And you are talking about namespaces? Multiple
system intergration with same object names... give me a break... I'm
sure 99% of PHP programmers don't know what shm module is. Or what the
purpose of it.

There is room for improvement... lets just take it one step at a time.
Sheesh... namespaces. :)

Cheers,

D

Chung Leong wrote:

Oliver Grätz wrote:

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name. The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.

A symptom of what I was describing. Those who frequent this newsgroup
can testify to this, namespace collision is not a problem PHP
programmers are facing. Hell, I don't recall the last time someone
asked a PEAR related question--and that's the best known class library.
They are wasting their time pursuing the pipe dream of component
programming, which while sounding good in theory, is always thwarted by
programmers' tendency to write rubbish documentation.

I for one would rather have a new built-in datetime type that doesn't
suffer from the limitation of Unix timestamp. Now that is a real
problem.

[Kenneth Downs]

Chung Leong wrote:

Oliver Grätz wrote:

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name. The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.
A symptom of what I was describing. Those who frequent this newsgroup
can testify to this, namespace collision is not a problem PHP
programmers are facing. Hell, I don't recall the last time someone
asked a PEAR related question--and that's the best known class library.
They are wasting their time pursuing the pipe dream of component
programming, which while sounding good in theory, is always thwarted by
programmers' tendency to write rubbish documentation.

I for one would rather have a new built-in datetime type that doesn't

^^^^^^^^^^^^^^^^^

Amen and amen again. This was the only part of PHP that actually shocked me
in its lack of support for real-world needs.

The reason i use PHP is not because of its buzzword compatibility
(namespaces, OO) but because it actually allows me to get work done without
telling me how to do it. The datetime thing is kind of a sore thumb in
that department.
suffer from the limitation of Unix timestamp. Now that is a real
problem.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Oliver Grätz]

Chung Leong schrieb:

Those who frequent this newsgroup
can testify to this, namespace collision is not a problem PHP
programmers are facing. Speak for yourself. I was facing namespace collisions. So I guess I am
wrong frequenting this newsgroup?
Hell, I don't recall the last time someone
asked a PEAR related question--and that's the best known class library.

I don't agree that PEAR is the best known class library. But that's my
opinion. I tend to search for solutions in PEAR but most of the time a
specialized solution from another package is better. (which is why
namespace collisions do occur. Names like HTML_Form or DB_Query are just
too common...)

AllOLLi

[Spiduh]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I just think it's a good approach when you aim is improving the
language as opposed to increasing its usefulness. There is a subtle
difference. Removing function aliases, for example, improves the
language's consistency but doesn't make it more useful. I would say the
same thing about variable visibility and exception as well.

As there any point creating a PHP6 when so few hosts are upgrading to PHP5?

[Weird-beard]

Ummm... Some discussion that is.

I have been using php over 3 years now, and I am fond of it, though I
am coding in asp.net, asp and some java, because of customer needs. The
big companies and serious projects always prefer .net or java over php,
and the reason for that is php does not seem serious enough on their
side.

World is moving rapidly from procedural programming to oop, and the
reasons for that are numerous, being reusability, ease of programming
bigger apps, component sized developing, testing and so on.

Php, if oriented towards small applications, is adequate as a
procedural language. Could never be serious such, but as It works with
small projects thats ok. But, as we look upon the huge number of open
source projects written in php, which most of them are really brilliant
and huge, uses the oop approach and has to, as the functionality gets
bigger and lines of code stack upon, as the business requirements get
bigger, the oop approach becomes a must.

When I was programming using the procedural approach, as the number of
projects I have worked on begin to rise, I realized that I was facing a
serious problem. No matter how hard I thought upon the project I was
developing, that I surely would use it in another application, I always
stumbled upon something and resulted in modifiying the code I wrote for
another project using that feature. There had to be some way to reuse
the code across projects, and there had to be some way of adding
functionality dynamically. OOP alone does not resolve this issue, but
the "academic" work does, design patterns uml and such concepts helps
coder move towards a more perfected coding environment. I have realized
that they werent some buzzwords to appear smart, they were real
concepts, not as I have thought before.

The result is, as you move upon to larger and more complex projects,
you will need the move, maybe crave, as you know that you know that you
can do better but cant, feeling like losing the same time over and over
again chasing own tail.

So, if php does not improve itself towards oop approach, I guess it
will lose the big projects and serious apps, and php coder shall always
be considered a script writer.
blah blah blah.

[NC]

Oliver Grätz wrote:

NC schrieb:

Fortunately, we are not there yet. OOP can still be avoided
if necessary. Reading a remote file still can be done in a
single file_get_contents(),
OOP always seems to be "the bad guy". Sure, I like file_get_contents(),
especially if it's "file_get_contents('http://www.google.com');", but
what is so bad with

$myfile=new File('my-article.txt');
foreach($myfile as $line)
{
// do stuff
}

Nothing except it's unrealistic. In real-world object-oriented
frameworks it's much more complicated. For example, in order
to put the contents of a remote file into a string variable in
VB.NET, you need to:

1. Define an HttpWebRequest object to describe the request.
2. Call HttpWebRequest.GetResponse(), which will return a
WebResponse object.
3. Call WebResponse.GetResponseStream(), which will return a
StreamReader object.
4. Call StreamReader.ReadToEnd(), which will finally give you
the string you wanted in the first place.

Most importantly, string is still not an object.

What is so bad about

$s=new String('this is a test');
echo $s->reverse();

against

$s='this is a test';
echo strrev($s);

It's absolutely the same.

In PHP, due to its continuing adherence to weak typing, yes.
But OOP and weak typing are conflicting ideologies. In PHP,
both of the examples below would work:

$s = new String(123456789);
echo $s->reverse();

$s = 123456789;
echo strrev($s);

But the equivalent of "new String(123456789)" would cause an
exception in most object-oriented languages. So you would
have to do something like:

N = 123456789
Dim S As New String = N.ToString()

So now you have two representations of the same entity...
But the String class could tell you about it's capabilities:

print_r(get_class_methods('String'));
And this is better than proper documentation because ... ?
The only thing bad about strings being objects is having
to write more code.
Exactly. So why are we to abandon a more parsimonious approach
in favor of less parsimonious one? Reminds me of the interview
Bjarne Stroustrup supposedly gave to Computer magazine in 1998...
Objects are good. Period.

You are entitled to your opinion, but I respectfully disagree.
Objects are resource hogs. They are good only at creating more
work for programmers (and that's why programmers like them).
Their use in PHP should be limited to interfacing with
technologies incapable of procedural interaction (COM, .NET,
Java, etc.)

Cheers,
NC

[Jerry Stuckle]

Spiduh wrote:

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I just think it's a good approach when you aim is improving the
language as opposed to increasing its usefulness. There is a subtle
difference. Removing function aliases, for example, improves the
language's consistency but doesn't make it more useful. I would say the
same thing about variable visibility and exception as well.

As there any point creating a PHP6 when so few hosts are upgrading to PHP5?

They don't upgrade for business reasons.

Web hosting companies, like many other companies, almost never go with the
"latest and greatest". They wait until a release has been out for a while and
has stabilized. Once that's done, they then upgrade their systems.

They also have to be careful about existing scripts and changes in the language.
PHP has done a pretty good job maintaining compatibility between releases, but
there's always a chance of problems developing when an upgrade occurs. To help
with these problems, some hosting companies will install the new release on new
servers and migrate those who ask to the new ones. Eventually all servers are
migrated (with appropriate warnings, of course).

But it is a labor-intensive (and expensive) process which always generates lots
of help desk tickets. So it's not done very often. It can take a couple of
years before even a majority of hosting companies move to the new release. And
PHP5 has been out what - less than a year?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

NC wrote:

Oliver Grätz wrote:

NC schrieb:

Fortunately, we are not there yet. OOP can still be avoided
if necessary. Reading a remote file still can be done in a
single file_get_contents(),

OOP always seems to be "the bad guy". Sure, I like file_get_contents(),
especially if it's "file_get_contents('http://www.google.com');", but
what is so bad with

$myfile=new File('my-article.txt');
foreach($myfile as $line)
{
// do stuff
}

Nothing except it's unrealistic. In real-world object-oriented
frameworks it's much more complicated. For example, in order
to put the contents of a remote file into a string variable in
VB.NET, you need to:

1. Define an HttpWebRequest object to describe the request.
2. Call HttpWebRequest.GetResponse(), which will return a
WebResponse object.
3. Call WebResponse.GetResponseStream(), which will return a
StreamReader object.
4. Call StreamReader.ReadToEnd(), which will finally give you
the string you wanted in the first place.

Most importantly, string is still not an object.

What is so bad about

$s=new String('this is a test');
echo $s->reverse();

against

$s='this is a test';
echo strrev($s);

It's absolutely the same.

In PHP, due to its continuing adherence to weak typing, yes.
But OOP and weak typing are conflicting ideologies. In PHP,
both of the examples below would work:

$s = new String(123456789);
echo $s->reverse();

$s = 123456789;
echo strrev($s);

But the equivalent of "new String(123456789)" would cause an
exception in most object-oriented languages. So you would
have to do something like:

N = 123456789
Dim S As New String = N.ToString()

So now you have two representations of the same entity...

But the String class could tell you about it's capabilities:

print_r(get_class_methods('String'));

And this is better than proper documentation because ... ?

The only thing bad about strings being objects is having
to write more code.

Exactly. So why are we to abandon a more parsimonious approach
in favor of less parsimonious one? Reminds me of the interview
Bjarne Stroustrup supposedly gave to Computer magazine in 1998...

Objects are good. Period.

You are entitled to your opinion, but I respectfully disagree.
Objects are resource hogs. They are good only at creating more
work for programmers (and that's why programmers like them).
Their use in PHP should be limited to interfacing with
technologies incapable of procedural interaction (COM, .NET,
Java, etc.)

Cheers,
NC

Sorry, I disagree with you. OO does not have to be a resource hog. For
instance, in C++, you can define

String s = new String("123456789");

No duplication of data necessary.

Also, good OO code can be as (or more) efficient than non-OO code. Where it
becomes less efficient (other than poor programming practices) is when it
becomes more general purpose. This increases reuse - but also increases file
size and generally decreases performance. But that's also one of the limits of
reuse. It shows up in procedural code, also. For instance, the C call
"malloc()" (memory allocation) is known to be relatively slow. I can (and have)
easily write a function which will optimize memory allocation for a specific
structure, for instance. It will be faster and use less memory in the long run
(less fragmentation). But it's not worth the effort in 99% (or more) of the cases.

The real beauty of properly written OO is to separate the data representation
(i.e. storage, etc.) from the use of that data. A simple case - I needed to get
a web site up quickly (one day) on a (low cost) host where MySQL wasn't working
reliably. While the host worked on the problem, I created classes representing
the data storage which used CSV files and stored all my data there. I created
all the dynamic web pages based on the classes. Once they got MySQL working
properly, I simply changed the classes to use MySQL instead. I changed only the
class files - instead of numerous web page files. And I only had to test the
class files themselves - I knew the web pages were already working. A huge
savings of time!

Sure, it was a duplication of effort - but the site was up and running on time
and the customer was happy. And if they ever decide to go to any other
database, again it's a change of only the class files - none of the pages.

As I said - this is a simple, but real-life case. Before OO we used to do
similar things by creating functions to operate on the data. But that's just
basically object-based (instead of object-oriented) without many of the benefits
of true OO.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Chung Leong]

Weird-beard wrote:

So, if php does not improve itself towards oop approach, I guess it
will lose the big projects and serious apps, and php coder shall always
be considered a script writer.
blah blah blah.

That's like saying people who drive golf carts shall always be
considered carter drivers. Good engineers select the right tool for the
job. We want our tools to be become more refined over time, but their
general purpose and character should remain the same. A golf cart
should be a golf cart. It shouldn't acquire 4-wheel-drive capability
and high towing capacity in order to compete in the SUV market.

[Kenneth Downs]

Jerry Stuckle wrote:

The real beauty of properly written OO is to separate the data
representation
(i.e. storage, etc.) from the use of that data. A simple case - I needed
to get a web site up quickly (one day) on a (low cost) host where MySQL
wasn't working
reliably. While the host worked on the problem, I created classes
representing
the data storage which used CSV files and stored all my data there. I
created
all the dynamic web pages based on the classes. Once they got MySQL
working
properly, I simply changed the classes to use MySQL instead. I changed
only the
class files - instead of numerous web page files.

What you did is easily done w/o resorting to OO. It's even easier when you
are not messing with OO because you don't get the confusion of having
methods with the same name in multiple places doing differen things.

A good programmer will always have a wrapper layer between his own code and
outside systems like databases. There is always some program "Query()"
that can be quickly rerouted to pull CSV's instead of tables, or Oracle
instead of Postgres.

You have good habits, but do not mistake them as features of OO, because
they are not. Anything possible in OO can be done without it, usually with
less code and usually it turns out to be easier to maintain.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Jerry Stuckle]

Kenneth Downs wrote:

Jerry Stuckle wrote:

The real beauty of properly written OO is to separate the data
representation
(i.e. storage, etc.) from the use of that data. A simple case - I needed
to get a web site up quickly (one day) on a (low cost) host where MySQL
wasn't working
reliably. While the host worked on the problem, I created classes
representing
the data storage which used CSV files and stored all my data there. I
created
all the dynamic web pages based on the classes. Once they got MySQL
working
properly, I simply changed the classes to use MySQL instead. I changed
only the
class files - instead of numerous web page files.

What you did is easily done w/o resorting to OO. It's even easier when you
are not messing with OO because you don't get the confusion of having
methods with the same name in multiple places doing differen things.

A good programmer will always have a wrapper layer between his own code and
outside systems like databases. There is always some program "Query()"
that can be quickly rerouted to pull CSV's instead of tables, or Oracle
instead of Postgres.

You have good habits, but do not mistake them as features of OO, because
they are not. Anything possible in OO can be done without it, usually with
less code and usually it turns out to be easier to maintain.

Kenneth,

As I said - this is basically "object based programming" - without the advantage
of objects.

Actually, one of the greatest advantages to OO programming is the ability to
have functions WHICH DO THE SAME THING have the same name. I never have
functions with the same name do different things!

For instance - in my DB objects, I have fetch(), add(), delete() and update()
functions. In every db object they do the same thing. That way I don't need to
remember that it's fetch() in one object and get() in another one.

And no, I find non-OO code to be much HARDER to maintain. It doesn't take mode
code when both are done properly. And you need to remember all kinds of
different function names - even though the do the same thing.

Also, you have to worry a lot more about the side effects of changes you make.
Structure members are not private, for instance. No, YOU didn't code to access
the members directly - but who's to say someone else didn't? Encapsulation
prevents that from happening.

I've written a lot of non-OO code in my time - I started in 1967, well before OO
came out. I've only been doing OO since 1988 or so - mostly C++ and Java before
PHP.

As to "Anything possible in OO can be done without it". How do you do
inheritance and polymorphism in non-OO code? I'd love to see an example of
that. And as above - how do you ensure encapsulation?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Tony Marston]

"Oliver Grätz" <ol***********@gmx.de> wrote in message
news:43***********************@newsread4.arcor-online.net...
<snip>

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name.
Namespaces are only relevant in a compiled language where it builds up a
catalog of all the subroutine names that may be called. In a scripting
language such as PHP each request should only need to load in the modules
required for that request, so how many times would you want to link to TWO
different projects in the same request? If reqest #1 links to project #1,
and request #2 links to project #2 there are NO clashes, so no need for
namespaces. Besides which if component libraries are delivered as classes it
does not matter if 100 classes contain the same function name as each will
be qualified with their class name, thus making them unique.
The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.

Multiple inheritance will - as I guess - never be a part of PHP.

Multiple inheritance does not exist in Java, so why should it exist in PHP?

If a lot of programmers can screw up with single inheritance just think of
the damage that multiple inheritance will offer.

--
Tony Marston

http://www.tonymarston.net

[Tony Marston]

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:UK********************@comcast.com...

Kenneth Downs wrote: <snip> As to "Anything possible in OO can be done without it". How do you do
inheritance and polymorphism in non-OO code? I'd love to see an example
of that. And as above - how do you ensure encapsulation?

I used a non-OO language called UNIFACE in which I achieved encapsulation
and polymorphism. There was a sort of inheritance, but that was only one
level deep when a component was built from a template. You could change code
in the template, and that change would be inherited by all components based
on that template the next time they were recompiled.

--
Tony Marston

http://www.tonymarston.net

[Jerry Stuckle]

Tony Marston wrote:

"Jerry Stuckle" <js*******@attglobal.net> wrote in message
news:UK********************@comcast.com...

Kenneth Downs wrote:

<snip>

As to "Anything possible in OO can be done without it". How do you do
inheritance and polymorphism in non-OO code? I'd love to see an example
of that. And as above - how do you ensure encapsulation?

I used a non-OO language called UNIFACE in which I achieved encapsulation
and polymorphism. There was a sort of inheritance, but that was only one
level deep when a component was built from a template. You could change code
in the template, and that change would be inherited by all components based
on that template the next time they were recompiled.

Not familiar with UNIFACE - but it sounds like it had some rudimentary OO
constructs in it - at least inheritance and polymorphism.

But can you do it in a pure non-OO language such as C, Basic, PASCAL or others
(I'm not talking about OBJECT - xxx).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Tony Marston wrote:

"Oliver Grätz" <ol***********@gmx.de> wrote in message
news:43***********************@newsread4.arcor-online.net...
<snip>

For version 6, namespaces are becoming a topic again, since the sheer
number of PHP projects will surely lead to name collisions. You take
solutions from two projects and bang, several classes have the same
name.

Namespaces are only relevant in a compiled language where it builds up a
catalog of all the subroutine names that may be called. In a scripting
language such as PHP each request should only need to load in the modules
required for that request, so how many times would you want to link to TWO
different projects in the same request? If reqest #1 links to project #1,
and request #2 links to project #2 there are NO clashes, so no need for
namespaces. Besides which if component libraries are delivered as classes it
does not matter if 100 classes contain the same function name as each will
be qualified with their class name, thus making them unique.

The developers seem to be disussing about how to do it without
losing performance and how to hide it so that you only have to use it if
you want to. Old-Style code will be in a global namespace.

Multiple inheritance will - as I guess - never be a part of PHP.

Multiple inheritance does not exist in Java, so why should it exist in PHP?

If a lot of programmers can screw up with single inheritance just think of
the damage that multiple inheritance will offer.

Tony,

Actually, I can see needing namespaces in PHP. You may not take two different
complete projects - but it's nothing to take classes from different projects,
especially in a larger app. Not as common in PHP, where your projects are
generally smaller. But quite possible.

Let's take a simple example - you have a program which needs to update a MySQL
database from a SQL Server database? I.E. you have your inventory on an
internal VPN running MySQL, and you need to update the MySQL database on your
web site.

You already have the necessary classes from both, from previous projects. But
what if you have two classes named "Database"? And "Category", "Product", etc.?

You could go through and rename one (or both) of the sets of classes. Or, if
PHP had namespaces, you could create namespaces for them.

As to the multiple inheritance issue. No, Java doesn't have it. I occasionally
miss it - I've used it quite successfully in C++. But you're correct - it's
misused much more than it's used correctly, and more often than not I can code
around the restriction. Still, there are times I wish Java had it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Malcolm Dew-Jones]

Jerry Stuckle (js*******@attglobal.net) wrote:
: Tony Marston wrote:
: > "Jerry Stuckle" <js*******@attglobal.net> wrote in message
: > news:UK********************@comcast.com...
: >
: >>Kenneth Downs wrote:
: >
: > <snip>
: >
: >>As to "Anything possible in OO can be done without it". How do you do
: >>inheritance and polymorphism in non-OO code? I'd love to see an example
: >>of that. And as above - how do you ensure encapsulation?
: >
: >
: > I used a non-OO language called UNIFACE in which I achieved encapsulation
: > and polymorphism. There was a sort of inheritance, but that was only one
: > level deep when a component was built from a template. You could change code
: > in the template, and that change would be inherited by all components based
: > on that template the next time they were recompiled.
: >

: Not familiar with UNIFACE - but it sounds like it had some rudimentary OO
: constructs in it - at least inheritance and polymorphism.

: But can you do it in a pure non-OO language such as C, Basic, PASCAL or others
: (I'm not talking about OBJECT - xxx).

It's easy to write oo stuff using pure C, Heck, the first versions of C++
were apparently just C with carefully crafted preprocessing macros, and
the first template stuff was handled by preprocessing too. Long before
anyone talked about oo my Atari ST compiler had examples of window
handling that was code designed along the same conceptual lines as oo (at
least long before I ever head of it, anyway). Just build a common
structure that includes a standared way to incldue the function pointers
necessary for handling that type of structure. Add a lookup function to
find the functions and the whole thing becomes dynamic to boot (I thinks
that's how objective C [used to] works).

Having it natively in the language just makes it (much) easier to use, and
more (easily) flexible, etc etc.
--

This programmer available for rent.