PHP Classes

PHP is the Best Competitor of PHP - Lately in PHP podcast episode 47

Recommend this page to a friend!
  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP is the Best Compe...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)  


Viewers: 9

Last month viewers: 3

Categories: Lately in PHP Podcast, PHP opinions

PHP developments gained new life thanks mostly to Facebook Hack language and Zend reaction with PHPNG. Since Facebook Hack is mostly a fork of PHP, it seems PHP is the main competitor of PHP.

These developments were one of the main topics discussed by Manuel Lemos and Michael Kimsal in the episode 47 of the Lately in PHP podcast.

They also discussed new proposals for the next PHP versions like negative string offsets, offsets to Reset() and End(), a mail handling interface similar to session handlers, error handling in, and return type hinting declarations.

Now listen to the podcast, or watch the hangout video, or read the transcript to learn more about these interesting PHP discussions.

Loaded Article


Introduction (0:20)

PHP Releases 5.4.28, PHP 5.5.12, PHP 5.6 beta 2 (1:09)

Negative String offsets (10:03)

Adding offsets to Reset() and End() (15:55)

Mail Handling (19:22)

Error Handling on (33:59)

Return Type Declarations (38:52)

PHPNG Dramatic Speedup Features Coming in PHP 6 Release (42:56)

JavaScript Innovation Award Winners of February 2014 (52:38)

PHP Innovation Award Winners of February 2014 (57:18)

PHP Innovation Award Rankings of 2014 (1:08:18)

Conclusion (1:10:37)


Listen or download the podcast, RSS feed and subscribe in iTunes

Watch the podcast video, subscribe to the podcast YouTube channel

Read the podcast transcript

Click on the Play button to listen now.

Introduction music Harbour used with explicit permission from the author Danilo Ercole, from Curitiba, Brazil

View Podcast in iTunes

RSS 2.0 feed compliant with iTunes:

In iTunes, use the Subscribe to Podcast... item of the Advanced menu, and then enter the URL above to subscribe to this podcast.

Watch the podcast video

Note that the timestamps below in the transcript may not match the same positions in the video because they were based on the audio timestamps and the audio was compacted to truncate silence periods.

See the Lately in PHP podcast play list on YouTube and Subscribe to this channel there.

Show notes

Introduction (0:20)


Manuel Lemos: Hello. Welcome to the Lately in PHP podcast, Hangout. This is Episode 47. And this time, I have... back with us... the great Michael Kimsal. He returned from the desert, right?

Hello, Michael.

Michael Kimsal: Good morning. Or Goedemorgen. Because my surroundings are slightly different from last time we spoke.

Manuel Lemos: Yeah, it's like you've been having too much work.

Michael Kimsal: Yes. That's exactly. That's why.

Manuel Lemos: I'll be archiving those file archives we have on the, it's on my right.

OK. Well...

Michael Kimsal: Your left. Ok, sorry.

Manuel Lemos: Yes. Well, that's the way I see it. I'm never sure when this pictured is mirrored.

PHP Releases 5.4.28, PHP 5.5.12, PHP 5.6 beta 2 (1:09)

Manuel Lemos: Well, anyway, today we are going to talk about, as usual, the latest interesting topics about the things that are going on with the PHP world. As always, let me start from the latest PHP releases.

Let me share the screen here. We're already in May, because we're recording this a bit more delayed than usual.

We have PHP 5.4.28, which, well, there is nothing really much to say because it's mostly bug fixes.

Michael Kimsal: Oh, come on. Come on, it's probably got a lot of other stuff, too.

Manuel Lemos: Like? Such as?

Michael Kimsal: I don't know. I just think it probably does. There are probably new bugs that we haven't seen yet.

Manuel Lemos: Oh, yeah, now, you're right. They fixed some on there. There's a few more but they don't know yet. That's the...

Michael Kimsal: See right there, it says, "fpassthru broken".

Manuel Lemos: Yeah. Where?

Michael Kimsal: They were saying it was broken and this is a bug fix I thought they introduced.

Manuel Lemos: Intentionally.

Michael Kimsal: Yeah. it's 'fpassthru broken'.

Manuel Lemos: We have broken fpassthru, so you can have more fun with your comments.

Michael Kimsal: It could be pass through.

Manuel Lemos: So upgrade as soon as possible because with you, it's more fun.

Michael Kimsal: You might have been using fpassthru too much. So they...

Manuel Lemos: Yeah. Well, I don't know if I use much that function, because it's usually to... I think it's to run something. Is it the one to... No, that's probably the....

Michael Kimsal: Yes, it passes through stuff from a file handle to the response channel.

Manuel Lemos: Right. So, you probably have opened a file and it just flushes the contents to the page output. But I don't recall using this much. Probably, it's not a big deal because I do not always upgrade to the latest version because...

[Verbal Noise]

Manuel Lemos: Precisely I don't want to benefit from the latest bugs.

Michael Kimsal: OK.

Manuel Lemos: I don't know. Do you have the habit to upgrade to the latest version just to...

Michael Kimsal: I don't. I'm not sure what I'm on. Let me see what I'm on.

Manuel Lemos: Do you have a criteria, like 'Let's wait one month and start using this'?

Michael Kimsal: No. But actually, couple of machines I'm on right now were on 5.4.16. I'm not doing anything. I think I got one with 5.5 on it but I'm not doing anything that is 5.5 specific, even if it is. So, anything I'm writing is at most 5.4 compatible.

Also, at the same time, the majority of PHP stuff that I'm doing is not getting a lot of heavy use or traffic. And unless somebody would just scream out there's a massive security exploit, that's my criteria. I'm not necessarily going to go try to update everything unless there's a security issue or I need some new feature.

