On Thursday 31 October 2002 07:37 am, Victor Volle wrote: > Steve > > Steve Downey wrote: > > Clazz, or whatever, should provide MetaClass facilities. That is, it > > should be > > > for creating, manipulating, etc Class instances. And, in java, an > > instance > > of > > > java.lang.Class is a class. So j.l.Class is a type of MetaClass. > > Technically a MetaClass is a Class. But semantically a class whose > instances are classes is a MetaClass. So it might help to distinguish > both by using the prefix Meta (as in Smalltalk80) or some other > naming scheme. > Yes, and a natural number N is the class of all classes containing N elements. What I was trying to get at was that Class and Clazz are both instances of MetaClass. I think. In fact, if Class wasn't final (and I hate the number of times I've had to say that with Java), Clazz might even be a subtype of Class. As it is, a Clazz which describes a particular class (e.g. org.apache.commons.FooBar) probably has a reference to o.a.c.FooBar's Class instance.
> > But that shouldn't open the door for naming everything else Meta. > > > > A property that applies to an instance of Clazz isn't a meta property, > > it's a > > > class property. > > Same objection as above. > I'm not sure what the objection is? Could you clarify? I think it depends what metamodel is being followed. Some do use metaproperty to describe properties of classes of things, or for properties applying to a whole system. > > These are frequently called attributes, to distinguish them > >from properties, which apply to, and vary with, instances. If we use > > Attribute as the name of class properties, we need something to use for > > Property, in order not to conflict with ... nothing. There isn't a class > > j.l.Property. So Property is a decent name for describing object, as > > opposed > > > to class, properties. > > > > Field, on the other hand, usually means an actual slot in the object. A > > field > > > is never implemented virtually, the way a property might be. So Complex > > might > > > have fields real and imaginary, but properties real, imaginary, radius > > and > > > > theta. [With radius and theta being read only. Don't make properties have > > side-effects] > > This difference between Fields and Properties never became clear > to me before. I think this is an important difference, which should > be reflected in the API. So a property might have a Field but does > not need to, so perhaps "hasField()" or simply offer getField(). > > [SNIP] > Field is a part of the description of the structure of a class, whereas Property comes out the tool building side of things. It's a way of letting a tool know how to manipulate a component. Some languages, like Delphi, go even further, and can hide the difference syntactically between a field and a property. What looks like simple assignment is actually a call to a properties setter, for example. > I do think Stephen (Colebourne) is right that it might be better > to start prototyping and to see if the names fit. > > Victor -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
