Page 2 - Should We be more Pro-active (PHP)

Hey, don't get me wrong... I would prefer PHP/Zend as a language to most of the other languages out there, regardless of the target environment. You definitely have a point, that if there is something you can accomplish with PHP rather than learn another language, why not use it?

I'm not trying to be negative about PHP, just calling a spade a spade.

But it is also possible to get a little myopic in viewpoint. If you use PHP for everything, you might miss some of possibilities available in other environments. PHP makes some things really easy. But in so doing, the language has acquired many web-specific features and functions, which don't apply to other environments. In this sense, it is not so generalized. Sooner or later, some decisions are going to have to be made. For generic scripting, I think it would make sense to also create a "base" PHP build, which only has generalized programming features, and then allow for compiling or dynamic loading of additional features in this or that direction. This way, you could get a very small. efficient PHP binary for certain things.

It seems to me that PHP and Perl are both aiming toward higher ground in their next major release. Each will have a better-thought-out OOP model, and more modular architecture in general. But Perl 6 is doing this on a much grander scale, allowing for all kinds of "geek love-fest" things, such as bytecode compilers, cross-compilers, predeclaration of many features, etc...

In this sense, it is still going to stay ahead of PHP as a general language, with a lot of scope.

A couple of pros and cons I can see between the two:

1. PHP has much easier (IMHO more natural) array-handling features. With Perl, you still have to mess around with arrays of references to arrays to get nested structures. I don't know how Perl 6 will handle those things, though.

2. PHP's OOP model is simpler but more effective, although currently (pre Zend 2) it has a few oddities. But then again, Perl 6 will have an even more complete object model, possibly leapfrogging PHP in that department. (In Perl 6, you will be able to treat anything as an object, while still also being able to treat them as primitives (scalar, array, etc...).

