[Zope] Zope and Polymorphism

[Steve Spicklemire]

Hi about something like this (External method):

#
#
# Check a classes base types for a certain meta_type...
#
#

def checkClassMetaType(theClass, meta_type):
    """ check a class... and all super classess for meta_type...."""

    result = 0

    if theClass.meta_type == meta_type:
        result = 1
    else:
        for subClass in theClass.__bases__:
            result = checkClassMetaType( subClass, meta_type)
            if result:
                break

    return result


def checkObjectMetaType(self, object, meta_type):
    """ check and object for an ancestral meta_type..."""

    if object.meta_type == meta_type:
        return 1
    else:
        return checkClassMetaType(object.__class__, meta_type)

----------------------------------------------------------------------
>>>>> "Ingo" == Ingo Assenmacher <ingo.assenmacher@post.rwth-aachen.de> writes:

    Ingo> Hi Rik.

    Ingo> Am 09-Feb-00 schrieb Rik Hoekstra:

    >>> Thats really ugly having to know the distingishing method
    >>> names.  Isn't there some method like
    >>> _.inheritsfrom(_['sequence-item'],'Folder')
    >>> 
    >>  This doesn't look very nice to me...

    Ingo> No, it does not... but it would come in handy... :)

    >> You could test whether an object was 'Folderish', but at the
    >> moment I have neither a clue how to do it ;-\ nor the time to
    >> sort it out ;-(
    >> 

    Ingo> That is ok. Knowing that an object is 'Folderish' would be
    Ingo> enough of a clue for example to provide a standarised image
    Ingo> for a folder object within a tree.


    >> but you can give objectValues more arguments (the argument _is_
    >> a list).  So that would mean in this case
    >> 
    >> <dtml-in "objectValues(['Folder',
    >> 'UploadFolder',AnyOtherMetatypeYouCanThinkOf, ...])"> [bla]
    >> </dtml-in>
    >> 
    >> Note that this can include any metatype you want, not just
    >> folders or 'folderish' objects. If you want you can filter them
    >> further using their attributes, properties or whatever.

    Ingo> That is of course right. But let me point out a little
    Ingo> example I have in mind:

    Ingo> Right now I am constructing a container object to which
    Ingo> arbitrary files can be uploaded and it is then dislplayed
    Ingo> within a table. For that purpose I created a container
    Ingo> object which can contain very general "document objects". To
    Ingo> those I provided some basic information which must be
    Ingo> included into every upload (description, timestamp and
    Ingo> who-did-the-upload stuff). I thought it would be nice to
    Ingo> derive some objects from this baseclass (dokument) which can
    Ingo> have more properties (keywords, references etc.). On an
    Ingo> abstract level I basically want to do the same with these
    Ingo> objects: display them (plus properties) in a table.  This
    Ingo> could generally be done by method overloading. Ok so
    Ingo> far. Since it could be possible to mix several dokument-sub
    Ingo> classes in one container it would be very nice NOT to name
    Ingo> the items to be enumerated explicitly (like providing more
    Ingo> arguments to the objectValues method). Right now I could use
    Ingo> the "feature" of polymorphism very much. That was what
    Ingo> raised my question.  If there is no such thing a
    Ingo> polymorphism... well I can live with that and do some
    Ingo> workarounds. After all it would "only" be very comfortable
    Ingo> to simply do method overloading and let Zope call the right
    Ingo> method. This would enable a single declaration of

    Ingo> <dtml-in "objectValues(['Dokument'])"> [display data here,
    Ingo> even from derived objects] </dtml-in>

    Ingo> instead of adjusting the parameter with every new sub-class
    Ingo> of Dokument.


    Ingo> Regards, Ingo

    Ingo> ------------------------------------------

    Ingo> _______________________________________________ Zope
    Ingo> maillist - Zope@zope.org
    Ingo> http://lists.zope.org/mailman/listinfo/zope ** No cross
    Ingo> posts or HTML encoding!  ** (Related lists -
    Ingo> http://lists.zope.org/mailman/listinfo/zope-announce
    Ingo> http://lists.zope.org/mailman/listinfo/zope-dev )