to abstract OOP

[Torsten Anders]

Dear Denys, dear Christian,

Thank you for your answers! When, I posted my first question on this thread,
  I aimed for two things:
- modularity: I probably later need to change the implementation of some 
classes
   and want to keep higher-level functionality on objects of that class 
outside the
   class def (you see, coming form Lisp I dreamed of something like generic
   functions ;-)
- reflection: I want to have access to the class hierarchy, e.g., I would 
like
   to have a method understandsMethod(M ?B) for all (of my) objects to avoid
   certain errors.

Meanwhile, I realized a more simple way for modularity. My class 
definitions only implement the basic interface (generators, accessors, 
type-checking...). Everything else is defined by procedures resp. functions.

So, now I only aim for reflection writing the class hierarchy. Actually, 
most of (or even all?) the information I am looking for is already 
contained in the class data structure (direct-super-classes, super-classes,
  methods...). Unfortunately, I can not access it -- this data is protected 
by 'name-features'.

So, therefore I plan to do some book-keeping in the class definition. In 
every class I put at a feature some data structure containing the class 
information: the class, its super classes, its features, attributes, 
methods, and properties. Of course, you easily forget to update this info 
when you change your class definition later. Therefore, I would prefer to 
access the information already available in the class itself. Is there some 
way to do that? For my application security is not an issue (I am a 
musician :-)

On Thursday, May 15, 2003, at 10:32  am, Christian Schulte wrote:
> If you want to follow a different discipline of inheritance than the strict
> (but safe) flavour Oz provides you can also maintain the hierarchy 
> yourself.Then you could create class from your hierarchy by computing 
> which methods
> are in and create a class accordingly. This at least would free you from
> class creation and would render your inheritance mechanism compatible with
> Oz objects.

I probably don't want to leave the strict inheritance mechanism of Oz (I am 
used to a bit more freedom by CLOS, but in doubt that only causes headaches 
;-). Nevertheless, I do not fully understand your comment, could you point 
me to some more information?

Thank you very much!

Kind regards,
Torsten

PS: Sorry for my lengthy postings.

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
Please send bug reports to bugs at mozart-oz.org.