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

[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. A

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

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

[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 addFoo(Bar

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

Hi Dmitri, not yet sure, for me it is still a bit too complicated. If I have the *fealing* that I understand it and I can retain my higher level interfaces (to invoke the get/set/add methods) I really think about switching, because my own code became quite a mess in the meantime and I like the

[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

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,

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 difference

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 for

[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

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

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 extremely valuable help. What I want to know

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: PS: I am hesitating to offer my

[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

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

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 is DynaClass vs DynaBean. Its the instantiated

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 sometimes I am only interested in the operations (interfaces etc

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 -- To

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:

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 a

[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 attachment: overview.gif-- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail:

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: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail:

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 the

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 would