Re: [Clazz] subclassing vs. configuration (Was: Extending Clazz)

Dmitri, ok, I think I understand how it works internally. But I honestly must say I do not understand the reasons for all this ClassLoader stuff, or at least I do not know the requirements which lead to a mechanism, that is much to complicated for what I need. What Clazz did was to mimic java.l

[Clazz] subclassing vs. configuration (Was: Extending Clazz)

Dmitry: > > > 2. The reason all those things are implemented as subclasses rather > > > than configuration-based instances is precisely to avoid the need > > > for configuration. In any complex environment you are working with > > > lots of ClassLoaders, which are allocated by some container. > >

[Clazz] getFoos and addFoo: property name "foos" or "foo"

--- Weitergeleitete Nachricht / Forwarded Message --- Date: Wed, 18 Jun 2003 15:24:35 +0200 (MEST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: getFoos and addFoo: property name "foos" or "foo" > Hi, > > if I have the following class > > public class Hrglbrmft { >public void addFo

getFoos and addFoo: property name "foos" or "foo"

Hi, if I have the following class public class Hrglbrmft { public void addFoo(Bar bar) { ... } public List getFoos() { ... } } should the property returned by Clazz be called "foos" or "foo"? Currently "foos" is returned. Victor

Extending Clazz

>From the (perhaps not quite current?) overview I concluded that to extend Clazz for "Customizing a Family of Reflected Clazzes" I have to create 1) a subclass of Reflected*PropertyInspector 2) some (two) AccessMethodParsers 3) a subclass of (Standard)ReflectedClazz 4) a subclass of ReflectedClazz

Re: [Clazz] names of classes

Hm, have never recognized these ... and ~Support" is only used in the java.beans... packages. and Abstract~ is used in the java.util.* and in javax.swing... Victor > I typically use the suffix "Support" for non-required, non-abstract > convenience base classes. The word comes from the JDK. See

Re: [Clazz] names of classes

> >I do not like the names of ~Support classes. ~Support or ~Helper indicate > >(for me) > >that these are Helper classes with (often static) utility functions. In > the > >Java API I think > >I have found the usage of Abstract~ or Base~ much more often for classes > > You've missed an important d

Clazz User Guide

Hi! I have uploaded the first few paragraphs of my User Guide to http://www.artive.de/clazz/docs/userguide.html I am not promising to finish it, but if not, you can use it (put it under the Apache license) and change it anyway you want. I am (for now) very willing to make corrections, esp

[Clazz] names of classes

Hi, some nitpicking from me (currently trying to write a user guide for me): why is ReflectedPropertyIntrospector not called ReflectionPropertyInspector? Would be a little bit clearer from my point of view, that objects of this class are actively doing something. I do not like the

[Clazz] class with "add*" but without get* or set*

I was just playing around with Clazz (thinking about replacing my horrible own hack) and stumbled across the following. I have a class that contains a method addFoo(Foo foo) but not getFoos() or setFoos(List list) so Foo is not considered a property because of the following code in Refle

[lang] what about mutable BigInteger etc.

Hi! What do you think about implementing mutable BigInteger and BigDecimal classes as part of a [math] package? Using BigDecimal for financial applications comes with a big drawback: for every calculation a new BigDecimal object is created since BigDecimals are immutable. You might even need t

Re: [attributes][clazz]

> Thus one way to think of the difference is [attributes] is static, [clazz] > is instance based. Another important difference is, that the [attributes] API is based on java.lang.Class, java.lang.reflect.Field, java.lang.reflect.Method, whereas [clazz] has its own MetaModel. Victor -- To unsu

Re: [clazz] draft reflect implementation

Property. So to make the meta model useful for me, reflection specific code would have to be moved down to the ReflectionProperty. I am not sure that this solution suits the needs of anyone besides myself. Victor > Dmitri > > Dmitri wrote: > > Victor Volle wrote: > > >

Re: [clazz] draft reflect implementation

Dmitri Dmitri wrote: > Victor Volle wrote: > > PS: I am hesitating to offer my help, yet (besides criticism :-)) > > because I am still not sure that I can use it for my own project > > and I would like to wait for the "dust to settle". > Critisizm is in fact ext

