Slashdot Mirror
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."
Let's call it what it is, Anti-Social Media.
GOTO is perfectly fine in some situations. Using a technique badly doesn't make the technique bad itself. It's just stupid users.
Difficult to write assembly without "goto"
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.
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.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
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?
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."
Breakfast served all day!
PHP has always been a security nightmare. Can anyone speak about security issues, enhancements, etc, that us sysadmins should know about?
well, it's PHP. And the competition is not PHP. So the competition wins.
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.
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
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...).
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
Almost everything planned for PHP 6 is in 5.4, except for full unicode support, which was slowing down the entire language too much.
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 :-)
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.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
There's absolutely nothing wrong with goto. Just people who abused it and it got a bad reputation.
Let's call it what it is, Anti-Social Media.
But that's just me.
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).
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.
GRRR. "extends" was for inheritance, "implements" was for interfaces, so why wasn't "uses" chosen for traits, instead of "use"?
Loban Amaan Rahman ==> Anagram of ==> Aha! An Abnormal Man!
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.
I do not fail; I succeed at finding out what does not work.
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.)
Ezekiel 23:20
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).
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.