This may be better on a differetn SE site - there are quite a few but you need to check each to see what is on topic for each. For example, programmers.stackexchange.com has several answered questions about AOP... — Jerry Jeremiah13 secs ago
Over the weekend, I started poking around the Apache Commons Collections to figure out how to make an extension to it to implement some of their won't fix things that are won't fix for meh reasons. Their class hierarchy is...confusing.
@Ixrec you know what I like about this "question"? that with new rate limits asker won't be able to dump it to other sites for at least 40 (maybe 90) minutes. And that after it was closed and voted down appropriately, asker won't be able to dump more senseless garbage at Programmers for at least a day. Hope that will give them enough time to think how to ask better questions and at appropriate sites
Good. Now you can examine all of the available alternatives, evaluate those that are able to fan out, simple and able to be stubbed, and then choose the one that best meets your needs. — Robert Harvey35 mins ago
Thanks for your answer I can really start looking for a queue that satisfy my requirements. Really great comments, thanks. — Pepster33 mins ago
I disagree. Inheritance always creates a copy of the public interface of a class in its subclasses. This isn't a "has-a" relationship. This is subtyping, plain and simple, and therefore is inappropriate to the described application. — Jules13 mins ago
@Jules What do you disagree with? I said a lot of things that are demonstrable, and made conclusions that logically follow. You are incorrect when you say, "Inheritance always creates a copy of the public interface of a class in its subclasses." In Python, there is no copy - the methods are looked up dynamically according to the C3 algorithm method resolution order (MRO). — Aaron Hall4 mins ago
The point isn't about specific details of how the implementation works, it's about what the public interface of the class looks like. In the case of the example, User objects have in their interfaces not only the members defined in the User class, but also the ones defined in UserService and LoggingService. This isn't a "has-a" relationship, because the public interface is copied (albeit not via direct copying, but rather by an indirect lookup to the superclasses' interfaces). — Jules4 mins ago
So Jules thinks that using multiple inheritance for composition results in a non-has-a relationship because of the implementation? I don't think that's semantically correct.
to me this is just a good example of how taking OOP too seriously results in a lot of wasted time philosophizing about the deep meanings behind what are supposed to be practical real-world tools to be taken or left when and only when they are useful
@AaronHall IMO, the fundamental difference is that HAS-A is a statement at the value level: an array HAS elements, a person HAS-A first name and a last name. It is a statement about a relationship between values (objects, instances). IS-A is a statement at the type level: a Dog IS-A Mammal. It is a statement about a relationship between types (classes, interfaces, protocols, traits, mixins), i.e. classes (in the set-theoretic sense, not the OO sense) of values.
Bracha argues that mixins are just abstract subclasses and that mixin composition is a form of inheritance, and in fact a generalization of inheritance that subsumes all forms of classical single-inheritance (both Smalltalk-style overriding as well as Beta-style prefixing), linearized multiple-inheritance (CLOS, Dylan, Python), and Flavors/CLOS-style mixins. (I think the full Jigsaw thesis makes this clearer than the short overview paper you linked.)
In that sense, there is no real difference between classes and mixins, and so, if inheriting from a class creates an IS-A relationship, then so does mixin composition.
if you abstract too far, there's no difference between adding two numbers together and polyfilling a mixin across three layers of a C3'd inheritance hierarchy
But aren't these two different kinds of composition? Mixin composition is composition at the type level, i.e. composing classes out of smaller units. Object composition happens at the value level, i.e. composing larger objects out of smaller objects. They are both composition (in the English language sense of the word), but they belong to two different universes of discourse.
Confusing objects, classes, and types, instance-of and subclass-of, has-a and is-a, and similar issues are a pet peeve of mine. They are a constant source of confusion to newcomers to Ruby, not because they are hard to grasp, but because all the sources they use to learn confuse them as well.
"Class is an object and Object is a class" is commonly cited as a riddle you have to solve to gain Ruby mastery, but it's actually simple, IF you understand the difference between an object being an instance of a class and a class being a subclass of another class. If you keep that distinction clear, then even the fact that classes are objects and thus Object is an instance of Class which is a subclass of Object no longer can confuse you.
I'm already of the opinion that pure virtual/abstract interfaces are the way to go whenever any sort of inheritance is involved, and the natural definition of "interface" is much better at conveying its programming meaning than "class" is
Yeah, although that should be easy knowing what a functor is. I assume. I never actually learned category theory. I would love to understand how co-recursion over co-data can model an infinite event loop in a total language (i.e. a language where every functions always terminates). I know you can do it, I just have absolutely no clue what those words mean.
I mean, a total language is a language in which you cannot write an infinite loop. That's pretty much the definition. An operating system, a web server, a GUI is literally just an infinite loop. (If an operating system terminates, we call that a "crash" and get angry.) And yet, apparently you can write an OS with co-recursion (the category-theoretical dual of recursion) over co-data (the CT dual of data). Twists my brain.
and for any type T, its Monoid<T> instance specifies a "null" value for that type, and an "append" function that takes two values of that type and returns another value of the same type
that's it
in Haskell the "null" and the "append" are normally called mempty and mappend
I think that comes from a totally different branch of mathematics. Just like the term "functor" for an object that has an operator () in C++ has nothing to do with the concept of a functor from category theory.
the typical examples are 1) integers, where mempty is 0 and mappend is + 2) integers, where mempty is 0 and mappend is * (multiplication) 3) lists, where mempty is the empty list and mappend concatenates two lists 4) strings, basically the same as lists
functor is another typeclass, and it only requires the type to have a "map" method
for instance, the list type is a functor, because for any function that takes an integer and returns an integer, you can map that function over a list of integers
@AaronHall: Category Theory was invented, when mathematicians discovered that very different objects (they actually use that term in CT) from very different branches of mathematics had underlying shared properties. That they were actually instances of the same abstract idea. Now, if you imagine that mathematicians already have some pretty abstract ideas, and now they discover that those ideas are actually concrete instantiations of even more general, more abstract ideas, …
… then you can imagine just how abstract those ideas are. Category theory is so abstract, and sounds so ivory tower, because it is supposed to be. That's where its power comes from. Abstraction means Generality.
In maths, that means you need to prove stuff only once in category theory, and that automatically applies for lots of stuff across mathematics. In programming, that means that lots of things are, say, monads or functors or monoids, and you only need to write a library once that can deal with monads in general, and you can use that library for all sorts of stuff.
And you can apply intuitions from one branch of mathematics / one area of programming to totally different branches.
I must admit that it took me a second to get that reference. They weren't very popular here in Germany before the films came out, and those never managed to "catch" me. I actually have never seen a single one.
@AaronHall the first time I read about monad transformer stacks I got the mental image of a Maybe, an Either, an Except, an IO and a List combining to form the ultimate monad
which is more or less what transformers actually do
Well, you can create an instance of the Monad typeclass in Haskell that doesn't actually adhere to the Monad Laws of Category Theory. (Haskell's Type System isn't powerful enough, or at least wasn't when the Monad typeclass was added to the standard library, to express the Monad Laws in a way that they can be checked by the type checker.)
it's not really a necessary solution now that everyone's realized inheritance in general is a very strong coupling rarely suited to frequent or nested use
(at least the traditional meaning of "inheritance" where you inherited both implementation and interface)
For me, it's primitives: efficient dynamic optimization of OO languages has been known before Java was designed in the Lisp and Smalltalk communities. In fact, Sun owned the world's fastest OO VM and shut down the project in favor of Java. Then the developers left, formed their own company, and were promptly bought by Sun. HotSpot is, at its heart, still the Smalltalk VM it started out as. Just crazy.
The justification for the existence of primitives is the bad performance of boxed numbers, which had been solved long ago: just because they are conceptually objects in the language, doesn't mean they have to be compiled to objects in the machine code. Simple as that.
Has-a means Composition. Mixins are a form of Composition. The User class is not a UserService or LoggingService, but it has that functionality. I think Python's inheritance is more different from Java's than you realize. — Aaron Hall6 mins ago
It took us a good while, but the Community Team has circled up and here's where we stand on your request to change Programmers.SE's name.
We agree that renaming this site is a good idea.
"Programmers" is an affinity group, whereas "Software Architecture" (for example) is an action and a discipl...