PHP 5.4 Released

mikejuk writes "PHP 5.4 has been released, along with a new version of Zend Framework. It has a number of optimizations that make it faster and smaller (early estimates say 10-20% faster), a built-in webserver for testing purposes, and features that had been destined for PHP 6.0. The big addition from the now-crashed PHP 6.0 project is Traits, which are sort of a cross between a class and an interface, bringing some of the advantages of multiple inheritance to PHP. The full changelog and download page are both available."

Comments

advantages of multiple inheritance

[Anonymous Coward]

Please enlighten me on the "advantages" of multiple inheritance.

Everything I've learned has taught me that MI is a BAD thing (worse than GOTO), so I'm honestly curious what these supposed "advantages" are.

Re:advantages of multiple inheritance

[Anonymous Coward]

GOTO is perfectly fine in some situations. Using a technique badly doesn't make the technique bad itself. It's just stupid users.

Re:advantages of multiple inheritance

[Anonymous Coward]

Difficult to write assembly without "goto"

Re:advantages of multiple inheritance

[bieber]

Multiple inheritance is supported in some form or another in just about every OO language in existence. It's just that most prefer to restrict multiply-inherited traits to methods and call them "interfaces" instead of "base classes." IMO, that's entirely unnecessary. If I want an "interface" in C++, then I write a pure abstract class without any member variables and use it the same way I'd use an interface in Java. If I want true multiple inheritance in Java, I'm just out of luck. MI can be used in some very nasty ways, but if you tried to remove each and every feature that a programmer could possibly misuse from a language you'd pretty quickly find yourself with an insanely verbose toy language that no experienced developer would ever want to touch.

Re:advantages of multiple inheritance

[Daniel Dvorkin]

Like every other tool, multiple inheritance can be used or abused. It may be one of those tools which is actually more prone to abuse than to proper use, but that doesn't mean it can't be done right.

For a specific example, I used to work on a database application stack which had a bunch of classes for database entities (People and Companies, say) each inheriting from a DBEntity class; and other classes, inheriting from the database-facing classes, to format those entities for display (DisplayPeople, DisplayCompanies, etc.) The display classes each had to inherit from the database-facing classes, and each had its own particular display needs, but there were also, unsurprsingly, a lot of display functions in common. It would have been very useful to be able to define a DisplayEntity class from which each of the display classes could have inherited, using the common methods when applicable and defining their own methods when needed.

Re:advantages of multiple inheritance

[Anonymous Coward]

Or to implement lightweight error handling without a complex forest of unreadable if else blocks in languages that lack exceptions.

Re:advantages of multiple inheritance

[buchner.johannes]

I thought I would need it about 3 times in projects, but never ended up using it because there is always a way around it (delegation as last resort). That tells me that it really never is a requirement for a programming language, and even programming classes were never able to come up with a useful demo example other than the car/boat story.
However, inheriting/implementing multiple interfaces with one class *is* useful, and you do it all the time e.g. in Java. Perhaps this is meant here?

Re:advantages of multiple inheritance

[buchner.johannes]

Also, you can emulate a goto easily:

      cmd1;
start:
      cmd2;
      a = cmd3;
      if ( a == 0) { goto start; }
      cmd4;

becomes

      cmd1;
      while(1) {
          cmd2;
          a = cmd3;
          if (a == 0) continue;
          break;
      }
      cmd4;

Re:advantages of multiple inheritance

[CastrTroy]

Many languages provide fancy syntactic sugar type gotos so that developers can only make safe gotos. Some of these include things like "break" to exit a loop, or other commands like "exit for". As far as I'm concerned, Try/Catch is just fancy syntactic sugar for the old VB "On Error GoTo". Very much agree with you. There's nothing wrong with GoTo provided you use it right. Not having GoTo doesn't make terrible developers all of a sudden stop making crappy code.

Re:advantages of multiple inheritance

[Anonymous Coward]

Maybe that's part of the reason why most people don't write assembly.

Re:advantages of multiple inheritance

[Anonymous Coward]

The issue goes beyond that. Multiple inheritance significantly complicates implementing the language, and it also carries many complications that have to be sorted out so that the language itself becomes more complicated. On top of that, as you point out, multiple inheritance isn't useful most of the time anyway. Multiple interface inheritance avoids all of these issues, and can make up for most of the cases where multiple implementation inheritance is needed. So yes, there are useful cases where you want multiple inheritance, but keeping it out of a language is not nearly as asinine as you make it appear.

Re:advantages of multiple inheritance

[buchner.johannes]

Multiple inheritance is supported in some form or another in just about every OO language in existence. It's just that most prefer to restrict multiply-inherited traits to methods and call them "interfaces" instead of "base classes." IMO, that's entirely unnecessary. If I want an "interface" in C++, then I write a pure abstract class without any member variables and use it the same way I'd use an interface in Java. If I want true multiple inheritance in Java, I'm just out of luck. MI can be used in some very nasty ways, but if you tried to remove each and every feature that a programmer could possibly misuse from a language you'd pretty quickly find yourself with an insanely verbose toy language that no experienced developer would ever want to touch.

I disagree: Taking away options in the language can make the outcome better. For instance, you *have* to strongly type in Java, and you *have* to put everything in classes. Surely its safe to say that Java tends to be more modular by default.
If you take away the update operator, you end up in the wonderful world of side-effect-free programming, that the compiler also can take advantage of.

I have yet to see an example where MI is the best solution in a real e.g. Java program.

Re:advantages of multiple inheritance

[Anonymous Coward]

No, it's easy. You just increment/decrement the program counter as needed: that's an ADD/SUB. The problem is when you change the code and have to recompute offsets. Which means using GOTO is only a good idea if you are not good enough to nail it on the first go.

Re:advantages of multiple inheritance

[petsounds]

Taking away options in the language can make the outcome better. For instance, you *have* to strongly type in Java, and you *have* to put everything in classes. Surely its safe to say that Java tends to be more modular by default.

This is sort of like saying democracy in the United States is better because the Constitutional Convention decided an Electoral College would help keep the masses in check. Speaking as a proponent of strong typing, I reject languages that force behavior on programmers. A good language *encourages* good behavior through elegance, pragmatism, and tangible benefit. A bad language creates unnecessary rules because the creators of the language think they know better than the users.

Re:advantages of multiple inheritance

[Anonymous Coward]

Why the fuck were your data objects doing display logic?

Your example is a WTF, not a good argument for MI.

Re:advantages of multiple inheritance

[Daniel Dvorkin]

Why the fuck were your data objects doing display logic?

They weren't, and we didn't want them to have to do so. That's the point.

Re:advantages of multiple inheritance

[datavirtue]

My use of multiple inheritance is so rare as to be dusty. In fact, I have to look up the syntax whenever I use it. I only use it because I'm bored and I can fit it in. You really have to try to use it.

Re:advantages of multiple inheritance

[datavirtue]

GOTO is never unsafe, it is just a messy bad habit.

Re:advantages of multiple inheritance

[datavirtue]

WOW. This is a perfect example of pure craziness. I'm speechless....just WOW.

Re:advantages of multiple inheritance

[Compaqt]

>This is sort of like saying democracy in the United States is better because the Constitutional Convention decided an Electoral College would help keep the masses in check.

Well, a lot of people actually think it does contribute to the stability of the US political system. Whether you think stability is good is a different matter.

Now for Java: It's great that there are a lot of cool and funky languages, which are good for different purposes. But for the average ho-hum business application, a severely restricted language is best. Regardless of if you or I are rockstar programmers, most programmers are not. In fact 50% are below average.

For the vast legions of corporate business logic programmers, simple programming leads to greater maintainability. Below average programmers do not have the capability to understand "weird" blocks of code.

Secondly, I don't understand why every language under the sun has to slowly have Lisp/Scheme incorporated into it. We already have those, so why reinvent the wheel?

Re:advantages of multiple inheritance

[Anonymous Coward]

This technique doesn't work in all cases. Not all GOTOs can be translated into "standard" control structures. (More specifically, this only works if the GOTOs yield a reducible control flow graph, see http://www.cs.wright.edu/~tkprasad/courses/cs781/L31CFA.pdf )

Re:advantages of multiple inheritance

[Barbara, not Barbie]

Gotos are great. Look at your switch statement. See those case labels - they're the targets for the computed goto. Or do you not use switch statements?

There's absolutely nothing wrong with goto. Just people who abused it and it got a bad reputation.

Re:advantages of multiple inheritance

[Anonymous Coward]

Actually you have not successfully made your case for MI, because the concept of an interface aligns more naturally with the idea of composition ("hasA") rather than inheritance ("isA"). For example it's more appropriate to say "this Widget is a Shape that happens to have a Printable interface" (composition) than "this Widget is both a Shape and a Printable" (inheritance).

Without being able to claim interfaces as an example of MI, the meat of your argument reduces to "it's possible to use MI in C++ but not Java; however, I can't cite any examples of MI's usefulness, but I still assert that it makes C++ a better language than Java."

