[Types-sig] Why have two hierarchies? (*EUREKA!*)

[Evan Simpson]

One of these days I'll remember to make my posts as brief as possible *but
no briefer* :-)

>>2. Objects are based on other objects.  This forms an
inheritance/delegation
>>DAG exactly like current class DAGs.
>
>What is a DAG?

Directed Acyclic Graph, or what you get with a multiple inheritance
hierarchy.  Sorry, I didn't realize I was being obscure.

>>3. If you give an object a name, you've made a class.
>
>That *could* be a possibility. So far, it makes a lot of sense to me, but
>this detail is not very important: as long as there is _some_ way to
>distinguish a class form an instance.

It makes a lot of sense to me too, and I really like the idea that classes
have a name independently of how you got hold of  them, but instances are
anonymous except for their parentage.

>>This allows you to search the inheritance DAG by name.
>
>Sorry, I don't follow. What is a DAG?

I was being too concise again.  I just meant that you can search the
object's bases, and the bases' bases, etc for a class with a particular
name, without actually having a reference to that class.

[snippage] if you're calling an
>unbound method I strongly feel it's the responsibility of the caller to
>pass an object (*whatever* object) that the unbound method can handle.

I have mixed feelings here.  Eliminating the concept of unbound methods in
favor of raw functions makes the semantics more powerful and general, at the
cost of losing the automatic catching of "I forgot the self argument"
errors.

>>7. (Not sure on this one) An object can bind a method to itself before
>>handing it to its kids, thus allowing the elusive static class method to
be
>>realized.
>
>Not sure about this one myself. The easy way is to keep doing what we've
>always done:
>    MyClass.foo(MyClass, ...)

Since when have we been able to do this?  It doesn't work in the general
case, anyway, since a method may wish to operate on the state of classes
which are one or more subclasses removed from the one in which it was
defined, while allowing you to invoke it on any further subclass or
instance.  Invoke such a method on an instance, even, and it has no reliable
way of finding the parent class it's supposed to be tweaking.

>>12. "a = class (A):" or "a = object (A):" could be a synonym for #2, but
>>allow a code suite to execute in the context of 'a's namespace.
>
>I don't quite follow...

Oops.  Obscure *and* I forgot I re-numbered my points.
I meant that instead of:

a=A()
a.foo = 1
def bar(): pass
a.bar = bar

we could write:

object a(A): #or a = class (A):
  foo = 1
  def bar(): pass

Heck, you could even give instances docstrings in the usual way, if you
wanted.

[example of spelling an anonymous object]

>Hmmm, not bad... But it is the same as:
>
>class a:
>    a1 = 1
>    a1 = 1
>    def null(): pass
>    a2 = object:
>       b = "hi!"
>
>a.__name__ = None
>
>;-)

Hmf.  Only if you want to drive the newbies mad.  If anonymous objects
proved to be popular (as quick&easy containers, say), I'd say there would be
a *strong* case for an "object" keyword to keep the intent explicit.  Do we
*really* want to let people mutate __name__ without being slapped with a
chicken? <whimper>

>>Suppose objects could have a __birth_hook__ method, called every time a
new
>>descendent is created.
>
>Right, this is exactly what I meant with __instantiate__ above.

Wait, I read you as saying that __instantiate__ *or* __init__ would be
called, but not both.  If you meant that they get called in sequence, I
agree.

>>Unlike __init__, this would be called on named and
>>unnamed objects alike, and before __init__ for unnamed objects.
>
>Erm, confusion: are you creating an unnamed object from a named base or a
>named or unnamed object from an unnamed object???

I mean that *everything* descending from a class, whether it be an instance,
a subclass, or an instance of a subclass would get "birthed".  Only the
instances get __init__'ed, just as now.  Under your scheme, after all, the
only difference between subclassing and instantiation is whether the result
is a class (has a name).  The birth hook lets you handle new objects before
anyone else gets to see them.


I-suppose-you-could-call-it-a-midwife-ly^H^H^H^H^H

def Evan(Simpson):
  while self is not in PSA:
    avoid("yr's style signature")
    self.send(self, "Remember to sign up, already")