This has appeared at just the right time, now I'm re-working my project's image manipulation classes. The PHP GD library functions are a nightmare for readability.
I'll be having a little play about with what I intend to implement and if it works out well I'll likely implement it in my project proper!
> “Why didn’t he keep width and height as simple integer parameters in every method that needed those?” or “Why is x and y coordinates are an object called Point?”
Seems to me that PHP needs to turn its own primitives into objects so they can be type hinted. Trying to figure out which of a dozen number validation functions to use is an utter clusterfuck at the best of times.
It's really good to see some well engineered PHP software coming out.
For my projects I've moved out to Python after having dealt with legacy trash like Wordpress, Google's api libraries, over-engineered frameworks like ZF and lets just say the less said about Propel the better.
Code like this, Symfony 2, Doctrine 2, Lithium etc... are a breath of fresh air. Their obviously written by a group of talented devs and after cutting ties with legacy PHP versions < 5.3 the future of "modern" PHP is looking bright!
It's PHP 5.3's namespacing functionality, in a nutshell.
Symfony2 and Lithium are two frameworks I can currently think of that use them extensively. On the one hand, Symfony2 has a quite extreme implementation, and on the other, Lithium's is much more concise. The backslashes can be used to represent a hierarchy.
Namespaces, as others have mentioned. The first question I had when I first encountered that as the Namespace operator was: "Why not the double colon operator?"
Double colon is already being used for static member referencing, and in a few talks I've heard from Rasmus, they weren't able to find a way to overload it for Namespaces.
Another option that was discussed was a triple colon operator, which most were opposed to b/c of it's length. I personally think the backslash is ugly, and I kind of like the triple colon operator better b/c of it's similarity to the double colon operator. Regardless of which one is prettier, I wish the double colon operator could have been overloaded.
IIRC, the reasoning against double colons was that if you had a class and a namespace with the same name, it's impossible to tell whether SomeThing::Do() is calling a function in the SomeThing namespace, or the static Do function on the SomeThing class. One could argue that they could simple not allow namespaces and classes to share names, but I guess they didn't like that idea, either.
I hope I'm stating this right, I must admit it's from a fuzzy recollection.
If you're talking about the German layout and AltGr, then so are the []{} keys, which are already used quite a lot in PHP programming.
It's the main reason why, even though my phyiscal keys are in German layout, I still have the USA layout in software. It's just nice to be able to make [] with a single key press :)
sorry, it looked so awesome and I noticed the kind requirement to use it for flask-only projects after rolled the new sphinx design out. I promise to use a different theme and is something I'm working on now.
Just curious, is there a reason you chose GD over imlib2?
I've used both and I think I prefer imlib2 for flexibility and breadth, and there's already at least one imlib2 binding for PHP: http://pp.siedziba.pl/
Thanks, I'd seen so many language bindings for imlib2 (and, yes, gd) that I'd assumed it was an active project, but you're right that it's not. Also gd does a lot more than it used to.
I'll be having a little play about with what I intend to implement and if it works out well I'll likely implement it in my project proper!
> “Why didn’t he keep width and height as simple integer parameters in every method that needed those?” or “Why is x and y coordinates are an object called Point?”
Seems to me that PHP needs to turn its own primitives into objects so they can be type hinted. Trying to figure out which of a dozen number validation functions to use is an utter clusterfuck at the best of times.