Dan,
Sorry if I'm flogging a dead horse, but I just caught this call via the
summarizer.
> Okay, here's another shot at the semantics for objects [for perl 6]. If
> folks,
> especially non-perl folks, would look this over and chime in, I'd
> much appreciate it.
> Objects have (all optional):
> *) Properties
> *) Methods
> *) Attributes
Add to that:
*) A superclass (obviously, but I consider it to be the same level as
Properties, Methods and Attributes.)
*) Associations, eg in UML.
*) a set of Interfaces (similar to multiple inheritance; a way of
grouping methods associated with a class for another to implement).
eg, in Java and IDL.
Associations are similar to special types of attributes, that are typically
represented in Perl 5 by a collection, such as a hash, array or set -
depending on whether the association is keyed, ordered or unordered.
Associations may be *one way* - in which case the referred objects do not
have a way of referring to the objects that contain them for that
particular association. ie, like all of Perl 5's references and
collections.
They may be *two way* - in which case referred objects receive a
`back-reference', which is another container that is the symmetric
opposite of the first association. Two-way associations belong to both
classes. Adding Object A to B.association is the same as adding B to
A.backref. Tangram does something like this with its `back-references',
as does an experimental version of the object prototyping system I have in
the works.
Associations may have *mutliplicity* on BOTH ends. That is, one to many,
many to many, many to one, one to one relationships. Whether or not
multiplicity limits are enforced on the *source* side would probably be
tightly linked with whether or not the relationship is two way or one way.
This information is enough to then take the object structure, and assuming
you have a description of the types of attributes as well, map it to an
RDBMS (say) using foreign keys, link tables et al.
Actually the ability to describe attributes, and place limits on their
contents that are both hints to database mapping tools and generate
run-time exceptions when abused is a damned handy tool from a software
engineer's perspective.
Interfaces are similar to multiple inheritance from a functional
perspective; a bit like adding a class to @ISA, but qualifying exactly
what methods you're including, and probably not inheriting any of the
attributes at all. Which of course, you may later be overriding.
For what it's worth, I have most of this functionality duplicated into
JavaScript. It can be co-erced into having classes, etc - you just need
to rely on convention.
Are you going to implement the concept of `scope' of methods/attributes?
Many other languages have it, and I think in some circumstances it can
help clarify the intent of code. Of course anally requiring it to be
specified ends up with a language like Java :-).
My humble opinion is that `public' attributes should just be implemented in
terms of automatically generated accessor functions.
Sorta like taking Class::Contract, Class::MethodMaker, Alzabo,
Class::Tangram and recognising the common concepts - then making them all
effectively obsolete by unifying the concepts into the language :-).
my 2c.
--
Sam Vilain, [EMAIL PROTECTED]
"I like a man who grins when he fights."
- Winston Churchill -
