You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Vi...@gmx.de on 2003/06/16 20:10:52 UTC

[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

   ReflectedListPropertyParseResults#checkConsistency:

        if (readMethodParseResults == null && getMethodParseResults ==
null){
            return false;
        }

is this a deliberate decision? Can I not have write-only properties?
I know this sounds strange, but in this case my add-method is 
"addField(MetaField field)" which adds a field to a MetaClass and the 
corresponding getter is getDeclaredFields() (to make it distinguishable
from getAllFields()).
For now I will create a method getFields() and document that this is the
same
as getDeclaredFields().

I was just being curious.

On a side note: I think it will be quite difficult to add something (e.g. a
new 
method parser) to Clazz without a very good documentation.

Regards
Victor


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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

Posted by vi...@gmxpro.net.
--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Wed, 18 Jun 2003 15:24:35 +0200 (MEST)
From: victor.volle@gmxpro.net
To: commons-dev@jakarta.apache.org
Subject: 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
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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

Posted by vi...@gmxpro.net.
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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: Extending Clazz

Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Victor,

1. Are you really trying to add support for a FAMILY of reflected
clazzes? It almost sounds to me that you want to modify accessor
recognition for some specific clazzes. If that's what you are trying to
accomplish. There is a much easier way to do so: you create a custom
Clazz. If it is named propery, it will be automatically discovered by
the framework.  See for example
org.apache.commons.clazz.reflect.extended.CustomBean1ExtendedClazz

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 ClazzLoader is 
automatically allocated by Clazz for each ClassLoader as needed.  Where
would we put the hook for configuration?

3. AccessorMethodParsers rather than subclassing them is really not an
option either.  An AccessorMethodParser needs access to the Method to
extract its piece-parts from it.  There is no easy way to predict what
those parts are.  Will it use the type of some argument or some part of
the method name or its visibility or exceptions thrown - who can now?

It is important to understand that you only need to go through all this
trouble of creating ClazzLoaders and custom implementation of Clazz if
you are introducing a new programming model like Extended Java Bean or
something of sorts.  You don't need to do any of that if you just need
to customize an individual clazz: for that you either create a specific
custom implementation of Clazz or use BeanInfo.

- Dmitri



--- victor.volle@gmxpro.net wrote:
> 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 ReflectedClazzLoader
> 5) add the ClazzLoader created in step 4 to an
>     existing ClazzLoader
> 
> I find this quite a lot to do. 
> 
> 1) Wouldn't it be possible to create a new _instance_ 
>     of ReflectedPropertyInspector and configure the 
>    (two) AcessMethodParsers.
> 2) Wouldn't it be possible to simply create a new
>     instance of a BaseAccessMethodParser that has 
>     some methods like
>    
>       - getRequiredPrefix AND setRequiredPrefix (etc.)
> 
>     so that again, I would not need to subclass
> 3) The only reason to create a new subclass of
>     ReflectedClazz seems to be that it has to implement
>     getPropertyInspectors().
>     Why is this method in ReflectedClazz and not in 
>     ClazzLoader? 
>     And again why do I have to subclass wouldn't
>     a BaseReflectedClazz with getter AND setter for
>     PropertyInspectors be sufficient?
> 4) ...
> 
> So it mostly boils down to subclassing vs. "configuring".
> 
> (Besides the remark on the placement of the 
> getPropertyInspectors() method in step 3) which I simply
> do not understand.)
> 
> I do not know, if it's just my preference, but I really dislike
> having so many classes around.
> 
> The simplest solution I could imagine looks something like:
> 
>   AccessorMethodParser readMethod = new BaseAccessMethodParser();
>   readMethod.setRequiredPrefix("add");
>   readMethod.setRequiredParameterCount(1);
>   readMethod.set...
>   // for some methods like getValueType() a subclass might still be
> needed!
>  
>   AccessorMethodParser writeMethod = new BaseAccessMethodParser();
>   ...
> 
>   reflectedPropertyInspector inspector = 
>      new ReflectedPropertyInspector(readMethod, writeMethod);
> 
>   ClazzLoader clazzLoader = ...;
>   clazzLoader.appendPropertyInspector(inspector);
> 
> Could this work with Clazz? 
> 
> Regards
> Victor
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Extending Clazz

Posted by vi...@gmxpro.net.
>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 ReflectedClazzLoader
5) add the ClazzLoader created in step 4 to an
    existing ClazzLoader

I find this quite a lot to do. 

1) Wouldn't it be possible to create a new _instance_ 
    of ReflectedPropertyInspector and configure the 
   (two) AcessMethodParsers.
2) Wouldn't it be possible to simply create a new
    instance of a BaseAccessMethodParser that has 
    some methods like
   
      - getRequiredPrefix AND setRequiredPrefix (etc.)

    so that again, I would not need to subclass
