FFC

Changing the dictionary design of code formatting in ffc into a class based design

Registered by Martin Sandve Aln├Žs on 2013-03-01

The design where lambdas are inserted into the format dict is eerily close to the concept of a class. It's basically a collection of named functions, but instead of just implementing functions:

class Formatter:
  def foo(self, ...):
      return ...
formatter = Formatter()

functions are implemented, wrapped in lambdas, and inserted in a dict:

def _foo(...):
    return ...
format {
   "foo": lambda ...: _foo(...),
  }

When using this, instead of just accessing through an object with the function name:
  res = formatter.foo(...)

the code looks like:
  res = format["foo"](...)

or with prefetching:
  f_foo = format["foo"]
  res = f_foo(...)

Note that prefetching can be done with a class as well:
  f_foo = formatter.foo

The functionality of a dict is never used, and the functionality of classes is lost. There is zero gain to this design, and several disadvantages. A class can be overloaded in a much cleaner and standardized way. But my main issue with this design is that it makes it hard than necessary to "follow the trail" and search for where a function is defined, imported, used, etc., because it is imported as "format", fetched as "f_foo_bar = format["foo bar"]" and called as "f_foo_bar(...)", not necessarily with names this equal either.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.