I'm here to call Bullshit. I agree that C++ is a better language than Java, but I consider MI to be one of C++'s worst design flaws.

Re:advantages of multiple inheritance

[luke923]

I take it you're not a fan of Python, then...

Re:advantages of multiple inheritance

[GPLHost-Thomas]

GOTO is never unsafe

So, there's no safe assembly code? Silly...

Re:advantages of multiple inheritance

[Lord_Naikon]

Proper multiple inheritance makes it possible to share a common base class in a subclass instead of duplicating it (storage or code). For instance consider a Square baseclass which has a property called "width". We can now define two subclasses ColoredSquare and RoundedSquare with properties "color" and "radius" respectively. However wouldn't it also be nice to have a ColoredRoundedSquare? By subclassing from both ColoredSquare and RoundedSquare it inherits both the "color" and "radius" properties as well as the property of "width" _once_. In other words, the inherited functionality and storage from Square is now shared by both ColoredRoundedSquare's superclasses. That is something you cannot do without multiple inheritance. In Java you can fake the above by using interfaces but it leads to code duplication, because you need to redefine one superclass's instance variables (either radius or color) in ColoredRoundedSquare, or memory duplication because the ColoredRoundedSquare must proxy calls to one of the superclasses resulting in Square being instantiated twice.

Re:advantages of multiple inheritance

[Nutria]

Neither are automobiles, but we keep on driving them.

Re:advantages of multiple inheritance

[siride]

Only if you are using an assembly language that lets you directly modify the program counter with normal arithmetic instructions. x86 does not let you do this. You must use one of the jmp family of instructions (essentially goto), or call/int/ret/iret (and related).

Re:advantages of multiple inheritance

[Anonymous Coward]

See also: Ruby Mixins.

Re:advantages of multiple inheritance

[Anonymous Coward]

So in this case you would use composition instead of inheritence. Your base data class would simply compose a formatter, which would then be available to all descendant classes. This would provide common methods. Of course, the display and value objects really shouldn't be coupled.

Re:advantages of multiple inheritance

[shutdown -p now]

I have yet to see an example where MI is the best solution in a real e.g. Java program.

Generally speaking, public inheritance represents a "can-substitute-for" relationship (per Liskov substition principle). So whenever you have some A that can substitute for both B and C, you have multiple inheritance.

In Java in particular, every time you implement an interface, you use multiple inheritance. That's plenty of examples right there in java.lang.*.

You're going to say that interfaces are limited. Sure they are - you can't have fields, and methods can't have bodies. The second restriction is actually going away in Java 8 with "defender methods" - basically, the ability to provide default implementations for interface methods. Why is it useful? Well, you often have rich interfaces, such as e.g. collections, where a lot of members are going to be implemented the same way for all or at least most implementations, usually in terms of other members - e.g think about java.util.List#contains, which is normally implemented in terms of a simple loop. The way things are now, all implementations have to repeat themselves. In Java 8, it'll get a default standard implementation right there in List - so you get it for free when you implement it.

Inheritance of fields is more questionable, mainly because you're forced to make a choice of how do deal with duplicate fields coming from "diamonds" in inheritance hierarchy. That's probably why it's used very rarely in C++, even though it's technically supported.

Re:advantages of multiple inheritance

[Anonymous Coward]

This should be a post on the Daily WTF...

Re:advantages of multiple inheritance

[Anonymous Coward]

Because the LISP-family happen to be the most elegant languages there is.

Re:advantages of multiple inheritance

[sdk4777]

LD HL,GotoLabel PUSH HL RET

Re:advantages of multiple inheritance

[msobkow]

Multiple interface inheritance is necessary in order to specify a proper object model, but C++ is the only language I've ever used that supports multiple inheritance of methods and attributes as well as interface signatures.

Certainly I find it far, far easier to code a system with C++ than with Java or C#. Both Java and C# require that you copy-paste-edit code between implementations of the interfaces, which results in a lot of code duplication and is more prone to error than the C++ approach. (Not to mention being in direct contradiction with the whole concept of code re-use.)

Still, I do understand why it's difficult to work with C++. It's a true chainsaw of a language in the hands of an expert, with the resulting risk of slicing your own limbs off if you're not careful or don't know what you're doing.

But unlike some, I don't blame a flexible language for letting programmers hang themselves. I come from the era of bits bytes and machine code, so while I understand and take advantage of the newer languages, I have no fear of dropping down to the nuts and bolts for performance, and I have an intimate knowledge of how CPUs are implemented and work (I even took VLSI and CPU design courses in university, though things have moved along quite nicely since those days!)

Personally I prefer the flexibility of multiple-inheritance, but I am thoroughly addicted to the cross-platform nature of Java. My favourite is actually the C# syntax, but realistically the Mono implementation is so slow and outdated that it may as well exist -- C# is effectively Windows-only.

Maybe one of these days I'll play with PHP, but I'm really not a "web guy". Most of my experience is with back-end data services, relational-object modeling, and making batch jobs and huge complex reports run like a bat out of hell. PHP feels too much like Visual Basic or other "integrated" GUI/IDE/Code environments for my tastes. I'd rather work on and provide glue layers for scalable JEE systems than tie myself to a language whose libraries aren't inherently designed for cluster-scaling.

Re:advantages of multiple inheritance

[Anonymous Coward]

If you made a specific effort to find "a way around it" then it sounds like you'd already decided you weren't going to use it. It's not surprising that you managed to find some sort of workaround under that mindset, but it doesn't mean MI wouldn't have been useful if you'd actually considered it an option.

Re:advantages of multiple inheritance

[K. S. Kyosuke]

Multiple inheritance is supported in some form or another in just about every OO language in existence. It's just that most prefer to restrict multiply-inherited traits to methods and call them "interfaces" instead of "base classes."

Theory Alert: That's not inheritance, that's subtyping. The difference is subtle, yet important. Inheritance is reuse of implementation, subtyping is a matter of type compatibility (Liskov's substitution principle). In rather basic OOP languages, such as Java, inheriting a class implementation immediately generates a subtype - which is probably the reason why it confuses a lot of people - but it's not a general principle. (E.g., type systems with the MyType construct generate a subclass by inheriting a class but that subclass is not always a subtype.)

Re:advantages of multiple inheritance

[Anonymous Coward]

Multiple inheritance paves the way for virtual inheritance. I even used it once.

Re:advantages of multiple inheritance

[Anonymous Coward]

This is a joke, right? Otherwise pls always follow separation of concerns. In your case:

1. Data should be decoupled from how they are stored.
2. Data should be decoupled from how they are displayed.
3. And storage logic should be decoupled from display logic

Why? Because you want to minimize the scope you need to think about when changing something. If you have access to the display methods of your entity in the storage tier of your app you failed.

Re:advantages of multiple inheritance

[Anonymous Coward]

Try again, but actually read the quoted text this time.

Re:advantages of multiple inheritance

[rev0lt]

Now repeat in assembly.
Just because a given language has goto constructs, it doesn't mean that you need to use them. There are some use cases, (and many other constructs will translate to labels and jumps, so I don't really understand the pavor of using it), and in the example you gave, a poor compiler would produce crappy machine code for the 2nd version.

Re:advantages of multiple inheritance

[rev0lt]

Actually, you *do* have exceptions. And traps. And aborts. In x86/ia32, the first 32 interrupt vectors are reserved for cpu exceptions. In all modern x86 operating systems, virtual memory is managed trough (you guessed it) exceptions.

Regarding the if/else blocks, they are a bit like the bad programmers that use goto because they can't process anything else. How do you think those fancy exception structures are translated? You can quicly slap one of a dozen variants on an assembly project. An easy lazy version? At a given point, you have a var with the offset of the common error handling routine, and you pass as a parameter the error code you want to use and (optionally) the severity. Have a macro created that does something like (push errorCode / call [_errorHandler]). Your error routine will quit on fatal errors, or return to the execution (or change the return path in the stack) just like any other function. the iteration to get error messages? Use arrays of offsets, then add the base address of the offset array to the error code, and this step is similar to many other languages (but in asm you can have funcion offsets to call for specific handlers without using complicated object inheritance).

Re:advantages of multiple inheritance

[Anonymous Coward]

