Get rid of Field API's pseudo-hooks [#1032850]

In D7, the field-type API functions (hook_field_[op]), along with the widget-, formatter- and storage-type APIs are documented as hooks, while they are in fact 'magic naming' callbacks.

We know that we want to get rid of that. Two approaches, same old philosiphical debate.

1) Move to real callbacks, declared in hook_field_info() (resp. hook_field_widget_info(), etc)
Cons: tedious explicit declaration, harder to browse code (arbitrary function names)

2) Move to interfaces and handler classes, with predictable func names.
Cons: less granular alter abilities. You can only alter in a different handler class as a whole.

If I'm not mistaken, 1) is what Panels does, 2) is what Views does.
I'd personally tend to favor 2). We currently don't support field-type callbacks override anyway.

Comments

Comment #1

catch

he/him

English

commented 19 January 2011 at 18:06

Subscribing.

Comment #2

fago

German

Vienna

commented 26 January 2011 at 17:40

Subscribing.

I think option 2) is the way to go as interfaces are a great place for documenting the callbacks + their parameters. Also PHP complains if devs implement an interface wrong, DX++. Next, we'd benefit from class autoloading and could make use of base-classes for providing default implementations of certain callbacks.

Then I don't think we'd have less alter capabilities compared to now, as now just the providing module would be invoked which no one can alter. Anyway, modules should better provide alternative implementations based upon another one instead of hacking around with the other one. For site customization, one can still customize the main implementation by overriding the providing class.

Comment #3

yched commented 26 January 2011 at 23:53

Next, we'd benefit from class autoloading

#977052: Implement hook_hook_info() for Field API hooks, but better.

and could make use of base-classes for providing default implementations of certain callbacks.

Exactly, that's been my intention for a while for field_default_X() - "default implementations of the pseudo-hook" (yuck).

Comment #4

Crell commented 16 February 2011 at 00:27

I am also very much in favor of moving to a proper class/interface structure, for all of the reasons listed above and various others. :-)

Comment #5

bojanz commented 8 March 2011 at 11:05

Also, I hate the fact that in D7 you can't just get a bunch of nodes, then check their types (node? user? commerce_product?).
This also came up during the DevDays in Brussels, where a few developers expected to be able to do $entity->type == 'node'.
I ran into the same thing when developing efq_views, so I added $entity->entity_type myself after entity_load().
If entities were classes, I could just use instanceof to see their type, and problem solved.

In general I'm all for moving entities to a proper class/interface structure.

Comment #6

yched commented 10 March 2011 at 07:30

@bojanz: that's more about entity types as classes, rather than an OO formulation of the Field API. Both are probably desirable, but are not really related.

Comment #7

bojanz commented 10 March 2011 at 09:58

Okay, I won't steer the issue in the wrong direction. Just wanted to mention something that was bugging me :)

Comment #8

mlncn commented 2 April 2011 at 13:11

Would interface and class handlers be self-documenting, or would we want something in .api.php to replace the (misleading) hook_ definitions? Wondering if any of this might spin off into #1114032: Call callbacks callbacks, and let hooks all be true hooks.

Comment #9

Crell commented 4 April 2011 at 23:04

One of the advantages of classes-and-interfaces is that they are more self-documenting than hooks or callbacks, and where they are not there are industry-wide standards (DocBlocks et al) for how to document them. That doesn't mean that supplementary documentation isn't often a good idea as well.