I agree with you, although your choice of terminology is confused. You're not arguing for has-a. Has-a means "contains as a part", not necessarily part of the interface. Yes, a car (the kind you drive) has-a steering wheel, but it also has-a engine.
You seem to mean a specific kind of is-a called polymorphism. Looking at OOP, it looks like the only truly useful capability of OOP that Arc doesn't have is polymorphism, which fits well with duck typing. It basically means, "I don't care what this is or how it works, as long as it can foobaz."
Actually, I am arguing for a "contains as a part" semantics. arc.arc does have polymorphism - there are functions that work on sequences like lists, strings, and tables. The problem, however, is that some of them don't work on user-defined types without munging with 'isa.
What I'm proposing is abstracting some very "basic operations" such as 'car and 'cdr, put them in some "types" (really closer to type classes/abstract base class), and then have the built-in types "contain as a part" the "basic operation type". Then the arc.arc polymorphic functions will work based on the "basic operation type" instead of the actual is-a type, and user-defined types don't have to munge 'isa.
But if you think about it as an abstract base class/mixin/interface, then the standard terminology is "is-a". For instance, in Ruby:
module MyMixin # Like an interface
...
end
class MyClass
includes MyMixin # Like "implements MyMixin"
...
end
foo = MyClass.new
if foo.is_a? MyMixin
puts "is-a"
else
puts "has-a"
end
# Output: "is-a"
I'd rather see the "basic types" not as a collection of basic components, but as a collection of basic interfaces one can implement, or basic type classes one can be a member of, or what-have-you; what I'd really rather do is duck most of it, like Ruby does. If I can define car and cdr for my type, map should work seamlessly.
Regardless, it sounds like a lot of the voices here are in agreement over some common set of the features this plan proposes, which is a good thing. Perhaps we should set the naming quibbles aside for now and try to flesh that out. Or perhaps we should settle on a name for what we are about to flesh out. Either way, it looks like something good could well emerge from this thread.