(and many other constructs will translate to labels and jumps, so I don't really understand the pavor of using it)

The arguments against goto are about code maintainability. The fact that assembly code generated by the compiler uses the equivalent of goto is irrelevant because that code isn't expected to be maintainable.

Re:advantages of multiple inheritance

[runningduck]

Actually, more than 50% of programmers are below average. There is always a large number of beginning programmers compared to the few exceptional programers in the long tail of the population. Long tail populations almost always have an average on the long tail side of the median. In this sense I think that it would even be fair to say that the overwhelming majority of programmers are below average. This is in line with my experiencing with programmers.

Re:advantages of multiple inheritance

[Lisandro]

Aren't exceptions a fancy use of GOTOs aswell?

Re:advantages of multiple inheritance

[CSMoran]

Only if you are using an assembly language that lets you directly modify the program counter with normal arithmetic instructions. x86 does not let you do this. You must use one of the jmp family of instructions (essentially goto), or call/int/ret/iret (and related).

So what exactly prevents you from pushing the instruction pointer, popping a usual register, doing arithmetics on it, pushing it back to the stack and popping the modified instruction pointer?

Re:advantages of multiple inheritance

[Bill_the_Engineer]

The problem with GOTO was that before OO and modular programming becoming the norm, most code were long streams of consciousness that were hard to decipher. GOTO is still being used but not directly by the programmer or more accurately by syntactic sugar offered by the language.

Consider the WHILE loop:

a = 0
while(a < 5) {
println a
a = a + 1
}

It is really similar to (good enough for illustration - I could optimize by using logical not):

a = 0
loop:
compare a to 5
jump to continue if less than
goto exit
continue:
println a
a = a + 1
goto loop
exit:

The GOTO rule has been around so long that it has become an axiom. Unfortunately any (Perl) programmer can agree that there are more powerful ways to really reduce the readability of code. Poorly nested loops, extra long case statement tree, poorly done templates, inappropriately overloaded operators, and C++ being used for evil as prime examples.

Re:advantages of multiple inheritance

[siride]

The only way you can push the instruction pointer is with a call instruction. The only way you can pop the instruction pointer is with a ret instruction. So yes, you *could* do arithmetic on it and use call/ret as fancy push/pop instructions for the instruction pointer, but...why? What does it accomplish? Why not just use those instructions as intended, or one of the jmp instructions? I'm struggling to understand what value is gained by your method, if it's indeed different from using computed jmps.

Re:advantages of multiple inheritance

[Anonymous Coward]

I'm not sure why people keep stating that the only two options are multiple-inheritance and copy-paste.

There's a much more flexible solution... delegation. If you need something that can do "foo" to a widget, get a thing that can do "foo" to a widget and use it.

If you don't care about the implementation, you shouldn't be using inheritance to force a single implementation and you certainly shouldn't copy/paste in an implementation.

To avoid tightly coupling the implementation, you can use a factory or injection model to get the tools you need.

Re:advantages of multiple inheritance

[Xest]

Sorry, you've lost me, is this meant to be an example of multiple inheritance being used or abused? I get the intention you feel it's the former, but the reality is it's the latter.

Your example proves the point precisely - multiple is never necessary, hardly ever useful, and even people like yourself who greatly believe in it seem to completely miss the fact that you've used it for something that could've been done far better without it.

Your anecdote doesn't speak in favour of multiple inheritance - on the contrary, it's an example of why it's a problem, it gets used for things it simply shouldn't. Your example is a fine demonstration of poor architecture and a failure to properly achieve separation of concerns.

Re:advantages of multiple inheritance

[Anonymous Coward]

Oh fucking hell are you seriously incapable of telling the difference between the concept of branching code (which is essential) and the concept of the GO TO statement jumping to an arbitrary location (which is what people criticise)?

A switch statement is not GO TO. Yes, it compiles down to a computed jump at the machine code level, but you cannot use a switch statement to jump to an arbitrary location in your code, which is the problem with GO TO.

Fucking object methods are also compiled down to jump statements. Look up the method's location in the object's dispatch table, push parameters and return location onto the stack, jump to the method's code, execute it, jump back. You could implement the same thing with GO TO. The point is that you don't.

Please, learn something about the history of programming before you're next tempted to come out with an asinine comment like "herp derp this thing which is not GO TO is just fine so GO TO must be just fine too QED muthafuckas."

Re:advantages of multiple inheritance

[Barbara, not Barbie]

I would suggest that you take a chill pill. Goto is no worse than any other language construct. All language constructs can be abused - but the pathological fear of goto shown by too many people is based in part on stupidity, and in part on simple ignorance.

The ability to use a goto to jump out of deeply nested statements, or to jump directly to a common exit point of a function (so as to have one unique return point from any function) is a feature that people should be using to make code more, not less, maintainable.

Similarly, the ability to use a setjmp to jump outside of a function can result in code that is cleaner than a bunch of try/catch/finally statements, as well as reducing code duplication.

So why not quit with the "oh my I iz so l337 cuz I don't uze teh ebil GOTO" attitude, hmm? Just because YOU can't use it properly doesn't mean others can't.

Re:advantages of multiple inheritance

[CSMoran]

Nah, I never said there is something to be accomplished by doing that. I was just surprised by your assertion that one must use jmp/jxx or call and friends to change the instruction pointer. I honestly thought that one could push and pop eip if one wanted.

Re:advantages of multiple inheritance

[drkstr1]

Statistics fail! :P

Re:advantages of multiple inheritance

[siride]

Fair enough. It seems like you should, but x86 is weird with registers. There's no way to address ip/eip/rip like you can the other registers. You can't do it with flags/eflags/rflags either. You have to push, mangle and pop (like you were suggesting in the post above). Weirdo architecture...

Re:advantages of multiple inheritance

[drkstr1]

Sorry to double post, but as soon as I posted my comment, I realized the difference between median and mean. Snark Fail!

Re:advantages of multiple inheritance

[drkstr1]

+1 (if I could) for composition with DI.

Another thing I would like to add is that the only value of inheritance is to reduce the amount typing needed to accomplish a task. Since I can instantly generate accessor methods via code snippets, why bother with inheritance at all? From a design perspective, it only seems to complicate things. Granted there are certain cases where I will still use inheritance, but I find those cases less and less as my skills progress.

Re:advantages of multiple inheritance

[JonySuede]

Certainly I find it far, far easier to code a system with C++ than with Java or C#. Both Java and C# require that you copy-paste-edit code between implementations of the interfaces, which results in a lot of code duplication and is more prone to error than the C++ approach. (Not to mention being in direct contradiction with the whole concept of code re-use.)

No, you use delegation and you have your ide generate and update the code...

Re:advantages of multiple inheritance

[Anonymous Coward]

Nowhere did he say that GOTO is bad, he said that "GOTO is good because all the other control structures get compiled into GOTOs" is a stupid argument.

That's all we need ...

[Barbara, not Barbie]

a cross between a class and an interface,

... having php adopt a bad idea from Java and making it worse? Wouldn't we be better off actually having static typing instead?

Re:That's all we need ...

[Anonymous Coward]

Im confused, what would static typing have to do with that?

Re:That's all we need ...

[Daniel Dvorkin]

Java interfaces are essentially a fancy form of documentation. Traits sound like they provide actual functionality.

As for static typing ... oh, never mind. If you prefer static typing, by all means, use a language that has it. Also bear in mind that static typing != strong typing; a lot of people who complain about the lack of the first really seem to be talking about the second.

Re:That's all we need ...

[Anonymous Coward]

... having php adopt a bad idea [traits] from Java and making it worse?

Java doesn't have traits: http://en.wikipedia.org/wiki/Trait_%28computer_programming%29

Re:That's all we need ...

[tomhath]

having php adopt a bad idea from Java and making it worse?

More like understanding what went wrong in Java and not making the same mistake again.

Wouldn't we be better off actually having static typing instead?

If you want a static typed language and all the tedium that goes with it, use Java. If you want faster development and less code, use a dynamically typed language.

Re:That's all we need ...

[Yvan256]

No idea, but a sheet of Bounce would probably solve that problem.

Re:That's all we need ...

[Anonymous Coward]

Nothing, I suppose, but something useful would be a lot nicer to have.

Re:That's all we need ...

[icebraining]

I'm a dynamic languages guy, but to be fair, that tedium is Java's fault, not the static typing. A good typing system will have inference.

factorial x = if x == 0 then 1 else x * factorial (x-1)

This is statically typed code in Haskell, but as you can see there are no type declarations to be seen.

Re:That's all we need ...

[buchner.johannes]

a cross between a class and an interface,

... having php adopt a bad idea from Java and making it worse? Wouldn't we be better off actually having static typing instead?

Yes, a class is a terrible concept that must be abolished at once!

What are you criticizing exactly?

Re:That's all we need ...

[buchner.johannes]

Java interfaces are essentially a fancy form of documentation.

They are also a contract (although I admit not the fanciest).

Re:That's all we need ...

[Daniel Dvorkin]

They are also a contract

And, IMO, a contract is a fancy form of documentation. If you can't implement any functionality in it, it doesn't do anything that a careful check of the program against the design specs can't also accomplish. I'm not saying interfaces are useless, but I wish people would stop saying "we don't need multiple inheritance, we've got interfaces!" when they don't do anywhere near the same thing.

Re:That's all we need ...

[arth1]

hmm, I'm not sure that duck typing qualifies as static typing. I mean, can you infer from the above whether x can be a float or not?

Re:That's all we need ...

[Anonymous Coward]

The problem is: that code is not using duck typing. Haskell is indeed a statically-typed language. The Haskell compiler will infer that x is a member of the 'Num' type class, which includes floats and ints, and means there are certain functions that are defined over it (arithmetic ops, comparisons, etc.). The point is that the compiler knows the type of x - it's not duck typed.

The GP's point was that a good type inference system can allow you to avoid some of the tedium in declaring types all over the place (and can even be a bonus when you start talking about automatic generalization like what happens in the GP's example) while still giving the compiler type info so that it can enforce strong typing if it's designed that way.

