dickson.michael [michaeldickson]

F.module: Sort-of like Lambda functions. Except they're objects. And work as far back as PHP4. And have pseudo-currying. Not the prettiest code, but perfectly functional.

Used in tabular data module, for sorting [e.g. a drupal_sort() function]. BSD Licensed.

$f = f('$arg1,$arg2,$arg3',
  'return $arg1 . $arg2 . $arg3;'
);
$g = $f->curry('z');

$h = f_cuf($g);
echo call_user_func($h, 'A', 'b'); // prints "zAb"

Table.module: Helpful functions for working with tabular data. Note in particular table_sort(), which builds on f.module to make a very short and sweet sorting method. BSD Licensed.

Dictionary.module: To make working with VOs and Arrays easier. Note dictionary_overlay(), dictionary_underlay(), and dictionary_merge(). Easy names to remember how they work. Also note that dictionary_merge() is the way we intuitively expect module_invoke_all() to behave with non-numeric keys, as array_merge_recursive() can have side-effects. BSD Licensed.

That'll do for now... the other modules have a database component, and I still have to learn Drupal 7's database layer (the modules were all written for Drupal 5 initially).

/me still can't believe Drupal went to Objects for the database layer.

Can't review Table or Dictionary without first reviewing F, so the choice is obvious. I'll pick that. But it's rather pointless without the others. (They aren't merged into one module because that would be rather monolithic - not modular.)

F.module:
Goal: None, really. Except to make cleaner code where possible.
Existing Solutions: PHP native lambda functions. PHP 5.3+ only.
Utility For: Various other API abilities. No user-facing benefits.
Features: (almost) Lambda functions with (almost) Currying.
Problems: That (almost) part. It's nowhere near as elegant as ML or Haskell. And it uses eval(), which is a call I don't trust.
Benefits: Just look at table_sort(). No globals, no static variables, no OOP... it's simple, generates short functions, and is still readable.

---

BSD License is more-free than GPL2, so I'll dual-license these. Then the lawyers can be happy, and so can the rest of the world.

/me always thought Debian was particular about licenses...

As the author, I have the right to release code under whatever license I please. If Drupal agrees only to host code licensed under GPLv2, and if I wish to store my project on their server, then the code must be licensed under GPLv2. (Make no mistake that I misunderstood this).

However, there are no rules that state that you can take away my right to assign multiple licenses to my work. Therefore, while I am fully willing to license this under the GPL (as I agreed above), it is imperative that other users understand their right to select whichever license they would like to choose.

As the BSD license is more-free than the GPL, it is my attitude that most, if not all, users will choose the BSD license. (In addition, since the GPL is a superset of the BSD licensing terms, I had assumed that simply stating BSD license would be sufficient for Drupal's needs. Apparently I was mistaken about the level of commitment to freedom the Drupal community requires.)

I have stated my agreement to place these under the GPLv2 in addition to the BSD license. This is the third time I have stated such.

These module(s) have been submitted for review. I'm sure there is more to it than just the license.

And... I see that Drupal has added a whole new set of OOP rules to the Coding Standards, since last I checked it mid-2009. No need to point that out, I'll fix it.

There... I think this is compatible with OOP coding standards (which seem to not be finished yet). If it isn't, I'd appreciate being told which part of the standards it isn't compatible with.

CHANGELOG:
- Licensed under GPLv2.
- Added f_call(); a drop-in replacement for call_user_func().
- Removed f_obj(); was buggy, and never used.
- Adopted Drupal OOP coding standards.
- Dropped support for PHP4.

New example usage:

$f = f('$arg1, $arg2, $arg3',
  'return $arg1 . $arg2 . $arg3;'
);
$g = $f->curry('z');

echo f_call($g, 'A', 'b'); // prints "zAb"

With all due respect to Drupal, they do not have the right to make me give up copyright on my own code. No part of the GPLv2 state that Drupal has the right to change the license to anything other than future GPL versions. And if Drupal does requires that, it would be a violation of their own license (which states they may not add additional terms to the license)!

As for not supporting pass-by-reference, that's correct - and it's by design. I have trouble considering a scenario where someone would want pass-by-reference that isn't better handled, and better documented, by building a function the good old way. Can't fault that since even module_invoke_all() doesn't support pass-by-reference!

(Alternately: If someone /really/ needs pass-by-reference, it can always be added using the trick I describe in node/353494.)

Ah my confusion then. I read your line "the copyright notice should be probably removed" literally, to refer to the copyright itself, not the license the code is distributed under. Not to worry, I've lurked on enough message boards that I can grok the license issue.

But I do think keeping the notice is probably a good thing. i.e. I agree that if I choose to distribute code "linked" against Drupal 7, I use GPLv2. If Drupal changes it's license for a future version, and I wish to distribute code "linked" against this newer version, I must also change my license. But to remove the notice entirely is to suggest I've given up the right to review the new license and decide whether I wish to link against the new Drupal versions. Although not explicitly stated, it's implied, and in a court of law... implications do count. I know it's a technicality, but it's an important one, whichever side of the free-software fence one sits on.