commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <>
Subject Re: [clazz] Naming
Date Thu, 31 Oct 2002 20:09:01 GMT
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 

> > 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:   <>
For additional commands, e-mail: <>

View raw message