Re:That's all we need ...

[Anonymous Coward]

The Haskell compiler will infer that x is a member of the 'Num' type class, which includes floats and ints

Ignorant Haskell question. How does Haskell prevent factorial allows ints and floats, factorial 6.1 results in an infinite loop.

Re:That's all we need ...

[hcs_$reboot]

Frankly, why don't they seize the opportunity of PHP6 to rewrite~redesign that language, focus on lib functions names consistency and introducing true indexed arrays, and nested functions (currently nested functions behave the same as top level funcs, ridiculous), for starters.

Re:That's all we need ...

[Anonymous Coward]

I'm assuming that you're asking how Haskell prevents factorial 6.1 being called (which causes an infinite loop) using the GP's definition and given that the Num class includes both floats and ints. The answer is: it doesn't. This is a case where the developer should specify a type explicitly and not rely on the type inference mechanism. Its type signature would look like:

factorial :: Int -> Int
factorial n =

Sometimes the problem compels you to constrain types but, in the cases where this isn't needed or if the inferred types are already what you want (based on what functions are being used in the definition), then you can be lazy and not write them but still get the static typing benefits. Haskell allows both.

Re:That's all we need ...

[icebraining]

It's parametric polymorphism (a generic programming feature), not duck typing. Essentially, the compiler will generate (on compile-time, not runtime) two different instances of the factorial function, one for x as a float and one for x as an int.

If factorial is called with an invalid type (one for which the compiler can't generate a valid implementation of the function), that error will be detected at compile time.

Re:That's all we need ...

[Barbara, not Barbie]

I'd add getting rid of GLOBAL declarations inside functions, implementing proper variable scoping rules, and no auto-vivication of variables to that list. It needs a real clean-up.

Re:That's all we need ...

[siride]

You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable. The only methods you can call on a variable of that type are the pretty-print methods, but that's okay, because that's all you care about doing if you are just using the interface variable. Now you can create functions that take IDisplayable parameters. Any type throughout the hierarchy might implement this interface, but you don't care where, just that it has those methods. Without an interface, you must either restrict the functionality to a single class hierarchy, or rely on Object variables and reflection. Neither of these is desirable.

In C#, for example, you very frequently want methods that take an IEnumerable or ICollection of something, or return an IEnumerable. The actual object type might be List or an array or something more complicated. But you don't want to restrict yourself to one of those, because all you care about doing, for example, in taking an IEnumerable parameter, is looping through each element in the parameter. An array, a list, a dictionary or a method with the yield keyword would suffice. It allows you to specify desired behavior, not specific types. Without an interface, you'd *have* to ask for a list or an array or something specific and that would make the method less flexible.

In any case, it's not just about documentation, if it's indeed about documentation at all. It's a matter of functionality within the static type system. In a non-statically typed language, interfaces are obviously fairly useless (with some exceptions, like PHP's special interfaces that tell the compiler that your class can, for example, act as an array).

Re:That's all we need ...

[shutdown -p now]

Traits are coming in Java 8 with the addition of default method implementations to interfaces.

Re:That's all we need ...

[shutdown -p now]

You don't understand interfaces. They aren't just documentation. They allow you to actually do things that you wouldn't be able to do otherwise. Let's say you have an IDisplayable interface that provides some functions that let you pretty-print the contents of the object. Any object that belongs to a class that implements this interface can be assigned to a variable of type IDisplayable.

Interfaces are just a documentation in a dynamically typed language like PHP, since variables don't have types. The only other thing they give you there over duck typing is the ability to do instanceof checks.

Re:That's all we need ...

[Fallingcow]

Creating some consistency in needle/haystack vs. haystack/needle order in relevant built in functions would be high on my list of things for them to fix.

Making namespacing not suck balls would be nice.

Personally, I like "global" declarations in functions/methods--can't leave all the newbie-tripping-up fun to Python's explicit "self" argument, can we? :-)

Re:That's all we need ...

[hcs_$reboot]

needle/haystack vs. haystack/needle

Oh yes, this! I cannot imagine someone writing in C some PHP functions not implementing this mess on purpose. How come...

Re:That's all we need ...

[msobkow]

Interfaces are a method contract, not "fancy...documentation."

If you think interfaces are "just" documentation, you don't know SHIT about OO programming. Sorry dude, but your perspective is like saying that C/C++/C#/Java are "just" big macro assemblers because everything eventually runs on a CPU.

Re:That's all we need ...

[w_dragon]

Not true on so many levels. PHP variables do have types, you just don't have to declare them. If you don't understand that you'll be very confused when your integer becomes a float due to overflow and suddenly your output contains a bunch of numbers after the decimal. You can use type hinting on a method signature to make certain that the variable you get implements the interface you expect, exactly as you would in a statically typed language. If you aren't doing type hinting in PHP you're really ignoring one of the simplest safety features the language has.

Re:That's all we need ...

[Anonymous Coward]

PHP variables do have types, you just don't have to declare them.

No. Values have types, variables don't. (Type hinting doesn't count because 1) it only works for function parameters, and 2) it only works with class/interface names or "array" (for lulz, try running php -r 'function foo(boolean $x) { } foo(true);').)

Re:That's all we need ...

[rev0lt]

Multiple inheritance isn't a Java concept. It's a OO concept, older than java itself. Also, PHP isn't a OO development language, but a scripting language that supports OO constructs, and the latest releases have been focusing hard on modern OO funcionality. If you don't like a given feature, don't use it. Try do something in java that doesn't involve instantiation of an object.

Re:That's all we need ...

[Anonymous Coward]

Why do they keep pushing a server-side scripting language past where it should have ended?

If you need to do heavy lifting then you should offload that code to C or Java. Stop trying to be the Duct Tape (a 1000 uses that should never be used) of programming languages.

Re:That's all we need ...

[siride]

You said Java interfaces. In Java, they are not documentation. In PHP, you are mostly correct, as I indicated at the end of my post.

Re:That's all we need ...

[siride]

You aren't the guy I was replying to, but *he* said "Java interfaces" and I responded to that.

Re:That's all we need ...

[Barbara, not Barbie]

I never said multiple inheritance was a Java concept. In fact, I think one of the mistakes in Java was *not* supporting multiple inheritance, just like another one was stuffing everything into classes and objects.

Multiple inheritance in c++ is simple. People who think otherwise need to sit down for 15 minutes and review it to see how much better it is than interfaces.

Re:That's all we need ...

[garyebickford]

IIRC, not supporting multiple inheritance was one of the primary motivations for Java. Multiple inheritance (again, IIRC) makes it impossible to avoid ambiguities that a compiler can not resolve, thus making it easy to write programs that can be very difficult to debug. I haven't looked at this stuff for 20 years, so I don't recall perzackly. Not supporting MI meant the size of the Java compiler a small fraction of the size, and much more reliable. But others here can speak to this far better than I.

Re:That's all we need ...

[Barbara, not Barbie]

The rules of resolving the order of multiple inheritance are simple in c++. The problem is that java was supposed to be conceptually more along the lines of a "c++ for dummies" (garbage collection and no pointers, for example), and you get what you ask for.

Prior to java, many of us went down the "let's make everything into a class" in c++, and realized just how stupid that was. But history has a way of repeating itself.

Re:That's all we need ...

[K. S. Kyosuke]

I mean, can you infer from the above whether x can be a float or not?

Because of typeclasses?

Re:That's all we need ...

[tepples]

I understand the benefits of interfaces in a statically typed language such as Java. But in a dynamically typed language such as PHP or Python, method contracts are just "fancy documentation" because the runtime doesn't verify them until the last moment.

Re:That's all we need ...

[Anonymous Coward]

Yeah, but in Java folks feel the need to declare an interface for everything. Every Java project I've been on in has had an interface for every damn data access object.

Re:That's all we need ...

[Anonymous Coward]

If static typing is your kink you could always write your code using C and CGI.

Saying "PHP 5.4 Released" isn't that meaningful...

[bogaboga]

Telling us readers how it (the new PHP) measures up to the competition would have been better and more informative.

So, let me bite: How does this new release measure up to the competition?

Oh good Lord

[PCM2]

What synchronicity! Just the other day I was thinking about the beautiful and elegant poetry that is PHP's syntax and standard library, and I was saying to myself, "You know... if there's one thing PHP needs, it's multiple inheritance."

Re:Oh good Lord

[CastrTroy]

I don't even know why they added object oriented features in the first place. It's really hard to bolt something like Object Oriented features on to language that never had them. Not to mention that having half the standard library in OO and half in procedural just makes everything an even bigger mess. PHP would probably be a lot cleaner and more palatable had they never tried to add objects in the first place.

