Lambda the Ultimate

wonder now if OOP is not hard for some programmers to grasp simply because intuitivly they classify information according to type instead of function, and because they think in terms of data pools that are manipulated using functions or operators.

Maybe so. I think I have had that problem, even though I think I have gotten rid of to a certain extent. For whatever reason, I tend(ed) to think more naturally about functions acting on objects instead of objects that happen to have methods. Maybe it's because certain class-based OO languages have felt too static for me. But I think a language like Ruby has mitigated that feeling to a certain extent with open classes, mixins, and duck typing.

I've also been interested in Prototype based OO, and posted a forum topic on LtU. OOPLs seem to have a more flexible feel to them.

The screws you wanted to use for the painting are of a subtype of type Screw. Your father-in-law obviously used the wrong type, because you failed to provide the correct type for the screws.

On the other hand, you implicitely used strong typing, without declaring it: your set of screws was a different type of normal screws. Your screws were about 'hanging the painting on the wall', while the rest of your father-in-law's screws are for any issue that might arise.

The problem with OO languages is that they do not define the type system over values, but over definitions. For example, a class X is a type. That is wrong though, because the exact definition of X might be of type Y or Z, depending on function.

One issue, of course, is that your GF's father's toolbox is a very limited taxonomy. Assuming it looks like most toolboxes, it has a rectangular arrangement of bins; and no object can be in more than one bin at once.

Software systems are not necessarily so constrained (though some are); it's perfectly natural in the world of SW to be able to "sort" things by form, then by function, or by any other property you want. (One bin for fasteners which are an inch long; another for those which are an inch and a quarter, etc...) The physical limitations of the physical toolbox forced a choice of classification criteria; and he and you made different choices.

Regarding OO languages, there is a lot of confusion, naturally, between a "class" and a "type"--confusion that doesn't come up in most FP languages due to a lack of subtype polymorphism. If I define a Base class, and then a Derived class that inherits from Base--the set of objects which are of type Base is a superset of the set of objects which are of classBase. The set of objects of type base is equal to the set of objects of class Base, and every subclass. The set of objects of class Base are those which are constructed by uttering the syntax "new Base" (in Java), and no more. If Base is an abstract base class; the set of objects of class Base is empty.

One can emulate FP-style type definitions (named algebraic sums) using inheritance, but it's a lot more typing:

List : NIL | { car: Object, cdr: List }

can be directly translated into inheritance like this:

abstract class List {};
class EmptyList extends List {};
class ListElem extends List { car: Object; cdr: List };

Doing so goes against the grain of OO style; so in most OO languages a List type is implemented with a single class; with logic within the methods to handy the empty case. The other issue in OO is that most OO languages assume that a list (and a list element) will be mutated--but most OO languages disallow type migration (or else make it expensive), so the differences in behavior between an empty list and a non-empty list have to be handled outside the type system.

People who try to classify things at inappropriate times find themselves unable to dress since clothes belong in the closet. No, it's not of OBJECT_TYPE_TO_WEAR_BEFORE_GOING_OUT, it's a shirt, and it must be hung in the closet.

What aggravated me was the seperation of the "TGoodyBag" class into its constituent bits, when it wasn't neccessary at all, which ultimately forced me to search through the pools of objects for what I needed, when it would have sufficed to keep the instance intact .

It was sort of akin to having global lists of TScrew, TNail, etc, then taking the members of the TGoodyBag class instance and adding the member values to the appropriate list, freeing the TGoodyBag instance, then thereafter having to do a search through each list to find the member you need. Hardly efficient, in my eyes.

The screws you wanted to use for the painting are of a subtype of type Screw. Your father-in-law obviously used the wrong type, because you failed to provide the correct type for the screws.

The types of the members were irrelevant to the purpose of the TGoodybag class, but my gf's father obviously thought that it was. It was the deconstruction of the funtional whole that I found illogical, especially considering that everything inside the bag was specialised to the purpose at hand. That they inherited from a more generic class type was immaterial. That property of each item does not automatically mean that it is appropriate to place them along with other descendants of the ancestor type.

It would have been a good excercise after the needed objects were consumed and the excess placed in the type pool, but not before.

One issue, of course, is that your GF's father's toolbox is a very limited taxonomy. Assuming it looks like most toolboxes, it has a rectangular arrangement of bins; and no object can be in more than one bin at once.

Ah, but if Compartment inherits from Toolbox, then the object resides in both Toolbox and Compartment at the same time. It would have been good to leave the instance intact inside Toolbox instead of stripping the members into all the instances of Compartment.

People who try to classify things at inappropriate times find themselves unable to dress since clothes belong in the closet. No, it's not of OBJECT_TYPE_TO_WEAR_BEFORE_GOING_OUT, it's a shirt, and it must be hung in the closet.

I don't quite get the thrust of your example because it implies to me that containers can only accept objects, not release them for use. Objects don't exist to be contained, they exist to be used. Thus the purpose of your shirt is not to be hung in a closet, but to be worn.

Just like a computer cannot "use" all its objects at the same time, you cannot "use" all your shirts at the same time. To that end, I consider the closet to be a generic buffer, with the same sort of taxonomy as the toolbox, except that the sub-containers may be more specialised (you don't hang your Manolo Blahniks on hangers or keep your shirts in shoeboxes).

Lol. Talk about extending the analogy :-)

Next time my girlfiend complains that she needs more closet space, I am SO going to burst out laughing.

I hope she won't get offended when I mutter something about garbage collection...

hm, reference counting I think

Doesn't this make the error that only the screws provided with the picture are suitable for hanging it. We may assume all screws of the correct size are equivalent. Selection of screw does not depend on the picture however, but the type of wall it is to be hung on, so I don't see how sorting into the toolbox makes this any less efficent.

I think the difference in approach stems from experiance. If you only have one picture to hang, it makes sense to keep the fixings together. On the other hand a proffesional picture hanger will be used to finding all sorts of different circumstances, and looking in the right section of his toolbox. They will also keep the leftover fixings for future use on other types of wall.