[fizx]

> It's an over complicated term for a really trivial pattern in development.

Yes, but...

The objective of most business-oriented programs is to create the One True Function(tm), usually known to developers as a the "application." For everyone's sanity, this should be composed of smaller functions, which are sometimes called "objects." An object is just a function that was created using a specific creation template, usually called a "constructor."

For a pretty moderately sized application, the One True Function might be a tree of sub-functions which has hundreds or thousands of branches. Sometimes you might want to write the straightforward boilerplate code to attach items to this tree, but that could get tedious to maintain.

Other times, you might find a library that will automatically assemble your tree for you, as long as you specify up front in configuration that all of your fruits are apples and all of your leaves are green. This program is usually called a "DI framework."

Hopefully, this saves you a lot of typing, which you can then use to type up HN comments.

[crimsonalucard]

Objects and functions are different. An object retains state, a function should be stateless. Objects cannot be evaluated and do not have return values.

[LBarret]

I think conflating data structures and objects is bad, and muddle the discussion. An app is mostly a pipeline of functions over an initial data structure.

[fizx]

I think you forgot the word mutable somewhere. A true Business Application(tm) has no mutable state that is not stored in the database, so all objects are immutable and therefore functions (except those dirty dirty data objects).

    some_object.apply(method_name, param, ...) // sure looks like evaluation to me

[crimsonalucard]

You never mentioned immutable. If objects were immutable then yes you are correct.

I'm not sure what you mean by "true business application" but there is a transient form of mutable state that an object possesses in between processing a request and returning a response that is seperate from the state that the database holds. It is up to you whether you want that transient state to be mutable or not.

An object itself cannot be evaluated. Methods can be evaluated but not the object itself. Is your example referring to a specific language?... because in general objects are not functions.

[Sohcahtoa82]

> Objects cannot be evaluated and do not have return values.

Python would disagree.

[crimsonalucard]

Python disagrees with you. Given a python script with a single class. If you instantiate an object and try to "call" or "evaluate" it:

    class A(object):
         def __init__(self):
             pass

    x = A()
    x()

you get this output to stderr:

  Traceback (most recent call last):
    File "python_temp.py", line 6, in <module>
      x()
  TypeError: 'A' object is not callable

Of course you can mess with the callable magic method, but that's more of a trick then a standard. You may be referring to how functions in python are implemented as callable objects rather than primitives. This is an implementation detail that is language specific, similar to how in javascript, functions are also classes.

In standard programming vernacular and practice, objects and functions are two different primitives. They are not the same thing. An object is a noun, a function is a verb, and just like their english grammar counter parts functions and objects are primitives because a Noun is not really a special kind of verb nor is a verb a special case of a noun.

Edit: added more detail, grammar editing.

[Sohcahtoa82]

> Of course you can mess with the callable magic method, but that's more of a trick then a standard.

Implementing a __call__ function is indeed what I was referring to.