Posted
by
Soulskillon Saturday March 03, 2012 @09:10PM
from the onward-and-upward dept.

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."

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.

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.

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 al

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.

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.

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 ignori

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.

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.

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.

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.

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.

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.

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 con

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.

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 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.

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.

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 [php.net], 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.

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...

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.

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.

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.

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.

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...).

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

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 [gplhost.com]) so we can discuss the mater.

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.

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.

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.

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 sys

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).

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.

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 ve

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.

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.

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):

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.

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.

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 langu

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.

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 actua

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

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 clas

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, Displa

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

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.

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, Nit

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 i

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.

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 [mit.edu], 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.

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?

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.

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.

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...

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.