Rasmus' Toys Page - Comments

Nifty Future Tips: HipHop PHP - Nifty Trick?

nospam@example.com (Nifty Future Tips) — Wed, 10 Mar 2010 12:27:58 -0800

I think it would be useful, even if it had to require type hinting and return type hinting. But even that could be overcome with the zval struct couldn't it?

justpassingby: The no-framework PHP MVC framework

nospam@example.com (justpassingby) — Thu, 25 Feb 2010 05:51:46 -0800

@Jose/@retryistherealretry I think Ruby's Sinatra and PHP's rough equivalent - Fat-Free Framework (http://fatfree.sourceforge.net) - are both in the right direction. Programmer has freedom in how MVC design pattern should be separated, or even no separation at all. No clutter in directory structures. It implements the front controller design pattern just as well, so you have all routers/controllers in a single file. But even that is under your control. All told, it could qualify as a no-framework framework. It's not the size, the speed, the OOP or procedural style employed, blah, blah, that matters. It's how elegant the code is, how the code is easily distributed across a team, and how usable it is.

Jose: The no-framework PHP MVC framework

nospam@example.com (Jose) — Tue, 23 Feb 2010 20:30:41 -0800

Like retry said "A php 'framework' that lets you pick and choose components to use within your design structure rather than force structure upon you would suit php best. And isn't that pretty much what 3rd party libs were before the framework fad came about?" I think that will make a lot of sense for PHP, I think like having a YUI library approach, but for PHP. That would be really cool!!

solostyle: The no-framework PHP MVC framework

nospam@example.com (solostyle) — Fri, 12 Feb 2010 16:05:55 -0800

Hello! I've been implementing my own mvc in php recently and stumbled upon this, which is in many ways similar to what I've been writing. I have a concern about the controller, which i am facing right now in my code. When I look at your code, it seems like the real controller is in common.js's usage of event listeners in fancyItems(). Initial page load is controlled by the thing you call the controller: add_c. I understand that in conventional mvc definition, your add_c is the controller. But really add_c does nothing more than what back-end model should be doing anyway. The view never directly interacts with the model in your example; it interacts only with your add_c controller. So I consider add_c, what you call the controller, really a layer upon the model. The view is defined by your html, but more significantly it is defined by the javascript. AND, in my opinion, it looks like the javascript also functions as your controller. (My purist view thinks "controller" refers to the thing that processes user input and decides what to do with it, "view" referring to the output and how to serve it.) Do you see it this way, too, or could you? In my application, I have taken to using asyc requests to update the view (and I use YUI 2.7), and my javascript ends up doing what you do--it passes some parameters and a resource (URL-type thing) to the back-end code, which figures out which back-end controller (similar to your add_c) and view (similar to your add.php) to give control to. I can see flaws with this.. it just doesn't seem as beautiful as I imagined my mvc would be. Of course, I am willing to incorporate some imperfections, but only if they are totally necessary. I guess my concern is really highlighting a flaw I see in the way mvc is being defined/interpreted/implemented... Maybe it would be useful to separate client-side view and controller functionality. So the callback function fN() would be seen more as a view updater, the clickFormEvent() more as the controller. Or if not separate them, at least begin to think of them in this way, so that when the application is expanded and more things are added, you might consider more of a separation. Any thoughts?

Sam Shull: HipHop PHP - Nifty Trick?

nospam@example.com (Sam Shull) — Fri, 12 Feb 2010 05:39:00 -0800

Yes, I have seen CodeGen_PECL, I guess I was just asking about something that didn't involve writing C, but could still be compiled.

Rasmus: HipHop PHP - Nifty Trick?

nospam@example.com (Rasmus) — Thu, 11 Feb 2010 20:49:19 -0800

We already have ext/skel in the source tree and the more powerful CodeGen_Pecl. See http://pear.php.net/package/CodeGen_PECL which lets you define much of an extension in an xml file. Just about all parts of an extension can be described, and while it doesn't mean you don't have to write some C or C++ code to do what your extension is supposed to do, it does free you from needing to know the details of the PHP APIs. Documentation is here: http://php-baustelle.de/CodeGen_PECL/manual.html

Sam Shull: HipHop PHP - Nifty Trick?

nospam@example.com (Sam Shull) — Thu, 11 Feb 2010 19:21:41 -0800

I think that HipHop is pretty cool, but not being much of a C/C++ programmer, I was hoping for a code transformer that output Zend API C code, that could then be compiled in the normal phpize way. Something along the lines of: function x ($a, $b) { return $a * $b; } might out put an extension skeleton that contained a function like PHP_FUNCTION(x) { /*I have no idea on how to implement this in the Zend API, but you get the idea*/ long *a, b; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ll", &a, &b) == FAILURE) { return; } return_value = a b; } or something to that extent. I think it would be useful, even if it had to require type hinting and return type hinting. But even that could be overcome with the zval struct couldn't it? Have you heard of anyone trying to do this type of code transformation? I feel like it would make these really complex frameworks so much simpler to implement IMHO. (Couldn't figure out how to prevent ** from being parsed as bold, sorry)

Ma'moon Al-Akash: A quick look at XHP

nospam@example.com (Ma'moon Al-Akash) — Wed, 10 Feb 2010 15:32:41 -0800

Hello Rasmus, Do you trust "Siege" more than "ab" or any other benchmarking tool for benchmarking your web apps? Thank You!

James Printer: A quick look at XHP

nospam@example.com (James Printer) — Wed, 10 Feb 2010 13:55:39 -0800

Thankyou.

Rasmus: A quick look at XHP

nospam@example.com (Rasmus) — Wed, 10 Feb 2010 13:09:49 -0800

The callgraphs come from Callgrind and exported from kcachegrind.