Manuel Lemos: Exactly. Yeah, there is no rush. This is mostly bug fixes, I think, that are not affecting your environment, your sites. Maybe it's not good idea to operate because you probably will stumble into new bugs that you did not have to be concerned before.

And talking about those, it seems that the PHP 5.5.12 is mostly the similar bugs or probably not much more than that. It's a bit hard to tell but well, what matters is that bugs are being fixed and if you stumble into these bugs, you know you need to upgrade it and there is a solution for those bugs.

Other than the latest releases, the latest PHP 5.6 Beta has also came up earlier in May. Let me increase the font here. I have not tried it.

[Verbal Noise]

Manuel Lemos: I'm particularly not excited with issue 5.6 because it's what it introduces is not, anything that is really exciting and there is not enough motivation to even try it.

I don't know, have you tried 5.6?

Michael Kimsal: Nope, still 5.4, 5.5. Now, come on.


Michael Kimsal: I'm going to here over the list: internal operator overloading, uploads over 2GB now accepted, POST data memory usage decreased, improved syntax for variadic functions. Yeah, the variadic function thing, is that in 5.5? I should know. I'm on a PHP podcast, I should know, but I don't know.

Manuel Lemos: Yeah. Don't worry, I don't know either. Because sometimes the recent developments are so uninteresting that probably we don't even want to bother to consider trying the latest release.

I think from 5.3 to 5.4, there were some significant speed improvements that maybe worth the upgrade. But after that, I'm not particularly excited in the news. Well, let's see.

Michael Kimsal: They've actually made big improvements if there'd been significant improvements in POST handling. Just that alone may appeal to some people.

Manuel Lemos: Yeah.

Michael Kimsal: But, yeah, the rest of this, it's going to require refactoring your code or writing new code to do it. I guess, in some sense, that's always the splitting point when you get upgrades. Is everything just faster and better? That's great.

Or are there now new data structures and new operators that I have where it might make my life easier, but until I modify my code, there's not a whole lot of point doing it. So, yeah, the eternal split.

Manuel Lemos: Yeah, because there are always those developers that like to be on the top of the latest wave and benefit from the latest features, that they write in backwards incompatible code that doesn't work with older versions.

But I think that's probably a minority, because a majority of developers do not even control the version of PHP they run on the sites of their customers. So, they're pretty much stuck with whatever they have and they do not even get interested on the latest features.

Other than that, I noticed from watching the interest about the articles posted on PHPClasses blog, the top most interesting news articles are about a couple of things. This is observed very consistently. One is performance and another is security. So, one is a benefit and the other is pain.

So people got interested because those seem to be the more urgent topics they are concerned. So if you talk about speed improvement, just like the latest article on PHPNG, they are very in security, it's the same.

Apart from that, new features, they do not get so much excited with at all. But if you tell them about old feature that gets broken or discontinued, deprecated or whatever in the future versions, they also get concerned.

For instance, when in the past, we talked about the deprecation of the original MySQL extension in PHP, there was a big, big concern. A big discussion of some people in favor, others against. That's one of very specific kind of topic that people get interested in, feature deprecation. And about new features, not so much.

Negative String offsets (10:03)

Manuel Lemos: Anyway, we always talk about new features here. And there are a few being proposed. Let me start, for instance, about one proposal supporting having negative offsets as indexes of strings for instance. I think, well, this is about strings, I'm not sure if they can also extend it to arrays.

Michael Kimsal: They can do that with arrays, I think.

Manuel Lemos: Is it? Really?

Michael Kimsal: Yeah.

Manuel Lemos: Well, I don't know.

Michael Kimsal: I think.

Manuel Lemos: It's probably one of those latest features that I never use.

Anyway, the idea here is if you specify a negative offset, I mean a negative index, it will take it as if you are taking a part of the string counting from the end, instead of the beginning when the index is positive.

I think this has its purposes. I don't know if it is a frequent need. There is a frequent need for this, at least in my projects. But I can see it can be useful in some projects. I don't know, what do you think, Michael?

Michael Kimsal: I was trying to run this and I can't get PHP to run at all at the moment. It just hangs. But I thought it's something you could do with... Ah, OK.

Manuel Lemos: I think it's substring, right?

Michael Kimsal: I may be thinking the substring. But I've also got some weird Zend extension manager already loaded twice. Yeah, undefined offset -1. OK, so now, you can't do with, at least in whatever version I am running here on my command line. This could be 5.3. 5.4.21, OK, so you can't do it. So you can't do it with that either, OK.

Do you need it? I don't know. And as somebody in that thread that you linked to, pointed out... Excuse me while I move all the stuff here. As somebody pointed out, this is one step away from using Python syntax. I don't know if they meant that as good or bad thing.


Michael Kimsal: But yeah, I'm just not sure. I don't know. I don't know if it really gets you a whole lot. I'm used to being able to do some of this in Groovy but at the same time, there's also some weird aspects of that sort of direct string or array access in Groovy. So, nothing's perfect.

Is it going to get you much? I don't know, somebody's already done a patch for it and it just kind of would work. I don't know if there's a huge negative to it.

Manuel Lemos: Right. It seems there is a part of the developers that are concerned in having features on PHP just because they exist on other languages. Just because they exist on other language doesn't mean that you really need them in PHP.

But, OK, if the feature is beneficial, great. If not, probably it's not a big deal. OK, I think it won't hurt to add these features. I probably will not use them soon enough because they will require a newer version that I probably will not be using anytime soon. But OK, I understand the language has to move on now. At least, that's some features they...

Michael Kimsal: Really, in what we would now, what I would refer to as the current standard PHP or Zend PHP, typeless PHP or loosely typed PHP, I think being able to give negative offsets, stuff like that, for arrays and for strings would cause hell with IDEs.

Manuel Lemos: Well, I don't know. What do you mean?

