RE: [reflect] Open for business

["Shapira, Yoav" <Yo...@mpi.com>]

Howdy,
I'd like to help a bit, especially on caching.  But since tests seem to
be the hot topic, what areas are most sorely lacking tests?

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>Sent: Friday, August 29, 2003 7:59 PM
>To: Jakarta Commons Developers List
>Subject: [reflect] Open for business
>
>The [reflect] sandbox project is now open for business. Code has been
>imported from [lang], adjusted and tidied up. And the tests even pass.
(But
>thats probably because there aren't enough of them ;-)
>
>TODO
>- Bean-like reflect implementation behind static classes
>- Tests
>- Caching
>- Tests
>- Field/Constructor tests
>- Tests
>- Delegates from C#
>- Tests
>- oh and Tests ;-)
>
>All commons committers welcome to join and submit patches or contribute
>directly.
>
>Stephen
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

Re: [reflect] Open for business

[Stephen Colebourne <sc...@btopenworld.com>]

Basically, only MethodUtils has tests. So ConstructorUtils and FieldUtils
need some.

However, probably the first thing to consider is whether to move to a bean
based design. What I was thinking was to have a basic bean for each of
Method, Field and Constructor. Then a subclass or wrapper bean to add
caching behaviour. (Sometimes you know you don't need to cache, if you are
only calling once. Also JDK1.4 is faster and caching is less important)

Other possible bean differences would be whether to break security or not
using the setAccessible() method. The current Utils interface tries to
handle all of this via boolean flags, which I dislike. Of course, we'd need
to keep the Utils classes for simple flat access.

So actually, I think refactoring comes before tests, which may cheer you up!
Perhaps you could propose a detailed bean based design that would cover the
usages above? :-)))

Stephen

----- Original Message -----
From: "Shapira, Yoav" <Yo...@mpi.com>
Howdy,
I'd like to help a bit, especially on caching.  But since tests seem to
be the hot topic, what areas are most sorely lacking tests?

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>Sent: Friday, August 29, 2003 7:59 PM
>To: Jakarta Commons Developers List
>Subject: [reflect] Open for business
>
>The [reflect] sandbox project is now open for business. Code has been
>imported from [lang], adjusted and tidied up. And the tests even pass.
(But
>thats probably because there aren't enough of them ;-)
>
>TODO
>- Bean-like reflect implementation behind static classes
>- Tests
>- Caching
>- Tests
>- Field/Constructor tests
>- Tests
>- Delegates from C#
>- Tests
>- oh and Tests ;-)
>
>All commons committers welcome to join and submit patches or contribute
>directly.
>
>Stephen
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


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