On 5/26/05, Martin Cooper <[EMAIL PROTECTED]> wrote:
>
> I'm not sure how you can be burned by not having direct access to a
> member while there are getters and setters available.
My mistake. The cases that keep flashing in my head provided getters
(if even that) but no setters. In those case
On 5/26/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
> > Hubert Rabago wrote:
> >
> > my intention here was to have _all_ the accessor methods of "properties"
> > in BaseConfig - i guess it can be a hinderance when the classes a
> > changing ra
If I understood what you're saying, then yes, that's how all other
config fields are, and I'll probably change 'properties' to conform to
that (unless someone else beats me to it).
Hubert
On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
> Hubert Rabago wrote:
>
> > Yes, but it doesn't mean I
Hubert Rabago wrote:
Yes, but it doesn't mean I'm not open to other ideas. In this case,
I started out reading from everywhere that fields should be private,
and everything should go through accessors (even subclasses). But I've
been burned by that restriction LOTs of times (in some cases, I h
Hubert Rabago wrote:
Yes, but it doesn't mean I'm not open to other ideas. In this case,
I started out reading from everywhere that fields should be private,
and everything should go through accessors (even subclasses). But I've
been burned by that restriction LOTs of times (in some cases, I h
On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
> at the moment the getProperties() returns the Map object. no necessity
> for the 2 accessor methods getProperty,setProperty
>
The getProperties()/setProperties() accessors are protected and are
for subclasses. The getProperty()/setPropert
Hubert Rabago wrote:
That's what we have now, accessors of "properties" in BaseConfig. In
fact, that's the only way to access them, which goes against the
convention set by most (if not all) other config objects. Other
config objects declare their fields as protected, allowing custom
subclasse
On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
> Hubert Rabago wrote:
>
> my intention here was to have _all_ the accessor methods of "properties"
> in BaseConfig - i guess it can be a hinderance when the classes a
> changing rapidly as u've mentioned. i think of it as a 'cleaner' way :)
>
Hubert Rabago wrote:
I'm not sure I want to forbid config subclasses from accessing
their properties directly. I've come across several libraries
and frameworks which used "private" all throughout and made it
difficult if not impossible for me to customize certain behavior.
(I'm still running
On 5/25/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:
>
> just a thought.
>
> ie, not expose the "properties" object (as it is) by the
> getProperties,setProperties methods.
I'm not sure I want to forbid config subclasses from accessing
their properties directly. I've come across several librar
On 5/25/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> I was wondering about this:
>
> > BeanUtils.copyProperties(copy, baseHandler);
> > this.addExceptionConfig(copy);
> >-
> >+copy.setProperties(baseHandler.getProperties());
> >+
>
> doesn't the
I was wondering about this:
BeanUtils.copyProperties(copy, baseHandler);
this.addExceptionConfig(copy);
-
+copy.setProperties(baseHandler.getProperties());
+
doesn't the strategy you implemented clobber properties which are
set on the extendi
12 matches
Mail list logo
