class/instance context [was: "my brain hurts" or is isinstance broken?]

[Robert Kuzelj]

hi,

<sigh> it seems i made my self not very
clear. i'll try it once again.
first i'll do some rehasing so that you are
not bothered with it. ;-)

- classes are objects
- i know that!
- so are metaclasses
- i know that!

- instances cant be destingiushed from classes 
- at least not explictily
- i know that!
- i dont like that!
- there is a workaround for that
- i can live with that workaround!
- i dont like it!

ok?

concerning the simplistic factory-example:
- it can besolved by a different design
- know that!
- there are at least len(thread_messages) + 1 solutions
  to this particular problem.
- we dont need to go thru all of them ;-)


the whole point of this discussion (at the moment) is that 
the question if something is a class or an instance 
is depending on the context.

so one more rehashing

for the context of defining the overall pythonsystem
- every class is an object
- i know that
- i like that
- it makes modifiying this system very easy
- i am playing around with that at the moment
- i realy realy love it.

for every other system this premise might (and i am purposefully
saying _might_) not hold true.

i think it only makes sense to further discuss this issue
if you are able and willing to subscribe to the point that context
is very very important.


let me explain why i think that python 2.2 has a bug (even so
i'll admit it's a minor one - as there exists a workaround).

sometime ago i had to write a generator for generating 
java-sources out of an uml-model from a modelling-tool. 
that was togetherj which is written completely in java.
usually in such tools if they are scriptable you have such
objects like an UMLModel, UMLPackage, UMLClass, UMLINterface
UMLRelation and so on. some of those tools realy have the
whole UMLMetamodel within them accessible for scripting.

usually when accessing modelinformation you write this kind
of code (for e.g in rational rose)
meths = System.getModel().getPackage("foo").getClass("Bar").getMethods()
for m in meths:
    generateClassMethod(m)

in togetherj this explicit typeinformation wasnt available.
one had a space full of generic elements at hand and the code
ended looking like that

elems = System.getElements()
for model in elems:
    if model.getType(UMLType.MODEL):
       packages = model.getElements()
       for pack in packages:
           if pack.getType(UMLType.PACKAGE):
              classes = pack.getElements()
              for cls in classes:
                  if cls.getType(UMLType.CLASS):
                     methods = cls.getElements()
                     for meth in methods:
                         if meth.getType(UMLType.METHOD):
                            getenerateClassMethod(meth)

upon encoutering this model i realy went nuts at first. i thought
these togetherguys must have been druged when doing this. after
diving further into their system it became obvious what these guys
did. because of the generic behaviour of there core-object (Element)
it was very easily for them to add a new UML-concept and have it
displayed either as a graphical icon (box or whatsoever) or as a
propertywindow.

somethin like the following was all they needed to do to make an 
Java-Interface editable.

class InterfacePropertyWindow(BasePropertyWindow):
    def __init__(self, element):
       ...
    def getType(self):
       return UMLType.INTERFACE

(made of course in java ;-) )

so from their point of view this was really cool and necessary.
from my context it was a load of sh*t. i had to write an awfull
lot of delagationcode that implemented a decent interface to
the uml-model.

i guess the same applies to python 2.2. for the purpose of
implementing metaclasses and having access to the metalayer
there is no need to destiguish between classes and instances.
for all the other people this might not necessarely be true.
even if you personally think it is a bad design to have
a typecheck - i personally think this heavily bound to the
context.

so i hope it might have become clear why i do think that the
absence of the possibility to know about a classinstance is
a bug.

ciao robertj