×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PHP 5.4 Released

Soulskill posted more than 2 years ago | from the onward-and-upward dept.

PHP 209

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

209 comments

advantages of multiple inheritance (1, Insightful)

Anonymous Coward | more than 2 years ago | (#39235229)

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 (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39235247)

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 (2, Informative)

Anonymous Coward | more than 2 years ago | (#39235301)

Difficult to write assembly without "goto"

Re:advantages of multiple inheritance (1)

Anonymous Coward | more than 2 years ago | (#39235371)

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 (1)

Anonymous Coward | more than 2 years ago | (#39235515)

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

Re:advantages of multiple inheritance (0)

Anonymous Coward | more than 2 years ago | (#39235559)

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 (2)

siride (974284) | more than 2 years ago | (#39236771)

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 (1)

buchner.johannes (1139593) | more than 2 years ago | (#39235483)

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 (1)

Anonymous Coward | more than 2 years ago | (#39236087)

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 (2)

CastrTroy (595695) | more than 2 years ago | (#39235511)

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 (1)

datavirtue (1104259) | more than 2 years ago | (#39235861)

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

Re:advantages of multiple inheritance (3, Insightful)

Barbara, not Barbie (721478) | more than 2 years ago | (#39236277)

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 (4, Interesting)

bieber (998013) | more than 2 years ago | (#39235311)

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 (0)

Anonymous Coward | more than 2 years ago | (#39235519)

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 (1, Interesting)

buchner.johannes (1139593) | more than 2 years ago | (#39235531)

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 (2)

petsounds (593538) | more than 2 years ago | (#39235635)

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 (1)

Compaqt (1758360) | more than 2 years ago | (#39236061)

>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 [racket-lang.org] incorporated into it. We already have those, so why reinvent the wheel?

Re:advantages of multiple inheritance (0)

Anonymous Coward | more than 2 years ago | (#39236423)

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 (2, Informative)

Daniel Dvorkin (106857) | more than 2 years ago | (#39235323)

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 (0)

Anonymous Coward | more than 2 years ago | (#39235685)

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 (1)

Daniel Dvorkin (106857) | more than 2 years ago | (#39235705)

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.

It's better than Ruby's "best practices". (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39235443)

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.

Mod parent up (1, Funny)

Anonymous Coward | more than 2 years ago | (#39235525)

This is so damn insightful!

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

datavirtue (1104259) | more than 2 years ago | (#39235899)

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". (1)

csirac (574795) | more than 2 years ago | (#39236267)

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". (0)

Anonymous Coward | more than 2 years ago | (#39236349)

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". (1)

luke923 (778953) | more than 2 years ago | (#39236603)

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". (1)

luke923 (778953) | more than 2 years ago | (#39236637)

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:advantages of multiple inheritance (1)

buchner.johannes (1139593) | more than 2 years ago | (#39235453)

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 (1)

datavirtue (1104259) | more than 2 years ago | (#39235853)

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 (1)

Lord_Naikon (1837226) | more than 2 years ago | (#39236567)

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 (0)

Anonymous Coward | more than 2 years ago | (#39236867)

See also: Ruby Mixins.

That's all we need ... (4, Insightful)

Barbara, not Barbie (721478) | more than 2 years ago | (#39235237)

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

Anonymous Coward | more than 2 years ago | (#39235265)

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

Re:That's all we need ... (0)

Anonymous Coward | more than 2 years ago | (#39235459)

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

Re:That's all we need ... (4, Insightful)

Daniel Dvorkin (106857) | more than 2 years ago | (#39235367)

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

buchner.johannes (1139593) | more than 2 years ago | (#39235541)

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

Daniel Dvorkin (106857) | more than 2 years ago | (#39235601)

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

siride (974284) | more than 2 years ago | (#39236811)

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

Anonymous Coward | more than 2 years ago | (#39235379)

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

tomhath (637240) | more than 2 years ago | (#39235387)

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

icebraining (1313345) | more than 2 years ago | (#39235485)

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

arth1 (260657) | more than 2 years ago | (#39235743)

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

Anonymous Coward | more than 2 years ago | (#39235825)

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

Anonymous Coward | more than 2 years ago | (#39235877)

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

Anonymous Coward | more than 2 years ago | (#39235923)

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

icebraining (1313345) | more than 2 years ago | (#39235931)

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

buchner.johannes (1139593) | more than 2 years ago | (#39235493)

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

Anonymous Coward | more than 2 years ago | (#39235691)

I blame the Jews for this.

Re:That's all we need ... (1)

hcs_$reboot (1536101) | more than 2 years ago | (#39235881)

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

Barbara, not Barbie (721478) | more than 2 years ago | (#39236249)

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.

Saying "PHP 5.4 Released" isn't that meaningful... (3, Interesting)

bogaboga (793279) | more than 2 years ago | (#39235325)

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?

Re:Saying "PHP 5.4 Released" isn't that meaningful (4, Funny)

Anonymous Coward | more than 2 years ago | (#39235397)

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

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

kale77in (703316) | more than 2 years ago | (#39235665)

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.

Re:Saying "PHP 5.4 Released" isn't that meaningful (1, Insightful)

hcs_$reboot (1536101) | more than 2 years ago | (#39235901)

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 (2, Insightful)

Anonymous Coward | more than 2 years ago | (#39235983)

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

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

hcs_$reboot (1536101) | more than 2 years ago | (#39236089)

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.

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

Rijnzael (1294596) | more than 2 years ago | (#39235451)

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.

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

Anonymous Coward | more than 2 years ago | (#39235809)

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.

Oh good Lord (4, Funny)

PCM2 (4486) | more than 2 years ago | (#39235385)

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 (3, Insightful)

CastrTroy (595695) | more than 2 years ago | (#39235535)

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 (1)

walterbyrd (182728) | more than 2 years ago | (#39236531)

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 (2)

hcs_$reboot (1536101) | more than 2 years ago | (#39236033)

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

PHP security (2)

lanner (107308) | more than 2 years ago | (#39235391)

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

Re:PHP security (0)

trparky (846769) | more than 2 years ago | (#39235471)

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 (4, Informative)

CastrTroy (595695) | more than 2 years ago | (#39235479)

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.

Re:PHP security (1)

geminidomino (614729) | more than 2 years ago | (#39235527)

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 (4, Funny)

Billly Gates (198444) | more than 2 years ago | (#39235767)

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 (2)

ProzacPatient (915544) | more than 2 years ago | (#39236005)

Dear god I hope you're not serious

Re:PHP security (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#39236707)

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 (1)

armanox (826486) | more than 2 years ago | (#39235785)

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

Parameterised queries are a canard (0)

Anonymous Coward | more than 2 years ago | (#39235557)

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 (1)

Anonymous Coward | more than 2 years ago | (#39235739)

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

Re:PHP security (0)

Lumpy (12016) | more than 2 years ago | (#39235841)

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 (-1)

Anonymous Coward | more than 2 years ago | (#39235749)

I don't think PHP has been a security nightmare. I think the fact that PHP has a lot of developers with a little amount of programming skills have made it a nightmare. My advice to sysadmins is make sure you have competent developers pushing code to your box. They don't need to know security in terms of PHP per se, but, they need to know about general web development security items: prepared SQL statements/parameterized SQL, how to prevent XSS and XSRF attacks, validate all input, etc. Also, using a framework like ZF or Symfony can help a little with with some of these issues.

hello, anybody out there? (1)

Anonymous Coward | more than 2 years ago | (#39235505)

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? (1)

martypantsROK (1413651) | more than 2 years ago | (#39235581)

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? (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#39236725)

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? (0)

Anonymous Coward | more than 2 years ago | (#39236003)

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? (1)

wimg (300673) | more than 2 years ago | (#39236057)

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

Re:hello, anybody out there? (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#39236763)

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? (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#39236719)

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

how about some new template features? (2)

GabboFlabbo (595073) | more than 2 years ago | (#39235723)

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 (1)

watermark (913726) | more than 2 years ago | (#39235783)

"... 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 (2)

wimg (300673) | more than 2 years ago | (#39236067)

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

LDAP Paging (1)

Anonymous Coward | more than 2 years ago | (#39235851)

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

Just add water and wait. And wait. (1)

Sneeka2 (782894) | more than 2 years ago | (#39235955)

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

Scan your code, folks (5, Insightful)

wimg (300673) | more than 2 years ago | (#39236077)

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

Traits are cool (2)

greywire (78262) | more than 2 years ago | (#39236093)

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 (1)

laffer1 (701823) | more than 2 years ago | (#39236353)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...