Michael Kimsal: Well, I know it would. And I don't... If this is something and it's a string, but can you do the square brackets on it? Well, I don't know. If the string is an array, what version of PHP might... It just strikes me as... We need types, just string types. Everybody moved it to PHP, which probably brings you to your next or brings us to another set, to another topic.

Manuel Lemos: Yeah, right, we already... I suppose you mean about the Facebook Hack and the features that Facebook Hack had added and commented in the last episode already. And many of those things are at worst, the direction that somehow the PHP core developers are reluctant to head. And well, until when? Until everybody has moved to Facebook Hack maybe.

Michael Kimsal: Yeah.

Manuel Lemos: I hope not. It would be bad to have a split in the PHP community. Well, Facebook doesn't care, they are doing their own stuff and if they cannot... if they stop relying on the good will or motivation of the PHP core developers, it's better for them. I think I'm not from Facebook to tell what is their criteria but that's what I probably would think if I were them.

Adding offsets to Reset() and End() (15:55)

Manuel Lemos: OK, but moving on now, another discussion here which is to somehow enhance the function reset() and end(). Those functions are used to traverse arrays, so they can take an additional argument to tell them if they should skip a few elements on the arrays.

So, for instance, reset the pointer traversing an array to the first element. If there was an additional argument to tell, you need to skip the first element and go directly to the second element, It would be probably useful for some applications and that's what this proposal is all about.

There is even a pull request on GitHub for PHP. Well, it may be useful but, again, not one of those very very useful feature that could bring gain to PHP to make it significantly better. I don't know, what do you think, Michael?

Michael Kimsal: Yeah, I don't know. I don't have any hard feeling on this. If somebody wants to do it, they can add it. It's never been a problem for me and I've been doing PHP for 18 years. It's not to say it's not a problem for somebody else but it would be pretty low on my total goal.

Manuel Lemos: Right.

Michael Kimsal: However, somebody's done a patch for it, it solves their problem. It does fill in a logical issue. I guess, part of it is I so rarely work with arrays rather than hashes or maps that I've never had the issue to say, "I need to reset it and then jump. I need to cycle through 80 things."

I probably had to do it on occasions and I'll just modify the for loop or something. It just does not feel like anything that's ever been an issue for me. But if somebody's got a patch for it and it doesn't create any other problems as it's always adding a new parameter generally should not be a problem.

But now, it's another definition of the language people need to support. And I think the patch was saying it doesn't support negative offsets. So, maybe it shouldn't.

Manuel Lemos: Yeah, I don't think it would make...

Michael Kimsal: Or they should start out to make it support negatives.

Manuel Lemos: What would be the effect of passing a negative offset to reset? Would it make the pointer go backwards in the array, go to the end of the array?

Michael Kimsal: Yeah, I don't why you couldn't just end ( ) and then the number there. Some if end (2) takes you two things in the end, I'm not sure that you necessarily need to support reset -2.

Manuel Lemos: Making it even more complicated when it is not useful for anything.

Michael Kimsal: Yeah. Yeah, it's just something else that will go on the PHP cert test three years from now.

Manuel Lemos: Yeah, those fake useful features.

Mail Handling (19:22)

Manuel Lemos: Well, now moving on to one feature that could actually make a big difference to PHP, I think, at least in my opinion. Let me share the screen.

And the proposal is to have somehow a better support for mail handling. I suppose this is for mail sending, because for mail receiving, it's probably more complex. But it says now 'mail handling'.

And the idea is to have something similar to what we have already with sessions, which it would be possible to register handlers to do some processing related with the email.

This is a bit abstract. I don't know if you follow the whole concept, but the idea here is that you would pass some objects with definition of a mail message and the handler would take care deliver to actually deliver it.

And the truth is that this is... I think it's a very important feature but over time, PHP developers have resorted to existing mail libraries written in PHP and somehow, they have their own mail problems solved.

I think this could be useful just as much as, for instance, PDO that somehow try to provide a uniform interface to database access, so you don't have to learn a different API for each database. With this, mail handler interface, you would be able to write a PHP application that could send email using the send() functions. But then, you could replace the handler and they have some other library to deal with it, with the specifics.

Because there are many ways to send email. You can send email using the mail function and send to relay SMTP server. And there are many types of configurations that you can change to make it probably more efficient in certain cases.

And I think this could be useful. Not absolutely necessary, but could be useful to bring some peace to the applications that really need to send email which are particularly all PHP applications, I think. What do you think, Michael? Have you thought into this?

Michael Kimsal: If I understood it correctly, they were thinking about trying to do it with the streams processing. It's funny because a couple of years ago, in one of the PHP classes that I teach, I mentioned mail handling as something you can do with custom streams.

I probably wouldn't do it myself but it is an example that you can use to say register custom handler, parse out this name or password, connect to it. So that's on the receiving end, checking an IMAP mailbox, for example. But in terms of sending, I've read through some of the threads here and it just feels like it's a more complex problem than what that could provide.

Your analogy of PDO to this, it might make sense but I don't think... Somebody there pointed out it's not just an issue of streaming bytes. There's a larger issue of configuration as well which doesn't seem to be dealt with in the proposal.

So, if some unified mail creation... The bigger issue really is mail creation, creating MIME things, creating emails with inline HTML and attachments and all that stuff. That's what everybody's classes do.

The actual sending of, sending that block of text to an SMTP server is by comparison pretty easy to do. There isn't any good way of dealing with errors like bounces and things like that. I don't think that's ever something you can do into the language itself but the... I kind of like the idea but I don't think necessarily doing it just with a subclass of stream system is really the way to do it.

Manuel Lemos: Yeah, sending mail is so complex and there are new standard being added to the possibilities of sending mail to define signatures and encryption. And all sorts of new RFCs being added over time, and to take advantage of all those standards and put it in a single interface is probably is not going to cut it.