Re:Oh good Lord

[datavirtue]

Are you drunk?

Re:Oh good Lord

[hcs_$reboot]

Don't be too harsh about PHP. It's a rough language that allows almost anybody to write rough programs that eventually give rough results. A democratic language...

Re:Oh good Lord

[walterbyrd]

I never saw the need for OO in PHP either. I think the language was faster, and made more sense, without it.

Re:Oh good Lord

[Max Romantschuk]

What synchronicity! Just the other day I was thinking about the beautiful and elegant poetry that is PHP's syntax and standard library, and I was saying to myself, "You know... if there's one thing PHP needs, it's multiple inheritance."

I once asked the PHP developers at ZendCon about why they don't gradually clean up the standard library, and the impression that I got was that backwards compatibility is a top priority for PHP and Zend.

While I personally do prefer the Python way of planning gradual changes to the standard library along with migration paths I do also see the strength of leaving things the way they are. Fortunately there is more than one language to use for web develiopment if PHP won't float your boat.

Re:Oh good Lord

[PCM2]

I once asked the PHP developers at ZendCon about why they don't gradually clean up the standard library, and the impression that I got was that backwards compatibility is a top priority for PHP and Zend.

That's probably sensible, considering how many people use PHP environments that they don't actually control (on shared hosting providers, for example). Just because there's a new version of PHP doesn't mean everybody who uses WordPress (for example) will be able to take advantage of it. Also, some of the things that need cleaning up in the standard library (inconsistent parameter ordering, for example) could potentially break code in weird ways that won't actually crash. But all that just means the problem is bigger than it sounds; it doesn't mean the current situation is good.

PHP security

[lanner]

PHP has always been a security nightmare. Can anyone speak about security issues, enhancements, etc, that us sysadmins should know about?

Re:PHP security

[trparky]

Any programming language can be a security nightmare if used by people who don't know what they are doing. And even those that DO know what they are doing can still end up in a lot of trouble. Case in point... C++. All it takes is an unchecked buffer and tada... instant exploit!

Re:PHP security

[CastrTroy]

PHP has had some security issues, but they can largely be avoid. First, always use parameterized queries (prepared statements) using PDO or MySQLi. Register Globals, which was a big problem in the past has been removed in 5.4. Most of the security problems I'm aware of can be summed up in those two things. I think the reason it has such a bad reputation is that it has so many newbie developers on it, and because there are a lot of bad tutorials out there (possibly written by newbies) that show bad practices, such as not using parameterized queries.

Re:PHP security

[geminidomino]

One thing that I found myself curious about earlier this week.

I was trying to do up a proof-of-concept demonstration for the semi-PHB to explain the risk of SQL injections, and I couldn't make it work with MySQL (I know, I know...).

Is the fact that PHPs built in mysql_* function set doesn't do compound statements (multiple SQL queries in a single string/function call) a bug or a feature?

Re:PHP security

[Billly Gates]

Here is my code from my login page in php 4 that is super secure

$query_login="select * FROM user";
$result_login = mysql_query($query_login) or die("Your passwrod is might be bad I think"); //$login_check = mysql_num_rows($result_login);
while($row=mysql_fetch_array($result_login))
{
$username=$row["username"];
if ($username==$username1)
{
echo "";
echo "window.location.href='login_error.php?rec=qq';";
echo "";
exit;
}
}

Re:PHP security

[armanox]

It's my understanding that it's a feature for exactly that purpose (avoiding injection attacks).

Re:PHP security

[Lumpy]

Yet some major PHP pachages, like phpCommerce still uses register globals because the Devs are too damn lazy to spend time fixing it instead of adding features. Sadly some clients ask for steaming turds like phpCommerce in spite of warning from educated site admins.

90% of PHP security flaws are very poorly written scripts, NOT the language.

Re:PHP security

[ProzacPatient]

Dear god I hope you're not serious

Re:PHP security

[GPLHost-Thomas]

It's because of such examples that people are saying that PHP is a security nightmare. Truth is, if you know what you are doing, it isn't worse than anything else. As for the language itself, compare it to the Java virtual machine from SUN, which many think (IMO, wrongly) that is a much more professional language. Now count last year's CVE against Java, and compare them to the ones of PHP, then make your own idea...

Re:PHP security

[Fallingcow]

If by phpCommerce you mean osCommerce (phpCommerce turns up nothing relevant in Google) then that whole thing is a steaming pile of shit. Nothing short of nuking it from orbit and starting over would fix that tangled pile of bad code.

Re:PHP security

[devent]

Why were EGPCS (Environment, GET, POST, Cookie, Server) variables registered as global variables in the first place anyway? Who could think of it as a nice feature to just register variables from outside of the application? I think that speaks a lot of the environment of PHP and the community behind it.

Re:PHP security

[devent]

Why were EGPCS (Environment, GET, POST, Cookie, Server) variables registered as global variables in the first place anyway? Who could think of it as a nice feature to just register variables from outside of the application? I think that speaks a lot of the environment of PHP and the community behind it. PS: Sorry I reply to the wrong post.

Re:PHP security

[petermgreen]

IIRC it still doesn't provide a secure random number generator as part of the core language. Given it's target application often requires generating things like session IDs that if guessed can allow session hijacking that seems pretty inexcusable to me.

Re:PHP security

[garyebickford]

History. PHP was first developed in a world where security was not such an issue (I was using PHP 1.99s in about 1995), and was originally grown from a bunch of shell scripts. It was a simple system to solve simple problems. Present-day PHP is a vastly different language, having gone through at least two major reconstructions. But because of a desire to maintain backwards compatibility as much as possible compatible with security and other concerns, many early features have been retained, and are gradually being deprecated. The process has generally been to first provide new functionality as an option, then as the preferred approach, then standard practice, then the old feature is deprecated, and finally it is dropped from the language.

One company I am familiar with has a lot of PHP code that was originally written by a novice, running (I think) PHP 3, and used both global variables and register_globals and some other unsavory practices throughout. By the time 'real' programmers got involved there were hundreds or thousands of separate web pages that all depended on these characteristics. It's taken about three years so far for a team to gradually wean the system from these practices - there's just no budget to rewrite from scratch so it has to be done incrementally as part of the process of adding new capability and modifying existing code as needed for new business requirements. Once you have a large existing system, rebuilding from scratch is not usually a financially viable option for the average business.

Re:PHP security

[Anonymous Coward]

Rofl. That looks like every Java w/ Hibernate project I've seen. There's only so much you can do to force programmers to not be retarded, I guess :)

Re:PHP security

[geminidomino]

Yeah, but they should have at least fixed the language since then. It really doesn't help that PHP only has two variable scopes: Local (as in declared in the function, no apparent stack) and Global.

Leads to a whole lot of ugly shoving arrays up and down just to avoid using "global $foo;"

Re:PHP security

[Anonymous Coward]

While horrible in every other aspect.. this actually is secure?

Re:PHP security

[garyebickford]

I think you are out of date. PHP has for quite a while had classes with class variables and class constants.

It also has namespaces (which AFAIK apply to classes, constants and functions but not variables). If I understand correctly, the Global context is now actually just a default namespace.

Re:PHP security

[Anonymous Coward]

Don't forget Magic Quotes

Re:Saying "PHP 5.4 Released" isn't that meaningful

[Anonymous Coward]

well, it's PHP. And the competition is not PHP. So the competition wins.

It's better than Ruby's "best practices".

[Anonymous Coward]

The people who scream the loudest about how multiple inheritance or gotos are bad are the ones who also scream the loudest about "best practices", but in reality write some of the shittiest code there is.

Just look at Java and C#. The worst Java and C# developers are those who go on and on about design patterns. Then instead of writing software that solves real problems, they spend months and years putting together frameworks and obtuse architectures that are damn near impossible to use in practice.

Then there are the Ruby users. Basically everything they advocate is wrong. Maybe it lets you crank out yet another blog engine quickly, but what they propose falls apart completely for any moderately complex application. All it takes is debugging one problem caused by monkeypatching, and you'll immediately see how stupid their ideas are.

JavaScript "programmers" are the worst. Their language is so fucked up, but most of them are so ignorant that they can't see this for themselves. I mean, they didn't even manage to get equality comparisons implemented in a sensible manner! Yes, very core functionality like that is broken.

PHP has traditionally been just slightly better than JavaScript, in terms of developer stupidity, but at least they're making a small degree of progress in the right direction. We can't say the same for Ruby, though. In fact, we rarely hear about Ruby these days. The hype surrounding it sure has died down lately. This isn't completely unexpected. Consistent failures, like most sizable Ruby projects tend to be, can quickly kill even the loudest hype.

Re:It's better than Ruby's "best practices".

[datavirtue]

I took one look at Ruby and that was it. I was left in complete shock as to why it had any hype at all.

Re:It's better than Ruby's "best practices".

[csirac]

