Flourish PHP Unframework
This is an archived copy of the forum for reference purposes

Flourish makes PHP sane; can't PHP learn from Flourish?

posted by audvare 8 years ago

I find that Flourish brings so much sanity to PHP programming yet at the same time when writing a new function, class, etc, some PHP not-so-nice things make their re-appearance. These are things talked about by critics in part when it comes to PHP:

I'm only pointing out a few common things I hear about. I'm not necessarily complaining but I am saying that it's great that Flourish brings PHP to a new level because Flourish is actually designed. That's all PHP needs in general, rather than emulating Java in one version (PHP 5.2), Javascript in another (PHP 5.3), and Ruby in the who-knows-when version (5.4?).

For the first issue, I've considered using fUTF8 for all string operations but there come to mind a few issues:

The rest of the solution I suppose is aliasing and creating better, more useful classes (this is what Flourish does for many things). fNumber essentially makes numbers objects in PHP (pretty much a first, but I'm sure many might wonder why this is a good idea, especially when there is also no literal syntax possibility yet). fDate/fTimestamp/fTime is all the date functions' replacements.

For the third issue, a general purpose Array (really, hash table) class could be made that implemented toString(), Iterable, etc and returned the values imploded (with their toString() methods called as well).

For the fourth issue, it seems like every class (regardless of need) should have a default call() method that's something like:

public function __call($method, $arguments) {
  if (substr($method, 0, 3) === 'get') { // fUTF8::sub would be better right? :)
    $value = substr($method, 3);
    if (isset($this->$value)) {
      return $this->$value;
    }
    return NULL;
  }
  if (substr($method, 0, 3) === 'set') {
    $prop = substr($method, 3)
    $this->$prop = $arguments[0];
  }
  return $this;
}

Other thoughts:

Other than using real tabs, I like the standards put in place. Naming convention is great. Almost like how in Objective-C almost everyone uses a 2-3 letter uppercase prefix instead of a full word. Consider this the 'vendor prefix' (like in CSS -webkit- or OpenGL GL_NV_). It's very useful and much simpler than a full word (and better than none). PHP lacks a good packaging system (STILL, who ever heard of a class 'autoloader' in another language?) and so this is the closest we can get without using the (IMO terrible) namespacing syntax (my criticism is choosing possibly the worst possible character for it,
).

The other issue that is still going on is compatibility. The cheap hosts are really holding us back! I want to actually use closures (honestly, already have)! But I know I can't because the average host remains on PHP 5.2. It's a horrible situation and I really don't know the solution besides somehow convincing the cheap hosts (I'm looking at GoDaddy for one) to actually stay up to date. The only way this could happen is if everyone began using PHP 5.3 functionality a lot more and nothing supported 5.2. Probably not going to happen soon.