But then, again, I think PDO does not cut on the possibilities of all databases. And there's probably are some databases like Oracle that PDO is not a good solution for.

Michael Kimsal: Well, if somebody will... I like it. I would probably suggest that we don't pursue this because somebody will create something and it will be the bait-in thing into PHP and it probably would suck in some respects or at least not do some basic stuff that you would expect.

And then rather than using an external classes for feature, people will say "We'll just use the internal one because it does this," and then you're going to be dealing with workarounds.

You mentioned PDO. As far as I can tell, there is no PDO close connection. It's just not there.

Manuel Lemos: Yeah, I don't know. I don't know if people are going to use it.

Michael Kimsal: Yeah, but it's not there. There is no PDO close connection, which...

Manuel Lemos: Yeah. I just, I would say, hope because I've developed it a long time ago. Although there had been much new developments, I continue to maintain it which is a bit of search and call Metabase.

It does not only have straight database access but also schema management. You can give it a schema definition and it is install that schema with whatever is the database. And PDO does not do that because it goes far beyond what were their goals. PDOs are more like what ADO is for the Windows world .NET or whatever.

Michael Kimsal: But I think even in ADO...

Manuel Lemos: And...

Michael Kimsal: I think even in ADO doesn't close the connection. Just set this to null and it will destroy it, but it doesn't actually work all the time. And I'm still maybe confused seven, eight years later, nine years later, as to why there's not an explicit close.

Manuel Lemos: Yeah. Probably because most Web applications use persistent connections and in the end, there is not a nice... that the actual would not even happen.

Michael Kimsal: Nope, if you don't... the docs, PHP will close the connection when your script ends. It closes the PDO connection.

Manuel Lemos: Right.

Michael Kimsal: It's just inconsistent architecture. This isn't a PDO rant so much, but it's just an example of that's now that go-to. If you're doing database stuff, everybody assumes that you should be doing that, even if their edge case says it doesn't support.

They'd rather have a workaround those edge cases and try to just use something else. And the mail thing would be the same, it would end up being the same situation. I'm just not sure that there's such a...

Manuel Lemos: Right. Actually, I think mail is even more complex. I think things like you already mentioned, for instance, how do you deal with the email bounces? Well, the bounce happens after you send the message.

Michael Kimsal: Somebody would want to, eventually, try to build that in, I think. The fact that they're talking about mail creation and mail sending in the same proposal should be a red flag.

Something that just creates mail messages for you that handle all the MIME stuff, that's fine. But the signing of them would be separate if you need that. And the sending of them would be separate, and they probably should be separate elements.

Manuel Lemos: And there's also the problem we deal with the memory limitations because if you try to send large files, you probably will be able... you'll have a hard time dealing with very, very large files because it would exceed PHP memory limits.

So the solution for that is to have an interface that supports streaming data rather than building the whole MIME envelope all at once and then streaming the MIME data through whatever is the means to communicate with the mail server.

And the mail function is not even appropriate for that because the mail function assumes that you can pass the whole message in a single stream. And if you exceed, if that string exceeds the PHP memory limits, you simply can't abort your script.

You can't send out large messages. But you could, for instance, if you pipe the message to Sendmail or qmail or postfix whatever...

Michael Kimsal: Sendmail.

Manuel Lemos: SMTP server, whatever is the means that allows you to stream data rather push a whole stream.

Well, this is already complex enough to deal with. One thing that I probably think would be a good solution to follow what was done for Java... and somebody would curse me for saying that... which is instead of providing an implementation, provide a specification for an interface and different developers would provide implementations.

So it will be sort of an abstraction but it there are limitations in certain implementation, other developers could implement better approaches but with the same interface so you don't have to change your actual application.

Michael Kimsal: I guess I disagree now in 2014.


Michael Kimsal: That would be the one off case. there's so few, little of that in the PHP community now to try to say, 'Well, we're going to do that for this mail thing.' It's just...

Manuel Lemos: Yeah, right. It doesn't happen. There is the FIG initiative.

Michael Kimsal: I don't think it should.

Manuel Lemos: But they seem to be still arguing about code formatting in the parentheses, autoloading.

Michael Kimsal: Yeah.

Manuel Lemos: And they also need it for actual practical things like sending email and...

Michael Kimsal: The community... and I say this with respect... but the community as a whole or a community that would end up implementing what you're suggesting, I don't think is... I want to say talented and that's going to come across wrong, but one maybe enough to do something with the rigor that would satisfy enough people and leave the door open for more stuff.

If anything, it would just end up pissing off and dividing more people. If there was already a history of doing this in the community, then yeah, it would just be another thing to do, "Hey, let's make a set of specifications for mail handling but we're 19 years into PHP and it's not the way we roll."

Manuel Lemos: I think PHP, the people around the FIG specification who have patience and the determination to be... spending of months arguing about the code formatting rules and this and that, maybe they have patience to go through that but we have...

Michael Kimsal: They might but that's at the framework level. That's framework inter-op group and at the framework level, in the PHP world, that's where this stuff belongs, not at the language level. And I didn't mean that nobody can do it. But I was maybe more specific when leaning to the history of the PHP language evolution and community and how that stuff happens. FIG probably somewhat different story though I'm not a fan of that, I think .

Manuel Lemos: Well, at least, if they develop PDO with the means to provide uniform interface for different database, they could as well do it for mail.

Michael Kimsal: Maybe.

Manuel Lemos: But well, that's the proposal that is being presented here in this topic. At least they are starting discussing it because this probably will not get to a conclusion anytime soon but people are already arguing if this is the right set of functions to have in an interface.

And at least they are discussing it. Whether they will come to a conclusion and move on to an actual implementation of any specification, that will be a different story but let's wait and see.

Michael Kimsal: If anything happens.