That's interesting; not that I use much Ruby any more either, but can you name any specific reasons why you felt this way?

Personally I loved the language - simple, elegant, intriguing ideas & patterns. I thought Hal Fulton's "The Ruby Way" was a great book, and I continue to use some of the ideas he wrote about even on current projects where I'm not using Ruby.

At the time, though, I completely rejected the Rails framework (circa 1.2.x?) for something that I thought had a much more reusable approach, Nitro/ogg - but now that's an abandoned framework which faded into obscurity, and people to associate Rails=Ruby, which is sad.

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

A week or two back, I started working on a perl script and realized I was sick of perl (for many reasons that I won't get into here). I had previously dismissed ruby (too much hype, too many retards on rails, monkey patching, too many stupid module names, etc) but when I actually looked it, it really fit my programming style. There are some things I don't care for (chief among them: no version of use strict). And 1.9 (which was a pretty significant upgrade) is now 4 years old yet debian and OS X are still on 1.8. Maybe it's slow, I don't know, don't care since I'm not using it for anything that's performance critical.

Re:It's better than Ruby's "best practices".

[luke923]

JavaScript "programmers" are the worst. Their language is so fucked up, but most of them are so ignorant that they can't see this for themselves.

True, which is why John Resig has the Khan Academy teaching JS in their intro to programming course, since a developer with an OOP background looks at it and doesn't scream, "WTF!." while looking at things like closures and JS scope issues (I'm looking at you, event callback!).

Hey, AC, would you agree that my sig is apropos for the topic at hand?

Re:It's better than Ruby's "best practices".

[luke923]

Should have read:

JavaScript "programmers" are the worst. Their language is so fucked up, but most of them are so ignorant that they can't see this for themselves.

True, which is why John Resig has the Khan Academy teaching JS in their intro to programming course, since a developer without an OOP background looks at it and doesn't scream, "WTF!." while looking at things like closures and JS scope issues (I'm looking at you, event callback!).

Hey, AC, would you agree that my sig is apropos for the topic at hand?

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

No.. it works for both cases..

Programmer with OOP background looks at JS: WTF???

Programmer without OOP background looks at JS: WTF???

Re:It's better than Ruby's "best practices".

[Rufty]

I love the language and my copy of "The Ruby Way" is just about my most read programming book. But the direction ruby's been going... Get good UTF support. Get real multithreading. Get a core of libraries ("gems") that have descriptive names but don't break every other week. Stop trying to be too clever or you'll end up like perl. And how about a GUI library that works on Mac, Win and Linux without having to compile QT and that doesn't look as crap as TK. I've just about given up on C ruby, now that jruby is useable. And python seems to have everything I want in extra libraries, just a shame the language isn't, well, ruby.

Re:It's better than Ruby's "best practices".

[MisterMidi]

Insightful my ass. The people who scream the loudest how fucked up some programming languages and how stupid their users are, are actually the worst.

Sane programmers however, just use what's best for the job. For example, what other programming language would you suggest for enhancing a webpage? VBScript? Or just throw in a Java applet like in the nineties?

If you think the equality comparisons of JavaScript are fucked up, I think you don't understand loose typing. If they don't do what you want, it's because you don't use them properly.

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

I've been a Perl programmer for a while, and decided to pick up Ruby. With the bad rap that Perl has, I figured my code would naturally clean up, but I noticed when I really looked at my Ruby code it was about the same (meaning my code is either always shitty, or I write decent looking Perl - you decide). From the base language standpoint, I think Ruby is a good language. The libraries are just terrible, and I'm not talking about obscure thing you pick up off rubyforge, I mean some of the basic libaries often packaged with the language itself. I've also gotten tired of trying to find an answer for something online, and pulling up nothing but random stuff asking questions about rails.

After years of trying to migrate myself to Ruby, I've gone back to Perl. I'm going to pick up Python next, which I was never too hip on from the looks of it, but I think I never gave it the proper chance. I'll miss the built in taint checking though.

Re:It's better than Ruby's "best practices".

[K. S. Kyosuke]

The people who scream the loudest about how multiple inheritance or gotos are bad are the ones who also scream the loudest about "best practices", but in reality write some of the shittiest code there is.

I have a suspicion that Sussman and Abelson are spot on in Chapter 2 of Structure and Interpretation of Computer Programs, when they describe the problem of MI as one that may be intractable. Or, it may be AI-complete, since I can't see how method resolution in MI can work in a way described by an algorithm short of implementing a reasoning system with human-like capabilities. The sentence

The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages.

is one of my favourite insights, at least from all those that I gained from that book.

Re:It's better than Ruby's "best practices".

[rev0lt]

Sane programmers however, just use what's best for the job.

This. Why all the good ones appear when I'm out of modpoints?

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

What is this modded insightful instead of flamebait?

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

There's also Ramaze, Sinatra or even plain Rack for Ruby.

Re:It's better than Ruby's "best practices".

[ducomputergeek]

That's why I still use Perl. I've been using basically the same API script I wrote for database interactions in 2003. Yes it's procedural Perl, not OO, but as I've had to show younger programers: guess what it STILL works and it's not a lot of overhead for maintenance. I think the last major update I've done to the script was adding the ability to return data in JSON in addition to XML circa 2008 or 2009. And that work took basically two days to implement and test. Now I admit, there are some nasty elsif statements that would look much better if I moved to a switch statement, but that means it wouldn't work in Perl 5.8.x. Frankly it's not broke so....

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

Or programmer who knows that "Object Oriented" does not equate to class-based inheritance looks at JS and goes, oh, it uses prototypes like other Self-inspired languages.

Re:It's better than Ruby's "best practices".

[Anonymous Coward]

Or programmer who thinks that if someone critisises Javascript then they must not understand it gets punched in the face.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[Rijnzael]

If you want opinion, go read an op ed in your local news, or if you really need technology opinion pieces, go read a PC World or what have you. PHP 5.4 being released is news people will care about, hence it being here.

hello, anybody out there?

[Anonymous Coward]

what the hell are we supposed to do with 5.4 when so many apps/scripts out there haven't even been fixed to handle the kinks in 5.3? and many hosters haven't even put 5.3 on their servers yet.

Re:hello, anybody out there?

[martypantsROK]

I'm still waiting for 5.3 on my hosting server and that's been out a good while. I don't guess I'll have to worry about 5.4 for another year or three

Re:hello, anybody out there?

[M0j0_j0j0]

If it is working, don't touch it!!

Re:hello, anybody out there?

[Anonymous Coward]

what the hell are we supposed to do with 5.4 when so many apps/scripts out there haven't even been fixed to handle the kinks in 5.3? and many hosters haven't even put 5.3 on their servers yet.

So you think the php dev team should stop all work until your hosting provider catches up? Or are you saying the dev team needs to convince your hosting provider to upgrade?

Re:hello, anybody out there?

[wimg]

Using the PHPCompatibility Codesniffer rules will get you a long way : https://github.com/wimg/PHPCompatibility

Re:hello, anybody out there?

[GPLHost-Thomas]

A good host will have a system in place so that you can choose what version you want to use, as well as chroot in all vhosts and such security protections. If your current host doesn't have this, move away...

Re:hello, anybody out there?

[GPLHost-Thomas]

Then you aren't hosted by someone serious. PHP 5.2 is EOL, and has no security support, plus there has been some security issues recently on it. You're at risk, move away.

Re:hello, anybody out there?

[GPLHost-Thomas]

It isn't working, and has security issues, so please upgrade...

Re:hello, anybody out there?

[GPLHost-Thomas]

Hi. This is a very good tip. Do you think it'd be a good idea to include this in Debian, and run it on all the archive? I'm currently making it as a Debian package, and will consider uploading it to SID.

Re:hello, anybody out there?

[wimg]

Keep in mind that it doesn't guarantee full compatibility with PHP 5.4, but it does all the automated checks it can do, so that's a huge timesaver.
Including it it Debian or any other distribution is certainly a good idea. But I recommend waiting a week or two... I just released it today, so there may be some minor bugs in there...

Re:hello, anybody out there?

[Anonymous Coward]

Or he is hosted on RHEL and you have no idea what you are talking about, Mr "Version numbers tell you everything"

Re:hello, anybody out there?

[tepples]

If your current host doesn't have this, move away

I can't necessarily afford to pay the cost of moving all users of my application to other hosts, especially if they have locked into 24 month contracts in exchange for a discount.

Re:hello, anybody out there?

[GPLHost-Thomas]

Well, it's you who made the choice of locking yourself for 24 months, IMO. Also, you may consider that having the server you are on being hacked is a greater cost than choosing to willingly move to a better host, even if the later cost you money.

Re:hello, anybody out there?

[tepples]

Well, it's you who made the choice of locking yourself for 24 months, IMO.

If I develop a web application installed on web sites operated by my customers, then it's my customers who demand updates to the application despite being locked in.

Also, you may consider that having the server you are on being hacked is a greater cost than choosing to willingly move to a better host, even if the later cost you money.

