Well, I use it internally - not on the public internet - so I didn't want to go through the mod_jk setup hassle ...

Thanks, it helped. For some reason PHP Development Tools package comes without Ant enabled.

Thanks for the tip. There seems to be some features that doesn't work though. The manual build button on the phpUnderControl index page does not get fixed by your output filter since it's using the jmx port (8000 by default I think).

Have you tried to get a similar setup with mod_jk?

http://forums.zend.com/viewtopic.php?f=59&t=573

You mentioned that this may be open sourced. Have you opened up the code yet? It doesn't matter if it's still a little messy, I'll be recreating the same functionality if I can't find an open solution. I'll be glad to contribute back (employer approval pending) also. Thanks.

Cheers
sakthi

Thats a great development tool you've created there, though I really wish the PHP development team would integrate a feature such as this into the Core.

I can see a future for OOP PHP getting closer and closer to the representation of JAVA. Not too far off though..

http://forums.zend.com/viewtopic.php?f=59&t=573

(this post is even referenced in the forum-post)

Yes, there is a performance hit. And yes, it happens on every method call with a type hint. But it also only happens in this case. if you don't specify a type hint in a methods declaration, nothing will happen. And if you specify a type hint - well, then of course there needs to be some code execution to check the type of the parameter.

Of course it would run faster if we would implement in the PHP core in C, but as this will not happen anytime soon, this is how it works right now.

I have to add that I designed this to be used in a testing framework. So the performance hit doesn't count in a situation like this. I probably wouldn't use PHPTypeSafe in a high traffic environment.

This is something I want to see in the core, along with docblock parsing that respects these metadata on the variable type. Good work.

I've looked at the code, can you comment on the type of performance hit you would expect?

From what I see, it appears that the error_handler is invoked on every type check for every method call.. that seems expensive no?

Otherwise, nice work!
-ralph

I would've dug this post, but you haven't finished submission @digg ;)

+1 for PHP Core submission !

This is amazing. It's the first time that I read something about PHPTypeSafe, it can help a lot to improve the maintainability of php apps api's (and the is_* inside method body).

Thanks for the update, although I still think that this functionality needs to go into the PHP core!

Thanks for the tip!

Thanks for sharing this!
I was trying to find some code snippet on the MT sites that covers exactly this, but failed miserably!

Have you found that it helps with the site's seo?

Michele

Thanks!! You gave me a hint to solve the problem. In my case I had to change a previous version of the kernel

I have the same comment as Hodicska: Any update on the 'how soon' question? :-)

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Betty

in response to Mr. Scheumann (sorry, encoding issues have corrupted your first name :)

Depending on how the IDE implements phar access, this could be done easily using the C API of phar. However, there is no "libphar" which would make it possible to do without a Zend Engine present (and no plans for that), it is worth pointing out that the ability to add/remove or rename files in a phar archive is synonymous with the ability to do this within tar and zip archives for tar- and zip-based phar archives. There is no equivalent for phar-based archives, but this is worth mentioning, as existing libs like zzlib can be used to directly add support to the IDE without requiring bundled php/phar support.

However, if phar access is implemented directly the the phar extension, decompress/rebuild is unnecessary, as this is all handled internally by phar.

Another easy solution is simply to create a script that creates a tar archive of a directory, includes the .phar/stub.php for the phar stub, and a php script like so:
[?php]
$a = new Phar('/path/to/tempphar.phar.tar');
$b = $a->convert(Phar::PHAR); // voila - now we have a new phar
[/php]

Thx a lot. That helped me so much to figure out the problem.
Solved in 2 minutes *gg*.

Thanks for figuring this out! I previously looked into my app to see why the localization wasn't working and was kind of confused to see that – umm... – appended number in my German localization folder.

Can I use the 2.2 firware? This is because I have fw 2.2 on my iPhone.

Thanks again!

Thanks for the tip! Really helped me out.

Thx for sharing your slides. Great idea, I really like it. I was already thinking on some similar thing after reading a little about RSpec. The big question: how soon will be that soon? ;)

you might take a point - but I don't agree with your opinion.

$99 might be too much if you're planing to publish a free software.

But you state that you don't like Apple taking 30% of the program income. Which means you're planing to sell software on the App Store.

This means you're earning the same money developers are earning in the US, Europe and everywhere else in the world. So I don't see the point with the $99.

And let me tell you, 30% costs is really not much money given Apple is handling all the payment options worldwide plus not charging for hosting the application plus giving you advertising space in the App Store.

I was about to enroll but when I got to the agreement page, it states the enrollment fee is in fact an annual one. I know if you live in the US or Europe $99 is not a lot of money, but in Africa it is. Do you understand this the same way? Does it seem right to pay 30% of your program income and another $99 annually regardless of your income?

I work in a small web-company and this could be very handy for us. Using other peoples methods you can easily be confused what types are required, and have to look in the code or the PHPDOC's. A lot of effort on our parts also goes into enssuring that our methods are passed the right kind of data. I shall look into this.

Thank you so much for bringing this to my attention!

Rune

Sure I can tell you. Just have a look at the contact page of the Developers Portal of Apple.

http://developer.apple.com/contact/phone.html

I just called Apple in the US: +1 (408) 974 4897

I've been waiting about a week for my enrollment to go through and Apple have definitely taken the money out of my account but I haven't been emailed any activation links or anything.

Do you remember which Apple department you called? I can't see any contact info on the developer.apple.com site...

If you can reply with the email address I've filled in, then awesome. Otherwise I'll check back here for a response...

Thanks

Alex

I don't know, if I understood SPL_Types wrong, but you'd have to compile in a custom PHP (Pecl) extension and be forced to declare/change (i.e.) strings like objects ... that's not as easy like just using string and checking the type.

Well, as I already wrote:

1.) Parsing E_RECOVERABLE_ERROR got to be rather slow ... but it only happens when there are errors anyway.
2.) More important: using type hints in a dynamic language is NOT the same like in a static language - but it's shorter to use type hints compared to using is_*() functions (and its error handling) all the time.

Have you given a look at SPL_Types for that matter? That could be a way to save you some annoyances. Why re-inventing the wheel after all when all you'd have to do is to enable the extension :)

The thing is, I can't see any reason for this. One of the main advantage of typ hinting in compiled languages is that the compiler can catch errors for you, *before* they happen in the runtime, in php you can't.

As another commenter pointed it, parsing E_RECOVERABLE_ERROR got to be rather slow - but then again it probably won't matter since the application will throw a fatal exception if an error is found anyway.

Also, because you have type hinting/forcing without the added benefit of static languages of compiletime-checking the calling context has to be aware of to handled errors that could be thrown because of the argument list (in a dynamic language), errors that should be handled within the called function/method.

In the end you are not forced to use type hints for parameters. They are just a nice add-on.

I suppose if you're in a position where you have to deploy completely untrusted software and allow it to connect to a database with sensitive information, then maybe something like this makes sense. I'd argue that no one should be in that position, though.

Excellent, but I won't use it until it makes the core. But I'm soooo hoping it will be part of PHP one day.

Interesting approach. However, I doubt that catching and parsing E_RECOVERABLE_ERROR ist very fast. [..]

The idea behind it is to avoid having to cast, if a error is thrown, it meant you did something wrong. So of course in that scenario it's slower.
But you shouldn't be getting the errors.

No, just no. I'm sorry but this is just horrible. Can someone please tell me the point of type hinting i a dynamic language? I beg of you.

It's not something needed for every method out there, it's just to force in cases you would really want it.