[clazz] Some general thoughts on the design

Dmitri, your design reflects a decision I am currently having to make. So I would like to discuss the two possibilities and think about the possible suitability to [clazz]. We have some interfaces but no (abstract) default implementation. That means: for each ClazzLoader XXX we have to provide o

Re: [clazz] Naming

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

Re: [clazz] Naming

Stephen, > > Oh, agreed. But then it should be (Meta)Attribute and we need > > to find some better name for the MetaData stuff. Just brainstorming: > > > >aspect, dimension, extension, domain, ... > > But why not use 'Property' then the name clash doesn't arise? I would not like to call a "

Re: [clazz] Naming

> > from:Victor Volle <[EMAIL PROTECTED]> > > Do we need Clazz at all? > > What is the difference between Clazz (Bean) and MetaClass? > > What is Clazz (Bean) responsible for? > > In the JDK the parallel is Class vs Object. In [beanutils] the parallel

Re: [clazz] Some code to consider

Stephen > > BTW: in XMI operations and fields are subsumed under the name "feature". > > Could be useful name. Is there a simple quick guide to XMI anywhere you > know of? Not really. There is a book on XMI I am currently reading (meaning I won't have finished until the end of year) Victor --

Re: [clazz] Some code to consider

> > from:Victor Volle <[EMAIL PROTECTED]> > > 1. I do not like the name MetaBean, I would prefer Clazz or > > MetaClass, because "Bean" implies that I have to have > > getters and setters. I know that this is an important use > > case, but sometim

Re: [clazz] Some code to consider

Stephen, good idea to have something concrete. > I have checked into the [clazz] sandbox some classes. They represent the > basic ideas of where I was headed. > > They include a meta model > MetaBean > MetaProperty > MetaOperation > all extending MetaUnit 1. I do not like the name MetaBean, I w

Re: [clazz] Type-based or instance-based metadata? Take II

> a) We introduce all those methods suggested by Victor Volle: It was never meant as a suggestion but rather as a "beware" :-) > boolean isIndexed(); > boolean isMapped(); > boolean isListed();// I would call it "isUnorderedCollection" > > w

Re: [clazz] Clazz API mock-up

Berin > Victor Volle wrote: > >>Just wanted to clarify the naming: what you call Attributes are not the > >>same > >>as what Berin calls Attributes. Your Attributes are like my Fields. > > > > > > Yes, I think so. Imagine a class "Foo"

Re: [clazz] Clazz API mock-up

> Just wanted to clarify the naming: what you call Attributes are not the > same > as what Berin calls Attributes. Your Attributes are like my Fields. Yes, I think so. Imagine a class "Foo" with an instance variable "bar". In the MetaModel the MetaClass Foo would have an (Meta)Attribute that has

Re: [clazz] MetaModel

> This is a very good model, thanks for publishing it. It is somewhat > similar > to Stephen Colebourne's AClass etc. Where can I find that? Victor -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [clazz] Clazz API mock-up

Dmitri > Victor, > > - Original Message - > From: "Victor Volle" <[EMAIL PROTECTED]> [SNIP] > > So we need some Methods like isIndexed(), isMapped(), > > isListed()? > I agree. I am not sure about isListed though. Will there be any &g

[clazz] MetaModel

Some time ago I created a MetaModel for a code generator. Perhaps you are interested in it? I have attached an overview (UML) as GIF Victor <>-- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [clazz] Clazz API mock-up

> Please check out the two attached classes: Clazz and Field. These are What about Method? > client > APIs only. Nothing is said about where the metadata is coming from - > that's > to come later. > > Here are some notes on the design of these two classes: > > 1. Clazz is a metadescription of

Re: [clazz] Supported object model list

> IClass has the ability to store arbitrary meta data > void setMetaData(Object key, Object value) > Object getMetaData(Object key) > but this may be too weak a form of meta data? What about "pluggable domains", that is for a certain "domain" like say "EJB" you can configure factories: addD