Let's try a thought experiment: Would WordPress and phpBB, web applications deployed on thousands of hobbyist and commercial web sites, suddenly up and switch to Python if PHP were discovered to have a deep security hole? No; they'd do their best to work around it.

Mod parent up

[Anonymous Coward]

This is so damn insightful!

Parameterised queries are a canard

[Anonymous Coward]

If you mean 'use some simple method' to defeat SQL injection. (And let's face it it isn't difficult but some people find it hard.) then that's a fair point. If you mean 'stored procedures' then that's a sledgehammer to crack a nut which introduces yet another layer in an already complex stack. If people are not using OO to do their database access then they get what they deserve!

Re:Parameterised queries are a canard

[Anonymous Coward]

This one complains about a sledgehammer while advocating for a pile driver.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[kale77in]

well, it's PHP. And the competition is not PHP. So the competition wins.

No, the competition is, for example, .NET, which is unable to win.

how about some new template features?

[GabboFlabbo]

It'd be really nice if PHP would add some nice template features that Smarty / Twig have. (elseforeach, simple echo htmlentities construct ?)

The developers of PHP are so focused on becoming a real language that they've forgotten what PHP is all about: templating! There's no real focus on adding template features (ok... I don't have to type array now...).

PHP 6 crashed

[watermark]

"... from the now-crashed PHP 6.0 project...". When did PHP 6 crash? I was looking forward to some of those features.

Re:PHP 6 crashed

[wimg]

Almost everything planned for PHP 6 is in 5.4, except for full unicode support, which was slowing down the entire language too much.

Re:PHP 6 crashed

[tepples]

So until PHP has full Unicode support, how do I prevent PHP from dying with "Cannot modify header information - headers already sent"? This happens when a text editor inserts a UTF-8 byte order mark in front of the <?php that begins every PHP program, and I know of a few text editors that do this if even one non-ASCII character is in a PHP source code file.

Re:PHP 6 crashed

[wimg]

The problem here might not be the open tag, but closing tag. If you use include(_once) or require(_once) and you used a closing tag in the file you're trying to include or require, you hve to be careful nothing follows that closing tag (like a newline...).
The best option is :
- Never to use a closing tag, since it's optional anyway
- To use a standard PHP IDE to write your code

Re:Saying "PHP 5.4 Released" isn't that meaningful

[Anonymous Coward]

If you want opinion, go read an op ed in your local news, or if you really need technology opinion pieces, go read a PC World or what have you. PHP 5.4 being released is news people will care about, hence it being here.

I care, that is why I'm here.

LDAP Paging

[Anonymous Coward]

Finally the LDAP extension has paging support. About damn time.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[hcs_$reboot]

A language named after a main TLD sounds, indeed, a bit iffy. Maybe the nostalgia of the late .COM?

Re:Saying "PHP 5.4 Released" isn't that meaningful

[datavirtue]

Score, booyah, bitch slap, slam dunk.

Just add water and wait. And wait.

[Sneeka2]

Goody! Just another 5 years 'till it hits the production servers now.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[Anonymous Coward]

You base your criticism of a platform (not a language) on its name? Seems pretty arbitrary.

On top of that, the old platform was just called COM (no dot).

For what it's worth, I've used pretty much all the well-known languages out there (OO languages, functional ones, dynamic ones) and I have to say that the .NET framework and C# are pretty damn good. In particular, the C# language designers are really good at incorporating the good ideas from other languages but keeping the syntax from spiraling out of control (a la C++).

Not that this opinion will garner much praise on slashdot.

CAPTCHA: informed

Scan your code, folks

[wimg]

If you want to get your code compatible, a start is to scan it automatically : https://github.com/wimg/PHPCompatibility - just released for 5.4 as well :-)

Re:Scan your code, folks

[GPLHost-Thomas]

I just tried it, and however I put it, I always got loads of "Spaces must be used to indent lines; tabs are not allowed" or "Line indented incorrectly; expected at least 4 spaces, found 1". How do I tell phpcs to behave as it should, and only warn about important things (eg, in my case, only check 5.4 compatibility)? I tried "phpcs --standard=PHPCS --sniffs=PHP .", but then I get: PHP Notice: Undefined offset: 1 in /usr/share/php/PHP/CodeSniffer/CLI.php on line 328, PHP Notice: Undefined offset: 2 in /usr/share/php/PHP/CodeSniffer/CLI.php on line 328. What I am doing wrong?

Re:Scan your code, folks

[wimg]

You might want to read http://techblog.wimgodden.be/tag/codesniffer/
Make sure you have PHP_CodeSniffer version 1.3, not 1.2, otherwise it won't work...

Re:Scan your code, folks

[GPLHost-Thomas]

I did read it, and I did use 1.3. I even wrote a package and would have like to upload it in Debian SID, if it is worth a try, and maybe run it on all the Debian archive to make sure everything is correctly updated for PHP 5.4. But see the above, it's not usable. It seems to me that you were using explode with a dot instead of a coma around that line 328. If you can, please get in touch with me (my IDs are available here: http://www.gplhost.com/gplhost-contact.html) so we can discuss the mater.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[hcs_$reboot]

Not that this opinion will garner much praise on slashdot

I don't agree, /. changed since a couple of years. Bashing Microsoft or its products generally flags a Troll or a -1 anyway. The top post related to .NET here is being "Troll". Well, /. didn't change actually. More people read it, from more communities, including MS and the like. /. being (I think) fair in terms of moderators, the "new" people from those communities flag the bashers all the time. Even the Microsoft logo changed recently, the new one being more neutral.

Traits are cool

[greywire]

I've been waiting for traits in php (and thus php 5.4 when they finally decided to put traits into it) for some time now.

Think of traits not as really an extension to the object oriented features (alternative to multiple inheritance..) but as a kind of language assisted cut and paste with conflict resolution.

Because that's what it is. Traits are "flattened" at run time. Their methods become methods of the class where the trait is used, and work exactly like they were defined there to begin with. If there is a collision in the naming, you can specifically resolve that with language syntax.

Zend breakage technology strikes again

[laffer1]

Can't they just release a new version of PHP that doesn't break backward compatibility. Microsoft was able to do this with classic ASP and for the most part .NET for many years now. Sun and Oracle figured out how to do it with Java. Why can't Zend do it?

I'm tired of having features disappear. Yeah, magic quotes and safe mode were stupid. Maybe if they actually designed the damn language rather than throw in crap all the time this wouldn't happen.

This is the single biggest issue I have with PHP.

Re:Zend breakage technology strikes again

[GPLHost-Thomas]

If you think that PHP === Zend, then you are mistaking. Zend aren't the ones behind the language itself, which is made in an open source way. As for compatibility, there's not much that changed, and it's very easy to fix. If people can't maintain their code, then it's not worse using what they do.

Re:Zend breakage technology strikes again

[laffer1]

This is ridiculous. You think every time a SECURITY update comes out I should modify my code for every app I've ever written. I don't think so.

See that's what this is, a security update. They don't support old versions of PHP so it's a forced upgrade. Thus backward compatibility is important. Yeah, there's only a few things here and there between individual releases, but consider someone hosting on CentOS and then a new CentOS comes out. Suddenly they're 2 major releases ahead. Nothing works.. the sysadmin didn't tell the programmers he was updating CentOS. Now the company website is down. You can put blame at various levels here. The sys admin who didn't test first. The programmers who used an API that Zend killed. The architect that made the mistake to use PHP to begin with. The shit storm comes down on the programmers because the site was down and they had to do things to fix it. That's just how the world works.

Btw Zend actually says "Zend: The PHP Company". They want to be known as PHP so I give it to them.

Re:Zend breakage technology strikes again

[GPLHost-Thomas]

You think every time a SECURITY update comes out I should modify my code for every app I've ever written.

That's absolutely not what I wrote. I just think that you should keep your apps being able to run with CURRENT version of PHP, because one day, the old one will be EOL. This means, make sure that it will fit the next major PHP release. This is truth with absolutely all languages (look at python for example). We know well in advance what type of change will happen, and it's easy to prepare things well in advance. Also, distributions (well, at least Debian) maintain older versions of PHP for quite some time after a new version of PHP is available (PHP 5.3 will continue to be supported for at least 1 year and a half). PHP itself (the language) is also maintained for a while. So you really do have time to adapt, and there is nothing to rush for, you should just do the work in a reasonable time frame (that is, in less than a year). Again, the changes are really trivial!

consider someone hosting on CentOS and then a new CentOS comes out. Suddenly they're 2 major releases ahead. Nothing works.. the sysadmin didn't tell the programmers he was updating CentOS. Now the company website is down.

That's a really stupid scenario that has absolutely NOTHING to do with what I wrote. Of course, the programmers and the administrators should talk to each others, and the programmer should prepare well in advance an upgrade, and make sure his application has been tested to run with the new version of PHP. It's the administrator's job to make sure he has confirmation from the programmer that it will work. And that doesn't invalidate my argument that the code should move forward and stay current...

You can put blame at various levels here. The sys admin who didn't test first. The programmers who used an API that Zend killed. The architect that made the mistake to use PHP to begin with.

No, here, I blame the manager who's job is to have both teams (sysadmin and programmers) to talk to each other.

The shit storm comes down on the programmers because the site was down and they had to do things to fix it.

Really? Who exactly took the decision to upgrade? Shouldn't it be the one who destroyed (eg: the sys-admin) that should fix?

Btw Zend actually says "Zend: The PHP Company". They want to be known as PHP so I give it to them.

Put it the way you want, the company called Zend isn't driving PHP which is open source, and developed as such. Zend is mainly focused on the Zend framework, even though they also contribute to the language itself. I know that from an actual Zend employee living in Israel, who is doing some packaging work for them who also is a Debian developer, and who I talked with at last debconf and through the PKG-PHP Debian mailing list (Zend has its own packages of PHP). So I think it's a quite reliable source here.

Re:Zend breakage technology strikes again

[laffer1]

My original point has been lost in this discussion and that's it doesn't have to be this way. Microsoft and Sun found a way to avoid this. It can be done. You seem to point at lack of proper planning for rollout but I see lack of proper planning at designing the language. Both are problems.

I'm not sure OO is a good idea for web development

[walterbyrd]

But that's just me.

Why "use" instead of "uses"?

[Phantasmagoria]

GRRR. "extends" was for inheritance, "implements" was for interfaces, so why wasn't "uses" chosen for traits, instead of "use"?
 

Re:Why "use" instead of "uses"?

[nyctopterus]

Because this is PHP, man! Home of mysql_real_escape_string()!

Re:Why "use" instead of "uses"?

[Anonymous Coward]

Actually, mysql_real_escape_string() is originally from MySQL's C API. Which just goes to show that MySQL is just as shitty as PHP.

Re:Why "use" instead of "uses"?

[tomhath]

Because it's really more like "import".

That's not true in general.

[warrax_666]

Dynamic/static and strict/weak are orthogonal in general. A dynamically typed language could just as easily verify that all necessary methods defined by an interface are implemented by an implementation -- it's just that the check would happen at run-time rather than compile time.

Re:That's not true in general.

[shutdown -p now]

It can verify at declaration site, but at call site, dynamic typing (= values have types, variables don't) implies duck typing, meaning there's no information about which interface is expected to be seen at that point to do any verification.

Re:I'm not sure OO is a good idea for web developm

[Anonymous Coward]

Why wouldn't it be?

Re:I'm not sure OO is a good idea for web developm

[Chysn]

I can say that it's not just you. LOTS of people are wrong about this.

There are plenty of reasons, but one of the best ones is that "web development" isn't necessarily separate from other development. If you're using the same data structures and operations across multiple targets (web, desktop, mobile), OO is definitely a good idea.

Re:I'm not sure OO is a good idea for web developm

[Anonymous Coward]

How is the server side code of a web application different than any other OO codebase? The worst PHP codebases are the procedural variety mixing PHP, SQL, HTML, CSS and javascript in randomly hacked together scripts. I've been unfortunate enough to inherit several of these over the years... THE HORROR!

Re:I'm not sure OO is a good idea for web developm

[K. S. Kyosuke]

Because functional programming with continuations just may be a better approach to taming stateless HTTP?

Re:I'm not sure OO is a good idea for web developm

[Anonymous Coward]

If you like continuations you can certainly have them in an OOP language, or even a hybrid OOP/functional one if that's your thing.

Parameterizing the right side of operator IN

[tepples]

First, always use parameterized queries (prepared statements) using PDO or MySQLi.

I agree with you that queries in MySQLi should almost always be parameterized. But in moving from "almost always" to "always", I have found a few stragglers where I still think I have to use $db->escape($some_value). For example, how do I use MySQLi with parameterized queries that have a variable number of parameters, such as username IN ('filbert', 'bluebear', 'lucky') where the number of names on the right side of operator IN may vary? I'd have to build three things in parallel: the statement with a variable number of ? placeholders, the string of argument types, and the array of values. I'd have to construct the array of values differently for the different versions of PHP, whose semantics of call_user_func_array differs from PHP version to PHP version. I'd also have to be extra careful to make sure that the order of ? placeholders in the statement stays in sync with the order of items in the array of values, as letting them fall out of order is just as dangerous as letting an SQL injection slip through. Or should I just bite the bullet and port the entire application from MySQLi to PDO, which supports named placeholders?

Re:Parameterizing the right side of operator IN

[CastrTroy]

I would go for the last option, and start any new projects using only PDO. First there's the example of named parameters, and second, your library isn't tied by name to the database. So, in the event you wanted to write code that was database agnostic, or if you wanted to change databases mid project, you could do it. As a .Net developer, the whole idea of having completely different libraries for connecting to different databases is just absurd.

Can't even use the same language

[tepples]

How do you use the same data structures across all targets when you can't even use the same language across all targets? The client side of web must use JavaScript, and the client side of mobile must use C# unless you have a separate team for the Windows Phone 7, Android, and iOS versions.

Re:Can't even use the same language

[Chysn]

First, using the same data structures is fairly easy across multiple languages because the same object-oriented principles usually apply. Second, if you use web services to be consumed across your platforms, you don't need to duplicate business logic in more than one language (you can at least minimize it). Third, you're mentioning three mobile platforms that pretty much require an OO approach in their respective languages (C#, Java, and Objective-C), so why would you throw out the entire approach for the web?

It's the open tag

[tepples]

The problem here might not be the open tag

I've seen the misbehavior even in projects whose coding style guide forbids a final closing tag. In such files, the open tag is the only possible culprit. The issue is that a lot of programming language interprets cannot be configured to treat 0xEF 0xBB 0xBF, the UTF-8 byte order mark that several text editors automatically insert at the start of a file, as something to skip. Nor can several popular text editors, especially text editors designed to run on the Windows operating system, be configured to never insert the byte order mark. Or should developers always follow strict internationalization guidelines and include human-readable text only in external PO files, never in a PHP file?

To use a standard PHP IDE to write your code

What is "the standard PHP IDE" in the way that Visual Studio is "the standard C# IDE" and NetBeans or Eclipse is "the standard Java IDE"?

Re:It's the open tag

[wimg]

To fix your problem, set 'zend.multibyte = 1' in php.ini

Re:It's the open tag

[tepples]

Thank you. This brings up another question: By when do you expect most shared web hosts to have adopted PHP 5.4, which according to this page is the first to include zend.multibyte?

Re:It's the open tag

[wimg]

Actually it will already work on PHP 5.2/5.3 if it was compiled with --enable-zend-multibyte but that will depend on the hosting provider or the distribution being used.

So checking whether the host has this enabled (phpinfo() will tell you) is your best bet.
For 5.4 you still need to have it compiled with --enable-zend-multibyte but now you can disable it in php.ini

The fact that 5.4 doesn't introduce any backward incompatibilities should also increase the adoption rate significantly.

Re:It's the open tag

[Acaeris]

These days Netbeans and Eclipse/Zend Studio are the most commonly used PHP IDEs as well as far as I'm aware.

Re:Saying "PHP 5.4 Released" isn't that meaningful

[Hognoxious]

I don't care, but I've got nowhere else to go.

JS vs PHP equality sanity

[PSdiE]

.. [JS] didn't even manage to get equality comparisons implemented in a sensible manner!

Yeah, coz PHP really *shines* for equality comparisons.

        switch("dog") {
                case 0 : echo("Won't see this, nosir."); break;
                case "dog" : echo("This will be shown, promise."); break;
        }
        if("123" == " 123") echo("Hmmm ... I expected string comparison, but whatever.");
        if("123" == "123 ") echo("You'll at least be consistent about trimming though, right?");

JavaScript gets loosely-typed comparison operations pretty spot on IMO - i.e., logical and intuitive results, including for "truthiness" evaluation. Of course, like any language it has its share of quirks - e.g.:

        if( parseInt("0123") != 123) alert("Eeek - are you *really* defaulting to Octal radix for zero-padded nums, parseInt?!");
        if(typeof null == "object") alert("Meh, Netscape!");
        if( myDate.month == 11 ) alert("December, ORLY?");

Work Offline

[tepples]

First, using the same data structures is fairly easy across multiple languages

But if I make changes to a data structure or object in one language, how do I arrange for the changes to propagate automatically to the other languages?

if you use web services to be consumed across your platforms, you don't need to duplicate business logic in more than one language (you can at least minimize it)

I'm familiar with JSON web services. But the business logic has to be duplicated on the client if the application has any hope of being able to run offline or use peripherals such as the accelerometer, camera, and microphone. Otherwise I could just make a web application.

Third, you're mentioning three mobile platforms that pretty much require an OO approach

I wasn't saying OO was a bad idea, just that an application designed to work offline must implement business logic on the client side. So must an application designed to be more responsive than the fairly large ping of a satellite or 3G connection.