3) The only reason to create a new subclass of
    ReflectedClazz seems to be that it has to implement
    getPropertyInspectors().
    Why is this method in ReflectedClazz and not in 
    ClazzLoader? 
    And again why do I have to subclass wouldn't
    a BaseReflectedClazz with getter AND setter for
    PropertyInspectors be sufficient?
4) ...

So it mostly boils down to subclassing vs. "configuring".

(Besides the remark on the placement of the 
getPropertyInspectors() method in step 3) which I simply
do not understand.)

I do not know, if it's just my preference, but I really dislike
having so many classes around.

The simplest solution I could imagine looks something like:

  AccessorMethodParser readMethod = new BaseAccessMethodParser();
  readMethod.setRequiredPrefix("add");
  readMethod.setRequiredParameterCount(1);
  readMethod.set...
  // for some methods like getValueType() a subclass might still be needed!
 
  AccessorMethodParser writeMethod = new BaseAccessMethodParser();
  ...

  reflectedPropertyInspector inspector = 
     new ReflectedPropertyInspector(readMethod, writeMethod);

  ClazzLoader clazzLoader = ...;
  clazzLoader.appendPropertyInspector(inspector);

Could this work with Clazz? 

Regards
Victor


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: Clazz User Guide

Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Great!  Do you want to merge my overview with it?

http://jakarta.apache.org/commons/sandbox/clazz/overview.html

It would be great if the user guide were in xdocs.  This way we could
easily incorporate it into the clazz website.

Thanks,

- Dmitri


--- victor.volle@gmxpro.net wrote:
> 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, especially
> concerning
> the language (I am not a native speaker, if anyone didn't recognize
> yet
> :-)).
> 
> Victor
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Clazz User Guide

Posted by vi...@gmxpro.net.
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, especially concerning
the language (I am not a native speaker, if anyone didn't recognize yet
:-)).

Victor


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [Clazz] names of classes

Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Thanks, good points.

- Dmitri

--- Victor Volle <vi...@gmx.net> wrote:
> 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 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
> like
> the ~Support classes in Clazz. E.g. 
> 
>    ReflectedPropertyIntrospectorSupport
> 
> might be called 
> 
>    AbstractReflectedPropertyIntrospector or
> BaseReflectedPropertyIntrospector
> 
> 
> and to keep it consistent with my previous remark, it should be
> called:
> 
>    AbstractReflectionPropertyIntrospector or
> BaseReflectionPropertyIntrospector
> 
> I would easily agree that these are minor changes, but since I have
> such a
> difficult 
> time understanding the framework, I just write down every single
> issue I
> stumble 
> upon.
> 
> Regards
> Victor
> 
> PS: more to come
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[Clazz] names of classes

Posted by Victor Volle <vi...@gmx.net>.
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 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
like
the ~Support classes in Clazz. E.g. 

   ReflectedPropertyIntrospectorSupport

might be called 

   AbstractReflectedPropertyIntrospector or
BaseReflectedPropertyIntrospector


and to keep it consistent with my previous remark, it should be called:

   AbstractReflectionPropertyIntrospector or
BaseReflectionPropertyIntrospector

I would easily agree that these are minor changes, but since I have such a
difficult 
time understanding the framework, I just write down every single issue I
stumble 
upon.

Regards
Victor

PS: more to come


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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

Posted by Volle <v....@computer.org>.
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 clean design of Clazz
even if I still find a little bit too complicated.
(I need some visual design docs tounderstand things
like these.)

I can tell in a week or two, if I will use it.

Regards
Victor

Quoting Dmitri Plotnikov <dp...@yahoo.com>:

> Victor,
> 
> Alternatively, you could write a custom Clazz for you class, which
> would recognize getDeclaredFields() as the read method for the property
> "fields".
> 
> Are you seriously thinking about using Clazz?  Do you think it deserves
> to have a release?  I am morally ready to do a release as long as there
> is support for it.
> 
> - Dmitri


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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

Posted by Dmitri Plotnikov <dp...@yahoo.com>.
Victor,

Alternatively, you could write a custom Clazz for you class, which
would recognize getDeclaredFields() as the read method for the property
"fields".

Are you seriously thinking about using Clazz?  Do you think it deserves
to have a release?  I am morally ready to do a release as long as there
is support for it.

- Dmitri


--- Victor.Volle@gmx.de wrote:
> 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
> 
>    ReflectedListPropertyParseResults#checkConsistency:
> 
>         if (readMethodParseResults == null && getMethodParseResults
> ==
> null){
>             return false;
>         }
> 
> is this a deliberate decision? Can I not have write-only properties?
> I know this sounds strange, but in this case my add-method is 
> "addField(MetaField field)" which adds a field to a MetaClass and the
> 
> corresponding getter is getDeclaredFields() (to make it
> distinguishable
> from getAllFields()).
> For now I will create a method getFields() and document that this is
> the
> same
> as getDeclaredFields().
> 
> I was just being curious.
> 
> On a side note: I think it will be quite difficult to add something
> (e.g. a
> new 
> method parser) to Clazz without a very good documentation.
> 
> Regards
> Victor
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org