3. With Perl 6, we will no longer have the awkward C++ method of referencing objects and methods ($this->that), but the much more elegant Java-like dot dereferencer (this.that.doit()). While many complain that this will change the concatenation operator ("this" _ "that"), I think it is the right move. PHP developers claim they are most decidedly NOT moving to a dot dereferencer. I think this is too bad, because that is the single thing I like most about the Java (and Javascript) syntax. It just makes object-oriented programming flow so much better, and it makes code much easier to read. (And it's easier to say "this dot that" when you are discussing code with others. How do you say the C++ one? "this point that"?). This is just one of my pet peeves, but the dot alone would save me thousands of keystrokes a year (1 keystroke, versus MINUS SHIFT ARROW). Also it makes code easier to read and parse (self-modifying code, anyone), and might just be one of the deciding factors in whether I move some major development work to Perl 6 in the end.

Perl and PHP being my two favorite languages, I doubt I will be giving up either anytime soon, though .

I haven't really noticed too many of the "you can't do this" posts. I agree that 99% of the time when you think you can't do something, it's because you are too lazy to think of a way to do it.

I'm a little bummed about the change of the infix(->) operator for OOP calls in perl 6, but not too bummed. The dot syntax will definitely clear things up.

Perl 6 is going to be such a huge change, but I'm actually more excited to get a mod_perl that stable with Apache 2.0, whenever that happens.

I'm in the same camp as rycamor- Perl and PHP are my two favorite web languages (though I tend to use mod_perl over PHP) and they aren't going anywhere quickly.

I'd really hate to see the PHP community lose focus and veer too far from being a web focused scripting language.

The world needs an open-source language that competes directly with ColdFusion and ASP, and PHP fits that niche better than perl. Trying to do everything with it is going to weaken it's strength.

One of the axioms in the perl world is to use perl's strengths. . .I think that applies to PHP as well. Use it for it's strength as a web scripting language, not it's weaknesses as a client-site GUI development tool. But more power to the PHP-GTK folks!

And obviously, the best tool for the job is the one that lets you get what you need to get done quickly and securely. I wouldn't use PHP for shell scripting, but if it works for you, go to it.

I did not really think you were being that negative rycamor I just wanted an intro for my rant

I for one am a little myopic for sure and have to keep myself in check, but its important to me to see where PHP can take us, but that point needs to be taken seriously.

As for '->' vs '.' well I am not so bothered with that as I suppose its a personal preference, what I am hanging out for is better dereferencing , i.e
$temp=$this->child;
$val_u_like=$temp->property;
will become
$val_u_like=$this->child->property;
in Zend2, saving a fair few keystrokes !

I saw (posted here I think) that Andrei Zmievski has a patch to support dot referencing at http://www.gravitonic.com/software/php/ , but recall seeing it dismissed somewhere on Zend due to confusion with '.' concatenation ? (as you mention above for PERL) I dont really care either way as long as backwards compatibility can be ensured.

I tend to avoid OOP in my day to day dealings though of course realise its benefits in larger or collaberative projects (& as easily reusable/expandable libraries) , though my GTK adventures have conviced me of the need for better OOP in PHP.

All that said if we look at the breadth and scope of PHP's usage as-is on the web alone at the moment its doing pretty well by anyones standards , though I note the increasing popularity of mod_perl !! , and I guess many don't feel the need any more to push PHP with the same vigour as we used to. I for one generally can not keep my gob shut about it and talk myself into all sorts of fun and games (back to the myopia again) but all in all am still enjoying the journey.

but we too need compilers (free ones) & all the `"geek love-fest" ` things <- we can get , it cant really hurt & who knows where it can take us.


Hero Zzyzzx , I think the ASP/CFM war was won before CFM/ASP heads knew it had even started, today & tomorrows issues are going to be competing against .NOT & J2EE , advocates of which often try to compare directly against PHP , forgetting the difference between an application environment and `PHP` standalone.

How kewl would that be - a tiny compiled PHP engine into which you could plug platform-independant GUI and bluetooth libraries, along with a compressed XML datastore, and toss the same app onto a palm/pocketPC, next.gen Mobile, Tablet PC, and Desktop box to handle and sync all your todo's, memo's, accounts... blah blah blah. No more Excel for PocketPC!



[EDIT]Hell, why not stick it onto one of these aswell? [/EDIT]

Well, thats what a few of us are waiting for, and why XUL is so promising at the moment. If we can get someone to write the bindings for XUL/PHP, as python already has the pyXPCOM and perlXPCOM soon to be, we (or whoever) wouldn't need to rewrite any of the PHP engine. Applications with few boundries would be the utltimate success of such a project.

Imagine this -> Check out Komodo from activestate, now think of writing such applications, that can be implemented cross-platform, communicating between the client side GUI and a remote server (or just a client side application), written in XUL/PHP. Pretty incredible if you think about it..

PHP|GTK pretty good -> PHP|Mozilla|XUL pretty incredible

Um, yes we would. Or should. See, its not good coding practice sticking everything in when 90% of its not needed. Think about what I said: platform-independant, tiny. The current standard compiled distro of PHP comes with such items as Aspel, BCMath, ClibPDF, Cybercash, dBase, .NET, FrontBase, filePro, FDF, SQL Server, Oracle, Sybase... to name but a few. Why bother adding these to a compile release if they're not going to be used? Especially when the target platforms include a low-spec
PDA/Watch, a nokia bluetooth-enabled phone/organiser, and a desktop box?

And anyway, isn't XUL Mozilla specific? Wouldn't that mean we have to smash a full-scale browser distro into the 2MB storage space on the PDA/Watch as well as the full PHP server?

Well, maybe not in your PDA application - as I am talking about PC applications and not mini PDA apps. As for rewriting the PHP engine, it wouldn't be needed, for PC apps. Besides, removing packages from the PHP distro is not considered a rewrite of the engine. So no, no rewriting needed.

Thats why my post differed from yours - PC applications compared to PDA applications differ in a big way....

How many people actually wears that **** tracey clone of a watch anyways. Boy, in a corporate meeting wearing something like that would really look good to my clients....lol

I would laugh people out of my office after seeing that thing on someones wrist........

Now you're just nit-picking because you didn't read my post properly and you know i'm right!

Still, wouldn't a less bloated streamlined-PHP-engine-and-compiled-library type application be better than a full browser, the full PHP engine, probably an apache engine, and a database engine? Or do we all want to follow microsoft and various other companies examples of bloatware?

• Take, for example, this setup:
• (New) Zend Engine which handles basic PHP coding construct, along with generic functions (Date, Class, etc). Incorporated into this are the abilities to be compiled and to run independantly within OS memory, and to connect to and use other compiled libraries.
• Compiled Bluetooth Library: uses standard classes to connect to generic, cross-platform bluetooth devices/drivers.
• Compiled GUI Library: uses (compiled/read-only) stylesheets for platform-independant gui generation (see, not far from XUL ).
• Compiled XML Library: used to generate/access/maintain XML datasource.
• Compiled Compression Library: for compression of XML datasources.

I think this would be a little more stable and speedworthy than a mocked LAMP server with a (GUIfied) Mozilla thrown in, even on a PC-level platform.

As to rycamor's previous post, I would hope that the PHP/Zend community create the ability to handle everything as an object - a la Perl6. That would save a lot of trouble casting. Not too sure about removing the "." vs "->"... I'd have to completely recode my current works in progress! (Saying that, with addional features, tighter/faster code, future-proofing... I'd probably do it anyway!)



New word for this week: Future-proofing... lol Sorry, but keeping up on new platforms is the least we can do, if not developing for them.

No, never - don't have time to nitpick....

Yes, a less-bloated php engine would do some justice. As for bloatware, there is no bloatware termonology in developing applications in XUL - no need for an apache engine or a database if your not developing those types of apps. Also, you are not developing applications that are ran in a browser, you are developing gui apps - just using mozilla as the framework...

I once heard the same exact thing about webtv... What a flop...

Well, the web began as something used by tech boffins within the government and universities over 10 years ago... now look where it is... technologies are merging and leapfrogging each other. We have to keep up - who knows where the next standard will come from? XML's only a couple of years old as it is!



Sorry, am I mistaken, but don't you have to install the browser so you can use the additional mozilla features?