Manuel Lemos: In the worst case, they might implement this one and we will know more about it, because it will probably be a thing for the future, for future version and everybody needs to upgrade.

Michael Kimsal: PHP 6. If it's in PHP 6, that will be fun.

Manuel Lemos: Yeah, well, even the name of the next version, whether it will be PHP 6 or PHP 7, they have not yet reached an agreement.

Error Handling on (33:59)

Manuel Lemos: OK, now, moving on to the next topic, one thing that has been discussed, what will be possibly in the next PHP version. And one thing that I found here, there's a discussion about error handling using error events.

I don't know, but people sometimes come up with probably more complicated alternatives to dealing with things that are sort of well-dealt already. And I'm not even sure what this proposal tries to achieve.

It probably wants to deal with fatal error with exceptions. But I don't know if even fatal errors can be routed.

Michael, I don't know if we'll go into this. Although what...

Michael Kimsal: I didn't understand some of it. I understood some. Seems like they certainly want more consistency. I agree with that. There's a feeling of arbitrariness and possibly going back and either... Probably, for backwards compatibility standpoint, you need to have two layers of messages unless you made... There are two layers of errors, you have the old style errors and the new style errors.

And maybe the new style errors, maybe everything is an exception, maybe every single thing. I don't think that's what they're proposing, but to me that would make sense. Everything is an exception, there's some default handling for that and then you can register other custom handling and deal with your own inline handling.

But the idea of event severity or error severity mimics a lot of logging systems from Java and .NET and even in the PHP framework world. But baking that into the language, I don't think I'm opposed to that.

I'd like to have more consistency in error handling. The idea of 'Hey, we have exceptions', you can throw exceptions and 10% of the language throws exception or 5% of the language throws exceptions. But nothing else does, it's weird.

The idea of the fatal error that you can't catch, but now sometimes you can catch. Or you can catch but you can't do anything with, re-evaluating how well that works and how you deal with it, it would be great for that to be on the board.

Manuel Lemos: Yes, certainly the fatal error handling is somehow not present there. What you can do is register a shutdown function and at least to make sure that after fatal error, it gets called, but you do not get the whole context, you do not get what called the code that issued the fatal error.

I think that could be improved somehow. But other than that, probably complicating things more than they are. I understand the point of making it more consistent, but I don't know, people are always making up things that probably have more complexity than the benefit of what it's for, I think. That's my opinion.

Anyway, moving to the next topic here, we'll be...

Michael Kimsal: I'll mention this for a moment though, because I saw this person's the @ symbol, suppressed messages operator. I didn't quite get what they're saying at first, but they gave an example of saying, 'Hey, we could have suppressed message wrapper around code' and then say instead of doing @fopen, you know, handler = @fopen, you can just wrap it in a suppressed messages handler of some sort.

And as the person replies, he said, "This can actually be resolved much, much, much more elegantly to just have it for a real usable exceptions, instead of returning false and spitting out a warning." I like that.

Manuel Lemos: Yeah.

Michael Kimsal: I like that a lot. That's one of the canonical examples. Anyway, I didn't want to go through too much of that but yeah, I would like to have real exceptions everywhere in PHP and deal with them.

Manuel Lemos: Right. It could be interesting.

Return Type Declarations (38:52)

Manuel Lemos: Yeah, as I was saying, moving on to the next topic which basically getting back to the decision required regarding having type hinting for returning products of functions, class functions.

And well, I think if you have already type hinting for function, you might as well have type hinting for everything else. I don't know if it has any performance impact because the more type hinting you have, the more type checking you'll need to have in your PHP code.

So, I'm not sure if this would be a solution that everybody will use for the sake of performance. But for the sake detecting bugs earlier...

Michael Kimsal: I'm a Groovy guy... I used to be.

Manuel Lemos: Yeah. Although they do it in Groovy.

Michael Kimsal: That's optional. There's optional typing on those things, but it's known ahead of things. What's known is if you do explicit typing, it is because it compiles the Java, so there's compilation steps. So that's actually faster.

Explicitly saying, "This will return a string or this will return a list or an array", or "This variable is this particular type of class". Being explicit is faster because of the compilation step and it doesn't have to be checking at runtime.

But from a convenient standpoint, it's really heavy. It's just being able to say def x=0 and not worry about, "Do I want to make a float or double an end and just deal with the math later?" So the issues are maybe kind of reversed, because of the PHP world, because of the none or not compilation that we have, you're going to be doing more checks.

Now that said, in the Groovy world, it's going to be doing check at runtime if you're trying to add an integer to a float. It's going to have to say, "Oh, is this a float? What sort of thing is this?" because it doesn't know ahead of time. Because you haven't said, "I is a float." You just said "I is a def." But I'm a fan of it. I like the ability to do explicit typing when I want or need to and untype stuff by default.

Manuel Lemos: Right.

Michael Kimsal: So, I don't particularly care for this syntax. I don't really care for in hack. it reminds me of ActionScript and I got bad memories of ActionScript. I think, given the current syntax of PHP, I'm not sure that you could do much of the syntax. So then, after function declaration, you 'colon' and then type whatever thing you're going to return.

The options here are a string array or call-able. It would be nice to be able to say it's going to return a particular type of class. That would be really, really handy. Given that most of the other type hinting we have in PHP right now is only user-defined classes anyway, it would be nice to have some consistency there.

Manuel Lemos: Right. I think just like I said, if you have type hinting in function arguments, you might as well have a function return values, variable and whatever.

But the more effects you have at runtime, the more it could impact the performance and that's I think why the core developers are reluctant to do it. Because it's not all checks that you've done at runtime.

Anyway, it would be optional. And so, if you have type hinting, fine. If you don't have type hinting, it's fine too. It's up to you to decide, it's up to the developer.

