Slashdot Mirror
Extending and Embedding PHP
Sebastian Bergmann writes "PHP is a widely-used general-purpose scripting language that is especially suited for Web development. The interpreter that executes programs written in the PHP programming
language has been designed from the ground up to be easily embeddable (for instance into the
Apache Web Server) and extendable. This extensibility is one
of the reasons why PHP became the favourite "glue" of the Web: functionality from existing third-party
libraries (database clients or image manipulation toolkits, for instance) can be made available through
PHP with the ease of use you expect from a scripting language." Read the rest of Sebastian's review.
Extending and Embedding PHP
author
Sara Golemon
pages
448
publisher
SAMS
rating
9
reviewer
Sebastian Bergmann
ISBN
067232704X
summary
The new standard work on extending and embedding PHP.
"Extending and Embedding PHP" by Sara Golemon, a long-time contributor to the PHP project, remedies the fact that the internals of PHP are far from being as well documented as the rest of PHP. It brings writing extensions for PHP "to the masses", so to speak.
After a short introduction that makes the reader familiar with terms like PHP Extension, Zend Extension, Userland, and Internals that are used throughout the book, Chapter 1 ("The PHP Life Cycle") opens with an overview of how the PHP Interpreter works and what parts (TSRM, Zend Engine, SAPI, "PHP") it comprises.
Chapter 2 ("Variables from the Inside Out") shows how PHP handles and stores variables internally. The reader learns how to distinguish types, set and retrieve values, as well as how to work with symbol tables. It is in this chapter that the fundamental unit of data storage in PHP, the so-called zval (short for Zend Value) is discussed.
Chapter 3 ("Memory Management") builds upon the previous chapter and discusses more advanced operations on zvals, for instance creating and dealing with copies of a zval or the destruction of a zval when it is no longer needed. To this extent, the Zend Memory Manager is discussed as well as underlying principles such as Reference Counting and Copy-on-Write, for instance.
Chapter 4 ("Setting Up a Build Environment") guides the reader through setting up an environment, either on *NIX or on Microsoft Windows, for the development and debugging of PHP and PHP extensions.
After these first four chapters, the reader is ready to go about writing his or her first PHP extension. Chapter 5 ("Your First Extension") takes the reader through the steps necessary to write and build a simple working PHP extension. The following chapters build upon the knowledge gained here, so that the reader can ultimately implement or change any type of PHP feature.
Chapter 6 ("Returning Values") explains how to pass values (by value, by reference, and through their parameter stack using references) from internal (C-level) functions or methods to userland (PHP-level).
Chapter 7 ("Accepting Parameters") deals with the mechanisms involved in accepting parameters from userland calls to an internal function or method. This includes the discussion of the zend_parse_parameters() API which makes the parameters that are passed to the internal function or method as indirect zval references usable in your C-code. The handling of optional and arbitrary numbers of parameters is explained as well as the usage of type hinting and its arg_info API.
Chapter 8 ("Working with Arrays and Hash Tables") explains the Zend Engine's HashTable API, which is used to store any piece of data of any size, in detail. Its different data storage mechanisms supported are introduced and compared. To quote from the book, "A HashTable is a specialized form of a doubly linked list that adds the speed and efficiency of vectors in the form of lookup indices". Since these structures are used heavily throughout the Zend Engine and PHP and its extensions, a good understanding of this API is vital for any aspiring PHP extension developer.
Chapter 9 ("The Resource Data Type") introduces the reader to the first complex data type (excluding the Array data type that was discussed in the previous chapter, which is just a collection containing primitive data types like strings or numbers). A resource can be, for instance, a connection to a database. It allows the PHP extension developer to "connect abstract concepts like opaque pointers from third-party libraries to the easy-to-use userspace scripting language that makes PHP so powerful".
Chapters 10 ("PHP 4 Objects") and Chapter 11 ("PHP 5 Objects") delve into the last data type supported by the Zend Engine: objects. Sara Golemon dedicates one chapter each to the respective APIs of PHP 4 and PHP 5 because of the huge advancements that were introduced in PHP 5 and that totally changed the APIs.
After the previous chapter, all data types supported by the Zend Engine have been discussed and the book revisits a topic discussed earlier in the book: that of the PHP Interpreter's life cycle. Chapter 12 ("Startup, Shutdown, and a Few Places in Between") explains how to add state to a PHP extension by using thread-safe globals. Along the way, concepts such as internal and external (super) globals as well as thread safety are discussed.
Chapter 13 ("INI Settings") shows how a PHP extension can be made ready for runtime configuration through php.ini settings.
The next three chapters ("Accessing Streams", "Implementing Streams", and "Diverting the Stream") make the reader familiar with yet another important API of PHP: the Streams API. All file input/output in PHP userspace is processed through PHP's Streams Layer. This layer, that was introduced in PHP 4.3, is what makes working with files, compressed files, and remote files, for instance, seamlessly in PHP. The reader learns how to work with streams as well as how to expose streamable resources, whether remote network input/output or local data sources, using the Streams API, thus avoiding the need to reimplement all the tedious bits and pieces that are normally associated with this.
Chapter 17 ("Configuration and Linking") builds upon the tools and techniques introduced in Chapter 4 and adds the GNU autotools (autoconf, automake, and friends) to the reader's set of tools. These tools, if used correctly, allow the extension to be built in environments that the extension author does not know or has no access to.
Chapter 18 ("Extension Generators") takes a look at ext_skel (which comes with the source distribution of PHP) and PECL_Gen (which can be obtained, as the name suggests, from PECL, the PHP Extension Community Library). These two tools automate most of the steps described in the previous chapter and take a lot of tedious work out of the extension writer's hands.
Starting with simple embedding examples, the reader learns in Chapter 19 ("Setting Up a Host Environment") and Chapter 20 ("Advanced Embedding") how the PHP Interpreter can be embedded into almost any other application.
The book concludes with the "Zend API Reference", "PHP API Reference", "Extending and Embedding Cookbook", and "Additional Resources" appendixes. The first two are a great resource for both novice and experienced PHP extension writers (even for people working on PHP and the Zend Engine itself). The third features a collection of common use code snippets while the last one points the reader into the direction of PECL by suggesting a couple of existing extensions to look at and learn from.
Since the topic of this book is to extend the PHP Interpreter using extensions written in the C programming language (or to embed it into an application that is written in C), a good understanding of C syntax, its datatypes, and pointer management is important to get the most out of this book.
Being a contributor to the PHP project for about six years now, I have been looking forward to this book. True, there is always the source code of the PHP Interpreter as a source of information on how "things work". But although being the ultimate reference, reading the source code cannot replace a thoughtfully structured and well written guide that gets you started. If you are looking for such a guide, look no further: you will find it in this excellent book.
Although it deals with a very technical topic, "Extending and Embedding PHP" is readable and the many code examples are easy to follow. The reader profits from the knowledge of the author, who has been involved in the PHP project as a core developer for over four years now and is also the author and maintainer of a dozen PHP extensions that are available through PECL. The book covers both major versions of PHP that are currently used, PHP 4 and PHP 5, and it will continue to serve its purpose when PHP 6 comes out next year.
Sebastian Bergmann spends his free time with the development of Free Software, is a member of the PHP and Gentoo Linux development teams and author of a variety of PHP software projects such as PHPUnit."
You can purchase Extending and Embedding PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
"Extending and Embedding PHP" by Sara Golemon, a long-time contributor to the PHP project, remedies the fact that the internals of PHP are far from being as well documented as the rest of PHP. It brings writing extensions for PHP "to the masses", so to speak.
After a short introduction that makes the reader familiar with terms like PHP Extension, Zend Extension, Userland, and Internals that are used throughout the book, Chapter 1 ("The PHP Life Cycle") opens with an overview of how the PHP Interpreter works and what parts (TSRM, Zend Engine, SAPI, "PHP") it comprises.
Chapter 2 ("Variables from the Inside Out") shows how PHP handles and stores variables internally. The reader learns how to distinguish types, set and retrieve values, as well as how to work with symbol tables. It is in this chapter that the fundamental unit of data storage in PHP, the so-called zval (short for Zend Value) is discussed.
Chapter 3 ("Memory Management") builds upon the previous chapter and discusses more advanced operations on zvals, for instance creating and dealing with copies of a zval or the destruction of a zval when it is no longer needed. To this extent, the Zend Memory Manager is discussed as well as underlying principles such as Reference Counting and Copy-on-Write, for instance.
Chapter 4 ("Setting Up a Build Environment") guides the reader through setting up an environment, either on *NIX or on Microsoft Windows, for the development and debugging of PHP and PHP extensions.
After these first four chapters, the reader is ready to go about writing his or her first PHP extension. Chapter 5 ("Your First Extension") takes the reader through the steps necessary to write and build a simple working PHP extension. The following chapters build upon the knowledge gained here, so that the reader can ultimately implement or change any type of PHP feature.
Chapter 6 ("Returning Values") explains how to pass values (by value, by reference, and through their parameter stack using references) from internal (C-level) functions or methods to userland (PHP-level).
Chapter 7 ("Accepting Parameters") deals with the mechanisms involved in accepting parameters from userland calls to an internal function or method. This includes the discussion of the zend_parse_parameters() API which makes the parameters that are passed to the internal function or method as indirect zval references usable in your C-code. The handling of optional and arbitrary numbers of parameters is explained as well as the usage of type hinting and its arg_info API.
Chapter 8 ("Working with Arrays and Hash Tables") explains the Zend Engine's HashTable API, which is used to store any piece of data of any size, in detail. Its different data storage mechanisms supported are introduced and compared. To quote from the book, "A HashTable is a specialized form of a doubly linked list that adds the speed and efficiency of vectors in the form of lookup indices". Since these structures are used heavily throughout the Zend Engine and PHP and its extensions, a good understanding of this API is vital for any aspiring PHP extension developer.
Chapter 9 ("The Resource Data Type") introduces the reader to the first complex data type (excluding the Array data type that was discussed in the previous chapter, which is just a collection containing primitive data types like strings or numbers). A resource can be, for instance, a connection to a database. It allows the PHP extension developer to "connect abstract concepts like opaque pointers from third-party libraries to the easy-to-use userspace scripting language that makes PHP so powerful".
Chapters 10 ("PHP 4 Objects") and Chapter 11 ("PHP 5 Objects") delve into the last data type supported by the Zend Engine: objects. Sara Golemon dedicates one chapter each to the respective APIs of PHP 4 and PHP 5 because of the huge advancements that were introduced in PHP 5 and that totally changed the APIs.
After the previous chapter, all data types supported by the Zend Engine have been discussed and the book revisits a topic discussed earlier in the book: that of the PHP Interpreter's life cycle. Chapter 12 ("Startup, Shutdown, and a Few Places in Between") explains how to add state to a PHP extension by using thread-safe globals. Along the way, concepts such as internal and external (super) globals as well as thread safety are discussed.
Chapter 13 ("INI Settings") shows how a PHP extension can be made ready for runtime configuration through php.ini settings.
The next three chapters ("Accessing Streams", "Implementing Streams", and "Diverting the Stream") make the reader familiar with yet another important API of PHP: the Streams API. All file input/output in PHP userspace is processed through PHP's Streams Layer. This layer, that was introduced in PHP 4.3, is what makes working with files, compressed files, and remote files, for instance, seamlessly in PHP. The reader learns how to work with streams as well as how to expose streamable resources, whether remote network input/output or local data sources, using the Streams API, thus avoiding the need to reimplement all the tedious bits and pieces that are normally associated with this.
Chapter 17 ("Configuration and Linking") builds upon the tools and techniques introduced in Chapter 4 and adds the GNU autotools (autoconf, automake, and friends) to the reader's set of tools. These tools, if used correctly, allow the extension to be built in environments that the extension author does not know or has no access to.
Chapter 18 ("Extension Generators") takes a look at ext_skel (which comes with the source distribution of PHP) and PECL_Gen (which can be obtained, as the name suggests, from PECL, the PHP Extension Community Library). These two tools automate most of the steps described in the previous chapter and take a lot of tedious work out of the extension writer's hands.
Starting with simple embedding examples, the reader learns in Chapter 19 ("Setting Up a Host Environment") and Chapter 20 ("Advanced Embedding") how the PHP Interpreter can be embedded into almost any other application.
The book concludes with the "Zend API Reference", "PHP API Reference", "Extending and Embedding Cookbook", and "Additional Resources" appendixes. The first two are a great resource for both novice and experienced PHP extension writers (even for people working on PHP and the Zend Engine itself). The third features a collection of common use code snippets while the last one points the reader into the direction of PECL by suggesting a couple of existing extensions to look at and learn from.
Since the topic of this book is to extend the PHP Interpreter using extensions written in the C programming language (or to embed it into an application that is written in C), a good understanding of C syntax, its datatypes, and pointer management is important to get the most out of this book.
Being a contributor to the PHP project for about six years now, I have been looking forward to this book. True, there is always the source code of the PHP Interpreter as a source of information on how "things work". But although being the ultimate reference, reading the source code cannot replace a thoughtfully structured and well written guide that gets you started. If you are looking for such a guide, look no further: you will find it in this excellent book.
Although it deals with a very technical topic, "Extending and Embedding PHP" is readable and the many code examples are easy to follow. The reader profits from the knowledge of the author, who has been involved in the PHP project as a core developer for over four years now and is also the author and maintainer of a dozen PHP extensions that are available through PECL. The book covers both major versions of PHP that are currently used, PHP 4 and PHP 5, and it will continue to serve its purpose when PHP 6 comes out next year.
Sebastian Bergmann spends his free time with the development of Free Software, is a member of the PHP and Gentoo Linux development teams and author of a variety of PHP software projects such as PHPUnit."
You can purchase Extending and Embedding PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The reason? PHP is easy to use, loosely-typed (which happened to be an advantage in this case), fast, and of course the license works. It was a great decision.
PHP-embed is basically just a TSRMLS function wrapper. It's pretty straightforward; for example, zval integration is easy as pie, as I recall, something like:
Sigs cause cancer.
"Extending and Embedding PHP"...
:)
Microsoft involved here?
Found one: http://www.oreilly.com/catalog/phpnut/
But although being the ultimate reference, reading the source code cannot replace a thoughtfully structured and well written guide that gets you started.
Agreed, especially when the source code you're reading isn't your own. I claim that 99% of programmers who are not me write totally obfuscated code. Damn them!
I know that Slashdot gets kickbacks from B & N, but it's very inconsiderate of them to make their readers pay so much when Amazon has it for less (see Amazon's third-party sellers, cheapest prices on the 'Net).
I knew her when she worked at berkeley (I think she works for yahoo! now). She really knows her shit.
Do you even lift?
These aren't the 'roids you're looking for.
Ok, so 5 of the first 7 comments were trolling about how bad PHP is, insecure, buggy, etc (and I think they even managed to take a shot at Bush???)
/. thing to do?
I've used PHP for some very small applications/sites. Can anyone give an unbiased (almost impossible I know) state of affairs for PHP? I know that it is a pretty common tool, has its strengths and weaknesses. However, is it really that bad or is bashing it just the current
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
What makes you think such a book would be PHP specific?
The answer is 42.
If you're interested in this, you'll probably be interested to know about Ian Bicking's work on embedding PHP in Python web applications via PHP's FastCGI support. It's only in the experimental stages, but it's very promising, especially for developers like me who develop with Python but need to support legacy PHP code.
Bogtha Bogtha Bogtha
That doesn't surprise me. With a name like that she'd have to be a real digital monster.
i've got this book, it's very well written and easy to follow. i recommend it.
i hate when people post about php books in slashdot.
it's soo damn overrated.
all these php books.
php.net
PHP is missing alot of functionality, impliments alot of things in very bad ways, and has never been written with security in mind. This is a bad combo, and some of the bizzare PHPisms will really warp you way of thinking and make it much harder for you to go to any other language on the planet (like making "arrays" actually be some monster combination of arrays, hashes, stacks, heaps, and queues).
Save yourself $18.50 by buying the book here: Extending and Embedding PHP. And if you use the "secret" A9.com discount, you can save an extra 1.57%! That's a total savings of $18.99, or 38.58%!
Comparing PHP with Perl, PHP has no equivalent of "use strict". Consequently, there are simple programming mistakes which Perl will catch but PHP will not. Newbies think that not having to declare variables is a time-saver. Experienced programmers know that the few seconds gained by not having to declare variables, is lost thousands of times over when you have to find a bug that would never have arisen if undeclared variables had been caught by the language.
If you never need to write more than a dozen lines of code, PHP is fine. If you need to do anything more complicated, look elsewhere.
Yeah, so PHP stands for "Personal Home Pages" but that's is an historical misnomer now. PHP has a CLI binary that can be used to run scripts on the commandline. Obligatory "hello world" follows:
!#/usr/bin/php
echo "Hello, world!";
Now consider that PHP ships standard on virtually every Linux distro and comes with a large assortment of libraries. You can write LDAP scripts, do IMAP, generate images, the list is loooong. It amazes me that PHP isn't used more in corporate envirments. PHP is easy to use, arrays are surprisingly useful, and you can do a little OO (which is just the right amount IMO). And something that a lot of people take for granted is that the documentation on php.net is great. Everything is on one place unlike other languages (e.g. Python) where you just get redirected to every little sourceforge scribble and wiki there is.
I'm a C person. I'll continue to use C for heavy lifting but you also need a good scripting language. I just wrote a Zend extension to interface with some of my C work and it exceeded all of my expectations.
If you're looking for the lastest hot new "technology" then Ruby is a good buzzword. Otherwise, if you're just looking to get work done, so you can go home and play with your kids, PHP is a workhorse.
PS: I don't know spit about this book but the tutorial on writing extensions on the Zend website was pretty good. Good enough for me anyway.
A lot of PHP bashing going on; I'd just like to chip in my 2 cents on the language (and demonstrate a mild interest in the book). I was big on programming when I was younger - by 14 I had written an adventure game in Basic and I invented a DOS-based graphical application that is eerily similar to Flash (two stickmen and some props on the screen with keyframes and interpolation tracking). Needless to say I was well advanced of my classmates throughout highschool. I also wrote a Chess AI (who hasn't?) in C. But that was the end of it - about 10 years ago now. I longed for programming but Real Life(tm) got in the way and other career paths curbed my free time. Needless to say I had lost a lot of skills and I don't even know what OOP stands for, but getting into the blogging world and creating a custom website to house it resulted in me having to learn some sort of web-based programming. I have to say that PHP was beautifully easy to (re-)learn and I was back in the programming seat with a big grin on my face with just a few weeks of self-learning (by looking at examples and open source, no books). I'm praising PHP as a very easy to learn, easy to use starting point for all my would-be programming friends.
That'll teach me to copy/paste. I left his shebang mistake in there too. A thousand apologies. I tried to be the King of Pedantry, and I failed.
Wow. That'd have been the story of my adolescence to the letter, if my otherwise fine secondary school hadn't been an IT wasteland. I got a start in BASIC back in primary school, and was eager to take it further when I moved on. The first chance I got, I logged in and opened the first recognisable name I could see: Visual Basic.
And thus endeth my programming career until the lazy days of university some eight years later.
Many people just use PHP because it's popular and because they can't be bothered to use anything else. Which is a shame, because it doesn't deserve to be, and many people should be much better than that.
:D! I got a website with Tripod (urgh) and that gave me a MySQL database, so I could now make proper sites! PHP was brilliant, and I was excellent with it. Wow, I was on top of the world.
I remember when I picked up PHP. It was brilliant. Look at me, I can create dynamic web pages! I could do for loops, and while loops, and print out numbers without using JavaScript! And now, I can take parameters in from $_GET[], and make a proper website in only one file!
Seriously, I was ecstatic like that, but bear in mind that I only knew C and HTML before this. Oh, and BASIC, but that's just embarrassing.
We were happy, PHP and I. We were nice and friends. Why should I bother to learn something else when PHP was accomplishing what I wanted just fine, thank you very much?
Well, I can now safely say that dumping PHP was a great step forward for... pretty much everything really.
I was so happy with what I was doing that I was willing to see past PHP's shortcomings. It was easy to learn, so I learned it and stuck with it. But PHP has a lot of shortcomings. Sure, I don't see why it's stripslashes() but strip_tags(), the underscore's being there is just random, but it's OK, I could just look it up.
I didn't realise how slow I was coding, from all that looking at the docs.
These days, I can look at PHP and go "what the hell were they thinking?". While it's alright to look at the documentation when you're learning a language, it's not right if I keep having to look at them several years later, to find out if it's array_length() or arraylength() or arrlen() or count(). It's count(). I relied on magic quotes to do all my work for me, when now I see them as a clutch, a poor clutch at that, and now I use taint checking. I draw circles and bang my head on them when I realise there's STILL no namespaces. I laugh at all PHP's inconsistencies, wondering why it's strtolower but str_replace and bin2hex, wondering why it's $haystack, $needle arguments and other times $needle, $haystack. The PHP devs must talk to each other as much as the Slashdot editors do (ooh, low blow).
Seriously, PHP is so bad it's silly - there's just no reason for people to use it when there's far better out there. I don't have to talk about PHP's typing, or its syntax, as they can be dismissed as just a personal preference. I just don't understand why it's so inconsistent. A good language shouldn't be inconsistent.
(Oh, and I don't see what's so special about the PHP docs either. Sure, it's nice that they're there, but pydoc and perldoc and ri beat them any day)
So, I'm totally over PHP now. Totally. I learned Ruby, but you might want to learn Python, or maybe Perl. Maybe more than one. They all have good CGI support, and can do all that PHP can do, and more, better. Ruby's greatly improved my hacking ability, and dumping PHP can improve yours too.
Guy asked me for a quarter for a cup of coffee. So I bit him.
That's because there are people who are trying to reinvent a 40+ years old language who do not like the way PHP has taken over the web. They simply hate the way sites with page names ending in ".php" outnumber sites with pages names ending in ".rb".
Those people are too stupid to understand Lisp, too ignorant to know the good points of Lisp, and too close-minded to try learning how to use Lisp, therefore they tried to create a hybrid language by attaching some of the Fortran syntax to Lisp, creating Ruby in the process.
I think that there is a contingent of web programmers that are bored and upset that PHP is still the premier method for scripting websites. They want something new and fresh to work with. I can appreciate that. When you use the same language for a long time, it starts to look "old". This is exacerbated when they inherit sloppy code and are forced to decipher and fix some other dummy's spaghetti. So they declare the language "dead" in hope of creating enough spin and FUD that something new will take over. Something new that will create work and give them more job opportunities. The same something new that they invested a lot of time into learning.
To the PHP bashers - you might succeed in selling something new but after the next guy inherits your spaghetti code they will start bashing *you*.
Don't be fooled people. Every language has it's corners. I spend 90% of my time doing C but I just spent a month doing a standard LAMP site and I just don't see what these guys are hee'n and haw'n about. PHP is just as useful today as it was on 1998 so I'm willing to bet it will be around for a long time still. Don't be influenced by some bored guy saying "it sucks" and "I hate it". That's just not intelligent criticism. Try different things and make up your own mind.
PHP has a huge install base and has served us very well for many years. Let's not forget that. The PHP bashers pushing Python and Ruby should be ashamed of themselves. Post some useful information about how Python or Ruby solves a problem you think PHP has. And no cryptic one liners thank you. Get a spine and post some useful comments.
Why does this nit always come up? Sincere question, I assure you: pretty much *every book or tutorial on PHP has "Turn Off register_globals" in the first chapter." And it's off-by-default in the last few major versions. I remember some popular (but crummy) big apps like osCommerce required(d?) it and when I discovered that (in 2003!) I about fell out of my chair. And in agreement with another poster, SQL injection is basically-impossible in any language when you set up your privs intelligently.
My turnips listen for the soft cry of your love
I thought about that last bit a little more and realized there are plenty of situations where simple read-access could be dangerous... well, I use PEAR::DB anyway.
My turnips listen for the soft cry of your love
Some people also use a function to strip out less than/greater than signs from data (or simply use htmlspecialchars/htmlentities) before adding it to a database. Their desire is to prevent cross-site scripting attacks. This is a lazy hack. A better way to combat cross-site scripting is to apply htmlentities to data being pulled out of the database for display. If you are using "real" W3C DOM scripting methods and not innerHTML, you can simply add the data as-is (making sure your JSON methods slash out any would-be JavaScript escape characters)--"textContent" will display would-be markup as text.
You know, other languages have libraries and modules, too...
PHP isn't the first language with MySQL bindings. It's not the first with GD bindings. And so on.
And PHP wasn't really designed to be easy to properly embed in other applications either. It was designed to have the code embedded in HTML, granted. And it was designed to run in the web server. But I doubt it was designed to be put to all kinds of use. Who is embedding PHP except for web servers?
If you want a language that was really designed for embedding, consider looking at lua. From what I know of it, it was really designed to be used as scripting language within other applications. From spreadsheets to games.
I think my brother told me he was developing on a scientific instrument (most likely for fraunhofer, probably for the development of solar power related stuff), and that you could script it in lua.
Then there is enigma, a fun game (port of Oxyd), it uses lua for scripting the levels.
PHP has other uses. Like writing bad code. SCNR. But I do consider PHP a legacy language.
Debian GNU/Linux - apt-get into it.
Absolutely. More than anything else, these are exactly the things that are driving me away from PHP. magic_quotes* issues can be coded around (though they shouldn't have to be), but when I have to keep php.net open all the time to make sure a function is still called what I think it should be (often I'm still wrong by an underscore), I'm not a happy developer.
This is a poor excuse for a stab at Ruby. Most Rubyist sites tend to be powered by RoR, which in part explains why you haven't seen many ".rb" pages around. Also, how would Rubyists complain about PHP "taking over" the web (implying this should be the "domain" [pun] of Ruby powered sites) when so few of them were introduced to Ruby before 2000? Though PHP and Ruby were introduced around the same time, it took Ruby slightly longer to reach an English-speaking audience. It didn't really take off until pickaxe was released.
That's right, Ruby is just a horrible mishmash of Lisp and Fortran. Uh-huh. And PHP is a horrible mishmash of Perl (and Perl is a horrible mishmash of shell scripting, C, AWK, and that holy untouchable language Lisp!) Ruby is not the cause of PHP's poor reputation. PHP is the cause of PHP's poor reputation. I speak as an open-minded 6-year PHP developer.
<sarcasm>All these newfangled languages are just for people who are too stupid to understand machine code, too ignorant to learn the good points of machine code, and too closed-minded to try learning how to use machine code. Therefore they tried to create some sort of "higher level" language to escape their ignorance. They might call it programming, but it's not machine code!</sarcasm>
We get signal.
You CATS with mod points, its you!
You GET SIGNAL!
Your BASE p0wn3d by mod_php!
When the country falls into chaos, politicians talk about 'patriotism'. Lao-Tzu
But things like SQL Injection is one of many reasons I just love ASP.NET.
I wrote a very short piece on this on my site, and how use of paramertized queries/stored procedures in 99% of the cases eliminate this problem entirely.
It also includes a comprehensive SQL Injection demonstration, which I'd recommend that everyone working with DBs should read. Using PHP/Perl/ASP.NET or whatever their favorite web-programming lanaguge happen to be.Not Buzzword 2.0 compliant. Please speak english.
Come on, people! You do not escape your own values, because you'll inevitably forget something. Instead, you use parameter substitution and let the language do the work for you. If some new vulnerability comes along, would you honestly rather re-write every database access module you own instead of just upgrading the language's core library and being done with it?
Dewey, what part of this looks like authorities should be involved?
For example, PHP has a special function to see if a given key is in an array:
In Python, you'd use the standard syntax for determining if a value is present in any list-like object
If you ever change myarray into a different kind of object, like a list, set, or database-backed persistent store, that exact same expression still works. That is, it's not anything special for arrays, but part of the general structure of the language.
And that's why I can't stand PHP. While it may work perfectly, you have to learn an enormous amount about the language before you can really become proficient. I'd rather learn something with a small syntax that I can master quickly and build upon. I realize that comes down to personal preference, but I think that's the majority opinion here.
Sure, php.net is an excellent resource. I contend that it has to be or no one would ever be able to use the language. It's simply too large to memorize.
Dewey, what part of this looks like authorities should be involved?
Oh you poor thing. It must be awful to be tied to your computer desk and forced at gunpoint to read slashdot. Too bad you couldn't just go away.