× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



There are two ways of looking at that. 1. Full compatibility is absolutely, 100% required, or 2. While there are differences, from a practicality standpoint, they are pretty much the same. I use PCRE a decent amount but I'm drawing a blank on a situation where the difference has been unbearable. That's not to say that it's true 100% of the time but it's never bitten me. Based off of the Wikipedia article it seems like recursion in very specific circumstances are the biggest issue. So, it may not be 100% but it works pretty well.

As for dynamic typing increasing maintenance, I'd have some trouble buying that. In PHP there are 8 data types. Integer, Boolean, Float, String, NULL, resource, object and arrays. Objects and arrays can be "strongly" typed in that you can state that you want an array and not a string, or a particular instance of a class. So you have the ability to build a good structure to virtually any sized application.

However, when you deal with the 4 "scalar" types, that is when the dynamic typing occurs. The biggest problem is that (0 == false == null) based off of the type juggling rules and 0, false and null could have different meanings in certain circumstances. But in those cases you can use type sensitivity when you need it by using the === or !== sign. In other words (0 !== false !== null). But once you get into PHP 5 OOP the rules are virtually identical to any strongly typed OO language.

The reason for having these dynamic typing rules is that on the web EVERYTHING is a string. Whether "1" is a string or an integer really doesn't matter that much from a practical standpoint because the browser submitted a string value of 1. There is overhead in having the dynamic typing going on but it makes for very easy to write code.

One place where this COULD be true would be if you have a heavy dependence on associative arrays for structure, like using a struct. However, the simple solution is to use placeholder classes to define the structure you need. There is a minimal amount of overhead in doing that.

Kevin

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjoern Ravn Andersen
Sent: Thursday, October 29, 2009 12:42 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] iSeries, web development and perl

Mike Pavlak skrev:
And...keep in mind that PHP on IBM i supports PERL compatible REGEX...So, if that is all you are looking for "It's in There!"

You got me curious, and a bit sceptical since I've worked a lot with
Perl and I know the power of its regular expressions, so I poked around
a bit.

From "http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions":

"The name is misleading, because PCRE is Perl-compatible only if you
consider a subset of PCRE's settings and a subset of Perl's regular
expression facilities."

Sigh :(

(but I'd like to hear experiences with large PHP programs - my personal
one is that large programs without static typing tends to require more
time when doing maintainance because the compiler simply helps less.
I'd love to be taught otherwise :) )


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.