Quote - A function referring to itself is mind-boggling

Stop right there! The class CSB is not a function! It is a class.

Read these two summaries carefully. Many of the sentences are similar, indicating that classes and functions have a lot in common, perhaps causing your confusion. Study the differences carefully.

function: An encapsulation of instructions to follow to perform some action automatically. It does so by combining multiple program statements into a single unit. The most common way (but not the only way) functions are created is via the "def" keyword  The def keyword requires a name by which the function will be known for future use. To use the function, i.e. to perform the action it describes, you type its name followed by a pair of parentheses. (There are other ways, too.) Functions can have inputs (arguments) that are used when following the instructions described in the function. When calling a function, it may have results (return values, there can be 0, 1, 2, any number of returned values) that are returned to the caller after it finishes executing. We can do quite a lot without functions, but we'd find ourselves saying the same things over and over with slightly different inputs.

class: An encapsulation of instructions to follow to build objects with certain capabilities automatically. It does so by combining multiple attribute and function declarations into a single unit. The most common way (but not the only way) classes are created is via the "class" keyword. The class keyword requires a name by which the class will be known for future use. To use the class, i.e. to build an instance of the kind of object it describes, you type its name followed by a pair of parentheses. (There are other ways, too) Classes can have inputs (arguments) that are used when following the instructions described in the class. When calling a class, it always has one result (return value - the newly created object) that is returned to the caller after it finishes executing. We can do quite a lot without classes, but we'd find ourselves saying the same things over and over with slightly different inputs.

In my script, the class CSB encapsulates instructions on how to build a certain type of object that I need. When you "call" the class, as in

paint = CSB(AGC(Color(.2, .5, 1)), 1, 0)

you are not invoking the mix method. You are invoking the class. The class internally builds a new object, then calls its init method WITH THOSE ARGUMENTS to initialize the new object.

So in that example, function init gets called with the arguments

item = the new CSB instance that is under construction because you called the class
color = AGC(Color(.2, .5, 1)
shine = 1
bump = 0

I wonder if you think that the mix function is part of the init function. It is not. The last line of instructions in the init function is the assignment to item.bump = bump. The init function then exits, returning to the caller which is inside the guts of Python.

The mix method is called later on the instances we created.

For example:

skin.mix(paint, paintMask)

In my script, skin and paint were created by the CSB class, and those objects "know" all the same things about what to do with themselves. They are identical in every way, except that they have different attributes, because I called the CSB class with different arguments when I made them.

So when we write

skin.mix

we are actually asking the skin object to look up its definition of mix. When the class built the skin object, it stored a little info in the object on how to find the class again, in case the object needs help with doing things. In this case, the skin object doesn't actually know how to mix (we never assigned a mix attribute to it) so it will go back to the class and ask for help. The class will give it its own copy of the mix function, with the skin bound automatically to the first argument of the function. This is called a "bound function". Until we invoked the mix on the skin, mix only existed in the class itself, as an "unbound function".

The mix function takes three inputs or arguments: a, b, mask. We just established that skin.mix created a bound function where a=skin automatically. Now all that remains is to fill in b and mask. Which is clearly what I did:

skin.mix(paint, paintMask)

so:

CSB's version of "mix" gets called, bound to skin, i.e. a = skin, and the other two inputs come from my argument list, so
a = skin
b = paint
mask = paintMask

Once these connections are made, the statements encapsulated inside the mix function are executed.

There is only one statement in there.

return CSB( ... )

This is not magical in any way. It is not recursion. We are calling the class CSB from inside a bound method of the object skin, while executing the method mix.

As always, calling the class creates a new object. The inputs (arguments) passed are used to qualify how to build this new object. In that sense, mix is quite straightforward. When you mix two CSB objects, you're trying to make a new CSB object who's attributes are a mixture of the two things being mixed. That's what it does - builds a new CSB object, and passes blended values for each of the new object's attributes.

Another analogy to classes is that of a factory. When you call the class, it's like you visit the factory and placed an order for a new item. During the visit, you customize the item they build for you by giving them input on the what attributes you'd like your new object to have. When you visit, someone takes your order. This is Python guts. The order taker doesn't actually know how to build your item - she just sends the order to a worker who actually knows what steps to follow. That worker is the init function. The worker builds you a new item and sends it down the chute, where it lands in front of you and you leave.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)