PHPNG Dramatic Speedup Features Coming in PHP 6 Release (42:56)

Manuel Lemos: And this somehow ties to the next topic which is about the announcement of a new branch of PHP. They called PHPNG because they do not know exactly in what PHP version this will come up.

And I have written this article. Hopefully, I think it will be called still PHP 6 because it's the next logical number despite original plans for PHP 6 many years ago were canceled. But that's the path. Anyway, the discussion still goes on and that's probably not the most important matter.

What matters is that after Facebook announced the Hack language, the Zend people somehow woke up from sort of stagnation in the core engine development.

Because Facebook Hack and HHVM virtual machine that Facebook developed already supports what this PHPNG branch implements which is a JIT compilation engine. The code is compiling into native machine code as it get executed. And this will result in a much faster execution of the PHP code.

In this case, Zend developers actually, specifically Dmitry Stogov, opted to develop their own thing based on I think it's on LLVM assembly compiler engine.

Although in theory, they could cooperate with Facebook people... that develop their own things so they remain independent and I can understand that... but this is still one thing that the HHVM engine that the Facebook Hack language implement that PHP misses.

Well, basically, I present more about it in this article. I also mentioned things that the Facebook Hack language implements but are still missing in the current Zend engine based on the PHPNG branch like new type hinting constructs, just like what we commented before.

And one thing is probably my favorite feature... actually it's not probably, it's definitely my favorite feature on Facebook Hack language... is the way they handle asynchronous programming with the new constructs. You don't have to deal with callbacks. Other things that are more technical but I think these are the most important.

Michael, I don't know if you followed the announcements of the PHPNG branch. It's still very early but I think we already have an idea what it can be. What do you think?

Michael Kimsal: I followed them and I've always been a little curious about the timing because it's pretty obvious that the works that they said, "Hey, this is what we're looking at, this is what we work on so far." It wasn't just a knee-jerk reaction to the Hack stuff.

The HHVM has been going on for awhile, the HipHop stuff, but Hack as a language, "Hey, this is a whole new language. It's like PHP but it's got new stuff." I don't know in what sense that sort of forced the PHP community, maybe Zend's hand, to say "We're working on these things, too." Maybe they should have been more open about it. I don't know.

It's nice to see and I suspect that probably some of the other things from Hack that aren't there yet may make their way into an PHPNG and will just continue on with one canonical example of PHP.

It could end up splitting into, and I don't think it's... As long as there's 99% compatibility, there may be a feature that is in Hack which isn't in PHP 6 or whatever it is going to be called. Some people would say this is very, very fractured.

If there's maybe some gentleman's agreement to keep these thing essential on the same path but maybe with slightly different runtimes optimized for different purposes, you could end up with a Java situation where almost everybody use Suns or maybe Oracle now uses their JVM. But IBM' s got one and somebody else has.

There's three or four other JVMs and they run nearly all Java code. And of course, one might have a slight variation, it doesn't run certain sets of code or doesn't run them well. I don't think it would necessarily be bad. I think we'll probably be for years to come still see everybody on this Zend thing, the Zend structure, the JVM or PHP runtime. But I think it's too early to tell what's going to happen here.

Manuel Lemos: Well, sorry, I was on mute.

I think the differences between PHP and Facebook Hack are not small. Once you migrate your PHP code to Hack, it will no longer be compatible with PHP so that will be a problem for adoption.

Michael Kimsal: Right now, that would be the case. I'm suspecting that there may be an off cross-pollination back so that you could fairly easily go back and forth between the two and get different runtime behavior and different benefits in each situation.

Manuel Lemos: Yes, I hope so. Personally, I think it's positive that Facebook is doing this. Actually, they are not doing this... I think, in my opinion, I don't know what they think... they are not doing this for the sake of PHP.

They are doing this for the sake of their own developments. Facebook whole site needs to perform as fast as possible with the least requirements of hardware so that there's a whole set of improvements not just in the language but also in the environment. They can run it as multi-threaded environment, which PHP is not very adequate for that.

Other than that, personally, I hope there will only be one PHP language in the future, not PHP and Hack. But to have it as a single language, somehow the developments have to converge. And so far, what we have...

Michael Kimsal: Eventually.

Manuel Lemos: Somehow, Zend has been sleeping and not focusing enough on PHP and their Zend Engine. And now, after Facebook Hack has been announced, they sort of woke up and then wait we still want to be relevant and are back to the job. Well, at least that's my opinion.

Michael Kimsal: Could be. I think 2014, 2015 would be interesting years to watch this.

Manuel Lemos: Yeah. On the positive side, I think this only reflects that the greatest competitor of PHP is still PHP. Well, Facebook Hack if you want to call it, but I think Facebook Hack is still PHP with a different face, probably PHP, the futuristic face because of all the new features that they had added to it.

And they are really cool and a lot of people had been requesting for them in the PHP Core and they're all in discussions, an excuse to not implement them. And all that is very frustrating and somehow Facebook fulfilled the desires of many PHP developers that wanted the features that are implemented in the Facebook Hack and they are not available in PHP, at least for now. But I hope they will be. That's my hope that we'd still only have one on PHP in the future, the PHP 6 or 7 or whatever. It doesn't matter.

I think the future is bright for PHP. I don't think there is no reason for those that develop PHP could be threaten by Ruby on Rails or Python, whatever. The PHP development is quite alive and it's great that Facebook is helping push things forward. It's also great that Zend sort of woke up and is getting back to the game. And I think it's all positive.

Michael Kimsal: Cool, yup.

JavaScript Innovation Award Winners of February 2014 (52:38)

Manuel Lemos: OK, now, we're getting close to the end of this Hangout and now we're going to one of the last regular sections on which we comment on just a few of the Innovation Award winners, in this case, first we talk about JSClasses site because this is the brother site of PHPClasses. And I want to promote it as well because JSClasses site is a much smaller site and it's interesting to make it more developed, has much more contributions.

