Make the method names shorter?

[jrduncans]

Should the names of the methods in EasyMockPropertyUtils be shortened?
What's your preferred name:

propertiesEq (current)?
propsEq
propEq

I generally prefer the longer form, but I'll take your responses into
consideration to change it.

[Jiri Mares]

There is 2 proplems eith the current method names:

1. they are too long
2. they are different (propertyEq and propertiesEq)

In the BeanProperty class you append only the propertyEq :-(

Therefore I suggest propEq.

jirka

[Jiří Mareš]

Hi Stephen,

another small improovement, the read method can be null.

--
Jiří Mareš

[Stephen Duncan]

I've committed a change to make all the method names be "propEq"
(leaving the old names as deprecated). I've also committed a change
to use the PropertyUtils for getting the properties from the object.
Could you perhaps provide a new patch with just the annotations stuff?
And maybe some code sample for how you envision it being used?

If this is too much work, just let me know, and I think I can piece it
together, but a fresh patch would make it easier...

-Stephen

> Ji � Mare�
>
> >
>
>

--
Stephen Duncan Jr
www.stephenduncanjr.com

[Jiri Mares]

Hi Stephen,

I'm at the moment a little bit thinking about the direction how to
implement my requirements. For me it is not a big problem to prepare a
new patch, but on monday.

Jirka

[Stephen Duncan]

Sounds good.

-Stephen

[Jiri Mares]

Hi Stephen,

at the moment I'm thinking about the right direction. For me is the
best way to compare the live objects (not to specify properties and
values in map). So I pass an object into propEq and want to compare it
with the passed value (something like equals but not by id, but by all
properties).

The problem is, that some properties are derived (compare them makes
no sense) and some I don't want to compare at all, because of diferent
reasons. So there is necessary to have way how to mark properties that
should not be compared.

There are 3 ways at the moment that I know, and none is perfect (maybe
you have any idea how to improove):

- compare not by properties (get.. and set.. methods) but by fields -
not good because imposibility to compare two objects with same
superclass and get.. and set... methods but diferent fields -> NOT
USING

- to each class and list (array) of property names that have to be
ignored during comparing - I'm using it at the moment, but this is not
refactoring save

- to each get... method add anotation, that can mark the property,
that is not used during comparing -> great but the business code is
dependent on the testing code (has to know the annotation)

Which direction to go?

Jirka

[Stephen Duncan]

Sorry for not responding.

My initial use case was where I call a method with an object, it
converts it to another object and calls a method on my mock service.
That is why I initial only went with the string/map for properties.

I think I would tend to mostly use a list of ignored properties and
deal with it not being safe for refactoring. I don't know for sure,
as I don't have anything currently using the methods that take in an
object.

If you would still like support for annotations, then I am ok with
adding them, as long as they do not affect the API for those who do
not wish to use the annotations. Please let me know as I would like
to make a release very soon.

-Stephen