And now, we are going to comment a few of the nominees of the February edition of the Innovation Award that were voted on March. Then, in April, the results came out. Michael, which one of these five nominees would you like to comment?

Michael Kimsal: I think... Hello? One, two... Good morning.

Manuel Lemos: Yeah.

Michael Kimsal: I think I was looking at JS Dynamic Load, JavaScript Dynamic Load. I'm looking for... Who is the... Just Jino, no last name, in India. And it's a basic object that you can configure to load up multiple other JavaScript files after or at a certain times.

So it doesn't have to be in your standard script tags. It can load those up after the rest of your initial pages load up. So you can load dependencies. You mentioned before, sort of a RequireJS something.

Manuel Lemos: Yeah, I think it suits for that purpose and...

Michael Kimsal: Sorry, I meant to share my screen. As you know, it won't do that, just to show it.

Manuel Lemos: It's under...

Michael Kimsal: I can't find the button. Screenshare, there we go. They've changed it all since the last time I was... Yeah, I'll share that. Can I share?

Manuel Lemos: Yeah.

Michael Kimsal: Red X, says "This application's security privacy..." Oh, it's asking...

Manuel Lemos: No, I think you need to pick the specific window of your browser.

Michael Kimsal: Oh, I have to...

Manuel Lemos: Stop the screensharing picking again.

Michael Kimsal: No. I have to give it permission to something. I thought I did that. Do that, desktop, start screenshare. Are you seeing it?

Manuel Lemos: I'm seeing my face. I think you're trying to...

Michael Kimsal: Oh, yeah. I'm sorry. I'm sorry. Are you seeing it now?

Manuel Lemos: Now, I'm seeing. If you can increase the font, it would be OK.

Michael Kimsal: Jino, yes. Browse all Classes by Jino. Hello, Jino from India. And just very basic... I think I'm logged in here, yeah... not too much but you register a call back and it will give you little logs to the console to show you what it's doing and call your callback when it's done.

Manuel Lemos: Yeah, it's pretty straightforward. It's not exactly anything new in the JavaScript world but it is among the other packages on the site was innovative. As I mentioned, its purpose is to load libraries dynamically so you don't delay the initial page loading with a library that will not be needed.

So on my behalf, I would also like to comment on another package in JSClasses site. In this case, it is called JavaScript Video Cam Kit by Raul from Brazil. And this is very, very simple. I think it's useful now that most modern browsers support HTML 5 access to webcam video and microphone audio from a web page.

This is useful precisely because you can get to see what is appearing on a webcam. I'm not sure if this though... I don't think it uploads the actual video audio that it's capturing but it's probably something interesting to do in the following step.

So this is interesting because usually in HTML5, you get rid of dependencies on Flash to do things with a webcam audio and video.

PHP Innovation Award Winners of February 2014 (57:18)

Manuel Lemos: OK, there were other nominees in this month but we don't have time so we're going to move on to the Innovation Award nominees of February, in this case, of the PHPClasses site. Well, let's comment on a couple. There were seven, we don't have the time to comment on all of them. Michael, which one would you like to comment?

Michael Kimsal: Well, I had one up and let me try to share my thing again. Wait up, share desktop. There, Decorate. I chose this. I wasn't one of the people picking this, but was just interested in the idea here.

"Sometimes you need to alter the behavior of functions by doing something before or after the original function code. That is the decorator design pattern. This implements the decorator pattern by calling custom code..."

You didn't write this. This isn't yours, is it? No, jstar88. OK.

Manuel Lemos: No, it's not me. I just write the nomination text to explain why it was nominated. I just try to explain why it was considered innovative. I'm not endorsing it but just telling why because there are loops in this context, which is why...

Michael Kimsal: But I think there's only so much you're going to be able to do in PHP as it stands right now. But there's some interesting on after decorative link list and on before decorative link list extending the built-in SplDoublyLinkedList.

This has to be a callable function. You say Decorate, you say before this function do something else. I'm not sure if the function itself has to be a closure or if it can be the name of the function. I don't think...

Manuel Lemos: A callable.

Michael Kimsal: Probably has to be a callable function to intercept, so probably a closure. So may not be as useful to decorate existing code that you don't have source code to, but you could probably modify some of your code to be able to be decorated with this.

I'm not a fan and let's say, an interested person or a person of interest... That's not what I'm trying to say. I've been interested in the idea of AOP and that sort of aspect-oriented programming for awhile.

And it's just not something you can do in PHP very well. But there are some other meta-programming in general that's hard to do in PHP, but this is sort of interesting attempt at giving you some more runtime flexibility.

Manuel Lemos: Yeah, there are certain solutions. Actually, they've been in the PHP Classes site since many years ago to implement sort of AOP approach, aspect-oriented approach, but they basically take the original source code and alter it somehow to insert new behaviors.

So it's not exactly something that would run at the runtime. I mean, they won't alter it dynamically and make you rewrite the code. And, well, it works that complete its purpose but it's not something that probably like you see in any other languages. But it's still a valid approach to implement this thing.

Michael Kimsal: If only because it's only actually dealing with in that example, in the code that he's dealing with, the SPL stuff, theDoublyLinkedList and the standard PHP library, the SPL stuff, is something that is just not used very much. So very interesting to see somebody dealing with that.

Manuel Lemos: Yeah. Well, other than that, which other possible, would you like to comment?

Michael Kimsal: I'll pull up another one to talk about here. This is another one of the winners, the Table from Insert, generate a create table statement.

And I have to say, I'm assuming mySQL for this. It's making assumption. But if you pass this method in a SQL statement, it will give you a very, very bare bones, create table statement. Where would you get that? Here is the... See, you could actually see what it's doing. It's taking your values, splitting up.

I'm guessing that there's probably some... No, no, no, never mind, never mind. I was thinking that there was a problem with this. There is not actually a problem with it because it's just looking for the field names. And assuming you don't have any syntax errors in that part of your SQL statement, this will work just fine.

So given the values, given the field names, it's going to make columns var 255 out of everything. Possibly not as useful as I initially thought it was when I first saw it.

Manuel Lemos: Right.

Michael Kimsal: I like auto-increment ID primary keys and everything. It might be nice to throw in here, if there's a not a field called ID then add it. And that make it auto-increment ID.

Manuel Lemos: Yeah. I'm not sure either if this would be useful for any specific purpose for the reason that he mentioned, because it probably needs more fields to be guessed and the insert statements may not have that information.

Michael Kimsal: Maybe.

Manuel Lemos: He'll need to actually create the table metadata but... Well, I don't know what is the scenario error that the author who is speaking about using this package, probably do not have access to the date field itself.

Michael Kimsal: Elements...

Manuel Lemos: Maybe it's probably to recover... For instance, if you lost your database and you have somehow to recover it from SQL dump that only has insert statements. I'm guessing. I don't know what to think.

Michael Kimsal: Yeah, I'm guessing. I would think that may have been what the motivation was. It seems to me if you had a couple other flags on this class, like created ID, if one doesn't exist, create insert dates and last insert date, last update dates, things like that. Create some standard, other standard columns that you might want to have. Or pass an array of other columns that should always be there in addition to whatever was in the SQL statement, the insert statement.

It probably solved a purpose. It probably solved a data recovery purpose and that's why it was written in the first place. So there you go.

Manuel Lemos: Right. Well moving on, on my behalf, I would like to comment also on a couple of classes. Let me share the screen here. The first one is Tables for the Shell, which is from Williams Sant Ana from Brazil.

This is one of those interesting packages that are more useful when you have a sort of console-based applications, like scripts that you need to run from the shell. And there had been components to actually render a sort tables on the shell emulating the table borders with certain characters that simulate the lines of the borders.

But this class actually goes farther and lets you give it an HTML table and it parses the table and it regenerates the table in texts. So this is useful only if you have already an application that outputs HTML tables.

You do not want to rewrite the whole code to generate the same table to render it in text format for putting on the console. So I think it was a great idea. And let me see if screenshot here that shows how it looks. It looks pretty well. I think this is a very nice class and very useful for purposes that is being proposed.

Michael Kimsal: Sweet.

Manuel Lemos: So kudos to William Sant Ana for this great idea.

And the other class that I wanted to comment was actually the winner of the month, which is a package meant for addressing security concerns, eventual attacks that your sites are being subjected. And this one is from Rolands Kusins from Latvia. Oh, it's not Arturs Sosins, but has a somewhat similar name and he's from Latvia.

Michael Kimsal:I was going to say...

Manuel Lemos: Yeah. This package is called PHP Block Host and what it does is to parse some logs to be able to extract the addresses of the computers that probably are performing security attacks.

So it can help them to, I think, firewalls... I mean, in this case, it's updating the /etc/hosts.deny files and also .htaccess files if necessary. So, it parses the logs, like for instance, from Apache or sshd or even Linux system logs and finds traces of suspicious activities. And it creates blacklist than can be used those configuration files so those hosts can be blocked.

Well, it's probably would not be enough to deal with a distributed denial of service attack but it can be useful for simpler attacks. So this seems to be a very useful package. And kudos to Rolands Kusins for this package.

PHP Innovation Award Rankings of 2014 (1:08:18)

Now let me comment a bit one thing that starting this year 2014 will become more and more important, which is the ranking of the authors that were nominated for the innovation award. And other than the authors there is now a ranking by countries. so lets see where each author is.

Well currently as you may see here, Orazio Principe from Italy is leading the ranking by author and he is followed right after by Roger Baklund from Norway with 3 packages, so despite Roger has already published 3 packages and Orazio only 2, I mean published packages that were nominated for the innovation award, Orazion is leading because he earned more points.

So, other than that they are followed by Roland Kusins from Latvia with 1 package and 7 points, then there are several authors Brazil and Egypt with 6 points, they are in 4th position. Then there are several authors here with less points.

So moving on now with the ranking by country, currently Brazil with 3 packages and 17 points thanks to all these authors that have published several classes. Despite none of them is leading as individuals and they contributed for the Brazil to win.

And Brazil is followed by Italy with also 3 packages but only with 14 points. Then comes Norway with 3 packages and 9 points and that is mostly due to great contributions by Roger Baklund. And then followed by Latvia, Egypt, Portugal and several others.

Well this ranking standings already takes in account with the nominees of March that we only comment next month.

Michael Kimsal: Nice.

Conclusion (1:10:37)

Manuel Lemos: With this, we practically ended this podcast. It's already a bit long. But it's always great to have you back, Michael, in this podcast. I don't know if you'll be having time to record. If possible, it would be great to have you again.

Michael Kimsal: Well, at some point. It's just been a very...

Manuel Lemos: Life.

Michael Kimsal: Yeah, life and hecticness or busy-ness.

Manuel Lemos: Yeah, somebody has to do the work.

Michael Kimsal: Hello to everybody. Goodbye. Should I say goodbye now. Goodbye to everybody as well. Thank you for tuning in if you did.

Manuel Lemos: OK. Well, thank you for coming. On my behalf, that is all for now. Bye.

Michael Kimsal: OK.


You need to be a registered user or login to post a comment

1,615,527 PHP developers registered to the PHP Classes site.
Be One of Us!

Login Immediately with your account on:


No comments were submitted yet.

  Blog PHP Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog PHP is the Best Compe...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)