You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Donnie Hale <do...@haleonline.net> on 2002/01/06 03:22:25 UTC
ResourceLoader.init() question
Folks,
Hopefully this is an easy one.
I'm working with the up-to-date dev builds of Velocity as well as the
recently-posted velocity-tools stuff. I see that ResourceLoader.init() is
passed an ExtendedProperties parameter named "configuration". Where do that
object's properties come from? What properties can I expect to be in it? I
ask because the view.Webapploader class' init() method is using the
ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
application attribute set in VelocityViewServlet; and I was naturally
curious if that could not be passed in that "configuration" parameter.
And, just to be provocative, may I once again express my utter disdain for
protected member variables like ResourceLoader.rsvc. <g,d,&r>
Donnie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/5/02 10:01 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Saturday, January 05, 2002 9:30 PM
>> To: velocity-user@jakarta.apache.org
>> Subject: Re: ResourceLoader.init() question
>>
>>
>> On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>
>>> Folks,
>>>
>>> Hopefully this is an easy one.
>>>
>>> I'm working with the up-to-date dev builds of Velocity as well as the
>>> recently-posted velocity-tools stuff. I see that
>> ResourceLoader.init() is
>>> passed an ExtendedProperties parameter named "configuration".
>> Where do that
>>> object's properties come from? What properties can I expect to
>> be in it? I
>>> ask because the view.Webapploader class' init() method is using the
>>> ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
>>> application attribute set in VelocityViewServlet; and I was naturally
>>> curious if that could not be passed in that "configuration" parameter.
>>
>> That init is constructed in RuntimeInstance
>>
>>>
>>> And, just to be provocative, may I once again express my utter
>> disdain for
>>> protected member variables like ResourceLoader.rsvc. <g,d,&r>
>>>
>>
>> Whu?
>
> I'm assuming you meant "why?".
LOL
No, I really meant 'whi'
:)
>
> Primarily it's due to the "fragile base class syndrome". Derived classes
> which depend on these items from base classes, and by its nature a protected
> member variable is not a rigorous contract b/w base and derived class, are
> at the mercy of changes in the base class. Correspondingly, conscientious
> base class developers are hamstrung in their attempts to refactor or enhance
> the base class when they know that derived classes will be broken if they
> eliminate or change the type of a member variable.
That's fair.
>
> If base class developers are creating their class with the expectation that
> a derived class will need a certain service, formalize that expectation even
> if it's something as simple as a protected method returning the type in
> question. Then the base class developer is free to change things at will,
> providing adaptor functionality to continue fulfilling that contract as
> necessary.
That's also fair.
>
> There's also issues when the base class needs to add side-effect behavior to
> accessing one of its members, e.g. synchronization, logging, reference
> counting, etc.
That's different.
> FWIW...
>
> Donnie
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Sunday, January 06, 2002 11:28 AM
> To: velocity-user@jakarta.apache.org
> Subject: RE: ResourceLoader.init() question
>
>
> > The "template method pattern" doesn't have anything to do with
> > "templates" as in C++ or "generics" as in JDK 1.4/5. It's the name of a
> > pattern from the "Gang of 4" Design Patterns book. I don't have my copy
>
> Ahhh... I was thinking STL. I stand corrected.
>
> > in front of me right now to provide the "official" motivation and
> > application of the pattern, but, in short, it establishes a non-virtual
> > public interface through a base class whose implementation is a
> > "template" which can/must be overridden by derived classes.
> >
> > As far as protected member variables in a base class goes, Geir's last
> > message summed it up most concisely: it violates encapsulation.
>
> Sure, you're right! But then the way threading is implemented in Java
> violates Platform Independent Parallel Programming concepts set down 25
> years ago (See Binch Hansen's article "Java's Insecure Parallelism"
> Syracuse University 2-175 CST). And while we're at it the way the US
> implements the concept of the Republic violates the concept of
> Democracy...
The U.S. was never intended to be a democracy, but don't get me started on
that one. :)
>
> > While the books aren't Java-specific, the rules in Scott Meyers'
> > "Effective C++" and "More Effective C++" are highly applicable.
>
> Sheesh, I really have to stop reading the predecessors "Hapless C++"
> and "More Kludgey C++" books and get with the program. :D
>
> > Donnie
> >
> >
> >> -----Original Message-----
> >> From: Nick Bauman [mailto:nick@cortexity.com]
> >> Sent: Saturday, January 05, 2002 10:38 PM
> >> To: velocity-user@jakarta.apache.org
> >> Subject: RE: ResourceLoader.init() question
> >>
> >>
> >> Donnie said:
> >>
> >> [edit]
> >>
> >> > If one subscribes to the Liskov substitution principal (a derived
> >> > class should be able to be used wherever a base class is used w/o
> >> > the user having to know which it is), then more up-front attention
> >> > needs paid on two fronts: 1) what is the full contract of a base
> >> > class? 2) does a derived class really meet the "is-a" test?
> >> >
> >> > I'm a huge fan of the template method pattern, and I think it's
> >> > wider use in base classes would help enormously. As regards this
> >> > question, it would help because the base class would be enforcing
> >> > the state machine, if you will, through which its implementation
> >> > progresses. It could then very easily pass what might otherwise be a
> >> > protected member variable to an abstract template method for derived
> >> > class use.
> >>
> >> Templates aside for a moment and I generally agree (because I think
> >> they're good too), this is Java: we use interfaces to establish
> >> contracts.
> >> Liskov substitution principal is what the Java interface is all about.
> >> Without interfaces, implementations end up pushing more and more
> >> functionality up the heirarchy tree into what become abstract God
> >> classes.
> >> Yeech. While it's true that "nobody looks at what's in the base
> >> classes enough" (how many times have I seen people rewrite stuff
> >> that's
> >> already in
> >> the base class they weren't paying attention to!), this doesn't
> >> negate the
> >> value of protected members. Again, Templates aside, sometimes things
> >> are simply correctly factored by using protected member variables in a
> >> base class.
> >>
> >> --
> >> Nick Bauman
> >> Cortexity Development
> >> http://www.cortexity.com/
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@jakarta.apache.org>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org> For additional
> > commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> Nick Bauman
> Cortexity Development
> Intellectual Process is more important than
> Intellectual Property -- you'll see.
> http://www.cortexity.com/
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Nick Bauman <ni...@cortexity.com>.
> The "template method pattern" doesn't have anything to do with
> "templates" as in C++ or "generics" as in JDK 1.4/5. It's the name of a
> pattern from the "Gang of 4" Design Patterns book. I don't have my copy
Ahhh... I was thinking STL. I stand corrected.
> in front of me right now to provide the "official" motivation and
> application of the pattern, but, in short, it establishes a non-virtual
> public interface through a base class whose implementation is a
> "template" which can/must be overridden by derived classes.
>
> As far as protected member variables in a base class goes, Geir's last
> message summed it up most concisely: it violates encapsulation.
Sure, you're right! But then the way threading is implemented in Java
violates Platform Independent Parallel Programming concepts set down 25
years ago (See Binch Hansen's article "Java's Insecure Parallelism"
Syracuse University 2-175 CST). And while we're at it the way the US
implements the concept of the Republic violates the concept of Democracy...
> While the books aren't Java-specific, the rules in Scott Meyers'
> "Effective C++" and "More Effective C++" are highly applicable.
Sheesh, I really have to stop reading the predecessors "Hapless C++"
and "More Kludgey C++" books and get with the program. :D
> Donnie
>
>
>> -----Original Message-----
>> From: Nick Bauman [mailto:nick@cortexity.com]
>> Sent: Saturday, January 05, 2002 10:38 PM
>> To: velocity-user@jakarta.apache.org
>> Subject: RE: ResourceLoader.init() question
>>
>>
>> Donnie said:
>>
>> [edit]
>>
>> > If one subscribes to the Liskov substitution principal (a derived
>> > class should be able to be used wherever a base class is used w/o
>> > the user having to know which it is), then more up-front attention
>> > needs paid on two fronts: 1) what is the full contract of a base
>> > class? 2) does a derived class really meet the "is-a" test?
>> >
>> > I'm a huge fan of the template method pattern, and I think it's
>> > wider use in base classes would help enormously. As regards this
>> > question, it would help because the base class would be enforcing
>> > the state machine, if you will, through which its implementation
>> > progresses. It could then very easily pass what might otherwise be a
>> > protected member variable to an abstract template method for derived
>> > class use.
>>
>> Templates aside for a moment and I generally agree (because I think
>> they're good too), this is Java: we use interfaces to establish
>> contracts.
>> Liskov substitution principal is what the Java interface is all about.
>> Without interfaces, implementations end up pushing more and more
>> functionality up the heirarchy tree into what become abstract God
>> classes.
>> Yeech. While it's true that "nobody looks at what's in the base
>> classes enough" (how many times have I seen people rewrite stuff
>> that's
>> already in
>> the base class they weren't paying attention to!), this doesn't
>> negate the
>> value of protected members. Again, Templates aside, sometimes things
>> are simply correctly factored by using protected member variables in a
>> base class.
>>
>> --
>> Nick Bauman
>> Cortexity Development
>> http://www.cortexity.com/
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
--
Nick Bauman
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/6/02 1:30 AM, "James Maes" <jm...@sportingnews.com> wrote:
>
> #define ckeleton skeleton
> #define programer programmer
Ew. How about
s/ckeleton/skeleton/
s/programer/programmer/
:)
>
>
> okay, I'm done....
>
> On Sunday 06 January 2002 12:27 am, James Maes wrote:
>> Class Behavioral - Template Method
>> Intent - "Define the ckeleton of an algorithm in an operation, deferring
>> some steps to subclasses. Templates Method lets subclassess redefine
>> certain steps of an algorithm without changing the algorithm's structure."
>>
>> - James "Bored programer with a copy of Design Patterns in front of me"
>> Maes
>>
>> On Sunday 06 January 2002 12:13 am, Donnie Hale wrote:
>>> The "template method pattern" doesn't have anything to do with
>>> "templates" as in C++ or "generics" as in JDK 1.4/5. It's the name of a
>>> pattern from the "Gang of 4" Design Patterns book. I don't have my copy
>>> in front of me right now to provide the "official" motivation and
>>> application of the pattern, but, in short, it establishes a non-virtual
>>> public interface through a base class whose implementation is a
>>> "template" which can/must be overridden by derived classes.
>>>
>>> As far as protected member variables in a base class goes, Geir's last
>>> message summed it up most concisely: it violates encapsulation.
>>>
>>> While the books aren't Java-specific, the rules in Scott Meyers'
>>> "Effective C++" and "More Effective C++" are highly applicable.
>>>
>>> Donnie
>>>
>>>> -----Original Message-----
>>>> From: Nick Bauman [mailto:nick@cortexity.com]
>>>> Sent: Saturday, January 05, 2002 10:38 PM
>>>> To: velocity-user@jakarta.apache.org
>>>> Subject: RE: ResourceLoader.init() question
>>>>
>>>>
>>>> Donnie said:
>>>>
>>>> [edit]
>>>>
>>>>> If one subscribes to the Liskov substitution principal (a derived
>>>>> class should be able to be used wherever a base class is used w/o the
>>>>> user having to know which it is), then more up-front attention needs
>>>>> paid on two fronts: 1) what is the full contract of a base class? 2)
>>>>> does a derived class really meet the "is-a" test?
>>>>>
>>>>> I'm a huge fan of the template method pattern, and I think it's wider
>>>>> use in base classes would help enormously. As regards this question,
>>>>> it would help because the base class would be enforcing the state
>>>>> machine, if you will, through which its implementation progresses. It
>>>>> could then very easily pass what might otherwise be a protected
>>>>> member variable to an abstract template method for derived class use.
>>>>
>>>> Templates aside for a moment and I generally agree (because I think
>>>> they're good too), this is Java: we use interfaces to establish
>>>> contracts.
>>>> Liskov substitution principal is what the Java interface is all about.
>>>> Without interfaces, implementations end up pushing more and more
>>>> functionality up the heirarchy tree into what become abstract God
>>>> classes.
>>>> Yeech. While it's true that "nobody looks at what's in the base classes
>>>> enough" (how many times have I seen people rewrite stuff that's
>>>> already in
>>>> the base class they weren't paying attention to!), this doesn't
>>>> negate the
>>>> value of protected members. Again, Templates aside, sometimes things
>>>> are simply correctly factored by using protected member variables in a
>>>> base class.
>>>>
>>>> --
>>>> Nick Bauman
>>>> Cortexity Development
>>>> http://www.cortexity.com/
>>>>
>>>>
>>>> --
>>>> To unsubscribe, e-mail:
>>>> <ma...@jakarta.apache.org>
>>>> For additional commands, e-mail:
>>>> <ma...@jakarta.apache.org>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by James Maes <jm...@sportingnews.com>.
#define ckeleton skeleton
#define programer programmer
okay, I'm done....
On Sunday 06 January 2002 12:27 am, James Maes wrote:
> Class Behavioral - Template Method
> Intent - "Define the ckeleton of an algorithm in an operation, deferring
> some steps to subclasses. Templates Method lets subclassess redefine
> certain steps of an algorithm without changing the algorithm's structure."
>
> - James "Bored programer with a copy of Design Patterns in front of me"
> Maes
>
> On Sunday 06 January 2002 12:13 am, Donnie Hale wrote:
> > The "template method pattern" doesn't have anything to do with
> > "templates" as in C++ or "generics" as in JDK 1.4/5. It's the name of a
> > pattern from the "Gang of 4" Design Patterns book. I don't have my copy
> > in front of me right now to provide the "official" motivation and
> > application of the pattern, but, in short, it establishes a non-virtual
> > public interface through a base class whose implementation is a
> > "template" which can/must be overridden by derived classes.
> >
> > As far as protected member variables in a base class goes, Geir's last
> > message summed it up most concisely: it violates encapsulation.
> >
> > While the books aren't Java-specific, the rules in Scott Meyers'
> > "Effective C++" and "More Effective C++" are highly applicable.
> >
> > Donnie
> >
> > > -----Original Message-----
> > > From: Nick Bauman [mailto:nick@cortexity.com]
> > > Sent: Saturday, January 05, 2002 10:38 PM
> > > To: velocity-user@jakarta.apache.org
> > > Subject: RE: ResourceLoader.init() question
> > >
> > >
> > > Donnie said:
> > >
> > > [edit]
> > >
> > > > If one subscribes to the Liskov substitution principal (a derived
> > > > class should be able to be used wherever a base class is used w/o the
> > > > user having to know which it is), then more up-front attention needs
> > > > paid on two fronts: 1) what is the full contract of a base class? 2)
> > > > does a derived class really meet the "is-a" test?
> > > >
> > > > I'm a huge fan of the template method pattern, and I think it's wider
> > > > use in base classes would help enormously. As regards this question,
> > > > it would help because the base class would be enforcing the state
> > > > machine, if you will, through which its implementation progresses. It
> > > > could then very easily pass what might otherwise be a protected
> > > > member variable to an abstract template method for derived class use.
> > >
> > > Templates aside for a moment and I generally agree (because I think
> > > they're good too), this is Java: we use interfaces to establish
> > > contracts.
> > > Liskov substitution principal is what the Java interface is all about.
> > > Without interfaces, implementations end up pushing more and more
> > > functionality up the heirarchy tree into what become abstract God
> > > classes.
> > > Yeech. While it's true that "nobody looks at what's in the base classes
> > > enough" (how many times have I seen people rewrite stuff that's
> > > already in
> > > the base class they weren't paying attention to!), this doesn't
> > > negate the
> > > value of protected members. Again, Templates aside, sometimes things
> > > are simply correctly factored by using protected member variables in a
> > > base class.
> > >
> > > --
> > > Nick Bauman
> > > Cortexity Development
> > > http://www.cortexity.com/
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by James Maes <jm...@sportingnews.com>.
Class Behavioral - Template Method
Intent - "Define the ckeleton of an algorithm in an operation, deferring some
steps to subclasses. Templates Method lets subclassess redefine certain
steps of an algorithm without changing the algorithm's structure."
- James "Bored programer with a copy of Design Patterns in front of me" Maes
On Sunday 06 January 2002 12:13 am, Donnie Hale wrote:
> The "template method pattern" doesn't have anything to do with "templates"
> as in C++ or "generics" as in JDK 1.4/5. It's the name of a pattern from
> the "Gang of 4" Design Patterns book. I don't have my copy in front of me
> right now to provide the "official" motivation and application of the
> pattern, but, in short, it establishes a non-virtual public interface
> through a base class whose implementation is a "template" which can/must be
> overridden by derived classes.
>
> As far as protected member variables in a base class goes, Geir's last
> message summed it up most concisely: it violates encapsulation.
>
> While the books aren't Java-specific, the rules in Scott Meyers' "Effective
> C++" and "More Effective C++" are highly applicable.
>
> Donnie
>
> > -----Original Message-----
> > From: Nick Bauman [mailto:nick@cortexity.com]
> > Sent: Saturday, January 05, 2002 10:38 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: RE: ResourceLoader.init() question
> >
> >
> > Donnie said:
> >
> > [edit]
> >
> > > If one subscribes to the Liskov substitution principal (a derived class
> > > should be able to be used wherever a base class is used w/o the user
> > > having to know which it is), then more up-front attention needs paid on
> > > two fronts: 1) what is the full contract of a base class? 2) does a
> > > derived class really meet the "is-a" test?
> > >
> > > I'm a huge fan of the template method pattern, and I think it's wider
> > > use in base classes would help enormously. As regards this question, it
> > > would help because the base class would be enforcing the state machine,
> > > if you will, through which its implementation progresses. It could then
> > > very easily pass what might otherwise be a protected member variable to
> > > an abstract template method for derived class use.
> >
> > Templates aside for a moment and I generally agree (because I think
> > they're good too), this is Java: we use interfaces to establish
> > contracts.
> > Liskov substitution principal is what the Java interface is all about.
> > Without interfaces, implementations end up pushing more and more
> > functionality up the heirarchy tree into what become abstract God
> > classes.
> > Yeech. While it's true that "nobody looks at what's in the base classes
> > enough" (how many times have I seen people rewrite stuff that's
> > already in
> > the base class they weren't paying attention to!), this doesn't
> > negate the
> > value of protected members. Again, Templates aside, sometimes things are
> > simply correctly factored by using protected member variables in a base
> > class.
> >
> > --
> > Nick Bauman
> > Cortexity Development
> > http://www.cortexity.com/
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
--
------------------------------------
|| James Maes
|| Senior Programmer
|| jmaes@sportingnews.com
|| The Sporting News
|| www.sportingnews.com
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
The "template method pattern" doesn't have anything to do with "templates"
as in C++ or "generics" as in JDK 1.4/5. It's the name of a pattern from the
"Gang of 4" Design Patterns book. I don't have my copy in front of me right
now to provide the "official" motivation and application of the pattern,
but, in short, it establishes a non-virtual public interface through a base
class whose implementation is a "template" which can/must be overridden by
derived classes.
As far as protected member variables in a base class goes, Geir's last
message summed it up most concisely: it violates encapsulation.
While the books aren't Java-specific, the rules in Scott Meyers' "Effective
C++" and "More Effective C++" are highly applicable.
Donnie
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Saturday, January 05, 2002 10:38 PM
> To: velocity-user@jakarta.apache.org
> Subject: RE: ResourceLoader.init() question
>
>
> Donnie said:
>
> [edit]
>
> > If one subscribes to the Liskov substitution principal (a derived class
> > should be able to be used wherever a base class is used w/o the user
> > having to know which it is), then more up-front attention needs paid on
> > two fronts: 1) what is the full contract of a base class? 2) does a
> > derived class really meet the "is-a" test?
> >
> > I'm a huge fan of the template method pattern, and I think it's wider
> > use in base classes would help enormously. As regards this question, it
> > would help because the base class would be enforcing the state machine,
> > if you will, through which its implementation progresses. It could then
> > very easily pass what might otherwise be a protected member variable to
> > an abstract template method for derived class use.
>
> Templates aside for a moment and I generally agree (because I think
> they're good too), this is Java: we use interfaces to establish
> contracts.
> Liskov substitution principal is what the Java interface is all about.
> Without interfaces, implementations end up pushing more and more
> functionality up the heirarchy tree into what become abstract God
> classes.
> Yeech. While it's true that "nobody looks at what's in the base classes
> enough" (how many times have I seen people rewrite stuff that's
> already in
> the base class they weren't paying attention to!), this doesn't
> negate the
> value of protected members. Again, Templates aside, sometimes things are
> simply correctly factored by using protected member variables in a base
> class.
>
> --
> Nick Bauman
> Cortexity Development
> http://www.cortexity.com/
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Nick Bauman <ni...@cortexity.com>.
Donnie said:
[edit]
> If one subscribes to the Liskov substitution principal (a derived class
> should be able to be used wherever a base class is used w/o the user
> having to know which it is), then more up-front attention needs paid on
> two fronts: 1) what is the full contract of a base class? 2) does a
> derived class really meet the "is-a" test?
>
> I'm a huge fan of the template method pattern, and I think it's wider
> use in base classes would help enormously. As regards this question, it
> would help because the base class would be enforcing the state machine,
> if you will, through which its implementation progresses. It could then
> very easily pass what might otherwise be a protected member variable to
> an abstract template method for derived class use.
Templates aside for a moment and I generally agree (because I think
they're good too), this is Java: we use interfaces to establish contracts.
Liskov substitution principal is what the Java interface is all about.
Without interfaces, implementations end up pushing more and more
functionality up the heirarchy tree into what become abstract God classes.
Yeech. While it's true that "nobody looks at what's in the base classes
enough" (how many times have I seen people rewrite stuff that's already in
the base class they weren't paying attention to!), this doesn't negate the
value of protected members. Again, Templates aside, sometimes things are
simply correctly factored by using protected member variables in a base
class.
--
Nick Bauman
Cortexity Development
http://www.cortexity.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
See below.
Donnie
>
> Seems to be the flavor of the day in jakarta-land these days... :)
>
Well if it leads to fixing brace locations and banishment of protected
members, then it can't be all bad. :)
> >
> > I'm a huge fan of the template method pattern, and I think it's
> > wider use in
> > base classes would help enormously.
>
> ?
See my response to Nick regarding the template method pattern. If I get real
motivated, maybe I'll reimplement VelocityServlet in terms of that pattern,
as it's a perfect example of where it would be used.
>
> Good to know I got *something* right, although I will be the first to
> proudly fess up that it's not in accordance with Sun's sacred canon on the
> subject..
I hope that you weren't inferring that I thought only your brace placement
was done correctly. Not the case at all...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/5/02 10:38 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> Thanks for responding, Geir.
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Saturday, January 05, 2002 10:11 PM
>> To: velocity-user@jakarta.apache.org
>> Subject: Re: ResourceLoader.init() question
>>
>>
>> On 1/5/02 10:06 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>
>>> One more thing on this. Variables should come from one of three
>> scopes: a
>>> local variable in the current method; a parameter to the
>> current method; or
>>> a member variable of the current class.
>>
>> Assuming you are anti protected members of a base class, sure.
>
> I of course don't want to start any kind of religious war on the subject.
Seems to be the flavor of the day in jakarta-land these days... :)
> I
> find it somewhat astonishing that there's any debate left on this point, as
> this particular issue was (I'd thought) decided years and years ago.
> Certainly in the C++ literature (see Stroustrup's D&E), it's as absolute a
> rule as you're likely to ever find when it comes to class design.
>
> If one subscribes to the Liskov substitution principal (a derived class
> should be able to be used wherever a base class is used w/o the user having
> to know which it is), then more up-front attention needs paid on two fronts:
> 1) what is the full contract of a base class? 2) does a derived class really
> meet the "is-a" test?
>
> I'm a huge fan of the template method pattern, and I think it's wider use in
> base classes would help enormously.
?
> As regards this question, it would help
> because the base class would be enforcing the state machine, if you will,
> through which its implementation progresses. It could then very easily pass
> what might otherwise be a protected member variable to an abstract template
> method for derived class use.
>
>>
>>> For each of those scopes, at least
>>> in Java (no header files :), determining the type of a variable
>> is nearly
>>> instantaneous. When I see something like "rsvc.info()" in the
>> WebappLoader
>>> class, and I know it's not from one of those three scopes, I
>> then have to
>>> start figuring out where it comes from, what type it is, etc.
>>
>> I sort of agree. I will also note that this is somewhat of a matter of
>> taste (no, we aren't going to discuss coding conventions here :), and
>> perfection isn't always achieved the first go-round.
>
> I'm willing to give you the benefit of the doubt to an extent, because I can
> see from the Velocity sources that you put the braces where they belong.
> ;-o)
Good to know I got *something* right, although I will be the first to
proudly fess up that it's not in accordance with Sun's sacred canon on the
subject..
>>
>> Also, modern development tools (javadoc, for example :) really remove most
>> of the problem.
>>
>> Also, don't you have the same issue with protected methods? I
>> don't see why
>> they are different...
>
> That's getting into a grayer area, as there are those who are just as
> adamant that protecte methods serve no useful purpose. I'm not one of them,
> but I sympathize. One of my design hot-buttons is rigor, and I don't like
> things as loosey-goosey as protected members.
Yes, I got that :)
I agree with your sentiments about rigor, and indeed protected members can
make a mess - it almost violates encapsulation, I guess. It's easy to fix
in our case if it would be a problem...
>
>>
>>>
>>> That of course doesn't include static (hopefully final)
>> variables such as
>>> those in a typesafe enum class; but those are prefixed by their
>> classname
>>> anyway.
>>
>> Not necessarily. I can always use a static final in a derived class w/o
>> the baseclass prefix, right?
>
> True. My main point w.r.t. scope was, of course, that code inspection,
> maintenance programming, etc. should be made as easy as possible; and having
> to hunt all over the world or bring up your web browser to see javadocs or
> whatever just gets in the way.
>
> One man's opinion...
>
> Donnie
>
>
>>
>>
>>> Donnie
>>>
>>>
>>>> -----Original Message-----
>>>> From: Donnie Hale [mailto:donnie@haleonline.net]
>>>> Sent: Saturday, January 05, 2002 10:01 PM
>>>> To: Velocity Users List
>>>> Subject: RE: ResourceLoader.init() question
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>>>>> Sent: Saturday, January 05, 2002 9:30 PM
>>>>> To: velocity-user@jakarta.apache.org
>>>>> Subject: Re: ResourceLoader.init() question
>>>>>
>>>>>
>>>>> On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> Hopefully this is an easy one.
>>>>>>
>>>>>> I'm working with the up-to-date dev builds of Velocity as well as the
>>>>>> recently-posted velocity-tools stuff. I see that
>>>>> ResourceLoader.init() is
>>>>>> passed an ExtendedProperties parameter named "configuration".
>>>>> Where do that
>>>>>> object's properties come from? What properties can I expect to
>>>>> be in it? I
>>>>>> ask because the view.Webapploader class' init() method is using the
>>>>>> ResourceLoader.rsvc (since it's derived from ResourceLoader)
>> to get an
>>>>>> application attribute set in VelocityViewServlet; and I was naturally
>>>>>> curious if that could not be passed in that "configuration"
>> parameter.
>>>>>
>>>>> That init is constructed in RuntimeInstance
>>>>>
>>>>>>
>>>>>> And, just to be provocative, may I once again express my utter
>>>>> disdain for
>>>>>> protected member variables like ResourceLoader.rsvc. <g,d,&r>
>>>>>>
>>>>>
>>>>> Whu?
>>>>
>>>> I'm assuming you meant "why?".
>>>>
>>>> Primarily it's due to the "fragile base class syndrome".
>> Derived classes
>>>> which depend on these items from base classes, and by its nature
>>>> a protected
>>>> member variable is not a rigorous contract b/w base and
>> derived class, are
>>>> at the mercy of changes in the base class. Correspondingly,
>> conscientious
>>>> base class developers are hamstrung in their attempts to refactor
>>>> or enhance
>>>> the base class when they know that derived classes will be
>> broken if they
>>>> eliminate or change the type of a member variable.
>>>>
>>>> If base class developers are creating their class with the
>>>> expectation that
>>>> a derived class will need a certain service, formalize that
>>>> expectation even
>>>> if it's something as simple as a protected method returning the type in
>>>> question. Then the base class developer is free to change
>> things at will,
>>>> providing adaptor functionality to continue fulfilling that contract as
>>>> necessary.
>>>>
>>>> There's also issues when the base class needs to add side-effect
>>>> behavior to
>>>> accessing one of its members, e.g. synchronization, logging, reference
>>>> counting, etc.
>>>>
>>>> FWIW...
>>>>
>>>> Donnie
>>>>
>>>>
>>>>>
>>>>> --
>>>>> Geir Magnusson Jr.
>>>> geirm@optonline.net
>>>>> System and Software Consulting
>>>>> "Now what do we do?"
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe, e-mail:
>>>>> <ma...@jakarta.apache.org>
>>>>> For additional commands, e-mail:
>>>>> <ma...@jakarta.apache.org>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> Be a giant. Take giant steps. Do giant things...
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
Thanks for responding, Geir.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Saturday, January 05, 2002 10:11 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: ResourceLoader.init() question
>
>
> On 1/5/02 10:06 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>
> > One more thing on this. Variables should come from one of three
> scopes: a
> > local variable in the current method; a parameter to the
> current method; or
> > a member variable of the current class.
>
> Assuming you are anti protected members of a base class, sure.
I of course don't want to start any kind of religious war on the subject. I
find it somewhat astonishing that there's any debate left on this point, as
this particular issue was (I'd thought) decided years and years ago.
Certainly in the C++ literature (see Stroustrup's D&E), it's as absolute a
rule as you're likely to ever find when it comes to class design.
If one subscribes to the Liskov substitution principal (a derived class
should be able to be used wherever a base class is used w/o the user having
to know which it is), then more up-front attention needs paid on two fronts:
1) what is the full contract of a base class? 2) does a derived class really
meet the "is-a" test?
I'm a huge fan of the template method pattern, and I think it's wider use in
base classes would help enormously. As regards this question, it would help
because the base class would be enforcing the state machine, if you will,
through which its implementation progresses. It could then very easily pass
what might otherwise be a protected member variable to an abstract template
method for derived class use.
>
> > For each of those scopes, at least
> > in Java (no header files :), determining the type of a variable
> is nearly
> > instantaneous. When I see something like "rsvc.info()" in the
> WebappLoader
> > class, and I know it's not from one of those three scopes, I
> then have to
> > start figuring out where it comes from, what type it is, etc.
>
> I sort of agree. I will also note that this is somewhat of a matter of
> taste (no, we aren't going to discuss coding conventions here :), and
> perfection isn't always achieved the first go-round.
I'm willing to give you the benefit of the doubt to an extent, because I can
see from the Velocity sources that you put the braces where they belong.
;-o)
>
> Also, modern development tools (javadoc, for example :) really remove most
> of the problem.
>
> Also, don't you have the same issue with protected methods? I
> don't see why
> they are different...
That's getting into a grayer area, as there are those who are just as
adamant that protecte methods serve no useful purpose. I'm not one of them,
but I sympathize. One of my design hot-buttons is rigor, and I don't like
things as loosey-goosey as protected members.
>
> >
> > That of course doesn't include static (hopefully final)
> variables such as
> > those in a typesafe enum class; but those are prefixed by their
> classname
> > anyway.
>
> Not necessarily. I can always use a static final in a derived class w/o
> the baseclass prefix, right?
True. My main point w.r.t. scope was, of course, that code inspection,
maintenance programming, etc. should be made as easy as possible; and having
to hunt all over the world or bring up your web browser to see javadocs or
whatever just gets in the way.
One man's opinion...
Donnie
>
>
> > Donnie
> >
> >
> >> -----Original Message-----
> >> From: Donnie Hale [mailto:donnie@haleonline.net]
> >> Sent: Saturday, January 05, 2002 10:01 PM
> >> To: Velocity Users List
> >> Subject: RE: ResourceLoader.init() question
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> >>> Sent: Saturday, January 05, 2002 9:30 PM
> >>> To: velocity-user@jakarta.apache.org
> >>> Subject: Re: ResourceLoader.init() question
> >>>
> >>>
> >>> On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> Hopefully this is an easy one.
> >>>>
> >>>> I'm working with the up-to-date dev builds of Velocity as well as the
> >>>> recently-posted velocity-tools stuff. I see that
> >>> ResourceLoader.init() is
> >>>> passed an ExtendedProperties parameter named "configuration".
> >>> Where do that
> >>>> object's properties come from? What properties can I expect to
> >>> be in it? I
> >>>> ask because the view.Webapploader class' init() method is using the
> >>>> ResourceLoader.rsvc (since it's derived from ResourceLoader)
> to get an
> >>>> application attribute set in VelocityViewServlet; and I was naturally
> >>>> curious if that could not be passed in that "configuration"
> parameter.
> >>>
> >>> That init is constructed in RuntimeInstance
> >>>
> >>>>
> >>>> And, just to be provocative, may I once again express my utter
> >>> disdain for
> >>>> protected member variables like ResourceLoader.rsvc. <g,d,&r>
> >>>>
> >>>
> >>> Whu?
> >>
> >> I'm assuming you meant "why?".
> >>
> >> Primarily it's due to the "fragile base class syndrome".
> Derived classes
> >> which depend on these items from base classes, and by its nature
> >> a protected
> >> member variable is not a rigorous contract b/w base and
> derived class, are
> >> at the mercy of changes in the base class. Correspondingly,
> conscientious
> >> base class developers are hamstrung in their attempts to refactor
> >> or enhance
> >> the base class when they know that derived classes will be
> broken if they
> >> eliminate or change the type of a member variable.
> >>
> >> If base class developers are creating their class with the
> >> expectation that
> >> a derived class will need a certain service, formalize that
> >> expectation even
> >> if it's something as simple as a protected method returning the type in
> >> question. Then the base class developer is free to change
> things at will,
> >> providing adaptor functionality to continue fulfilling that contract as
> >> necessary.
> >>
> >> There's also issues when the base class needs to add side-effect
> >> behavior to
> >> accessing one of its members, e.g. synchronization, logging, reference
> >> counting, etc.
> >>
> >> FWIW...
> >>
> >> Donnie
> >>
> >>
> >>>
> >>> --
> >>> Geir Magnusson Jr.
> >> geirm@optonline.net
> >>> System and Software Consulting
> >>> "Now what do we do?"
> >>>
> >>>
> >>> --
> >>> To unsubscribe, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>> For additional commands, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>>
> >>>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Be a giant. Take giant steps. Do giant things...
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/5/02 10:06 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> One more thing on this. Variables should come from one of three scopes: a
> local variable in the current method; a parameter to the current method; or
> a member variable of the current class.
Assuming you are anti protected members of a base class, sure.
> For each of those scopes, at least
> in Java (no header files :), determining the type of a variable is nearly
> instantaneous. When I see something like "rsvc.info()" in the WebappLoader
> class, and I know it's not from one of those three scopes, I then have to
> start figuring out where it comes from, what type it is, etc.
I sort of agree. I will also note that this is somewhat of a matter of
taste (no, we aren't going to discuss coding conventions here :), and
perfection isn't always achieved the first go-round.
Also, modern development tools (javadoc, for example :) really remove most
of the problem.
Also, don't you have the same issue with protected methods? I don't see why
they are different...
>
> That of course doesn't include static (hopefully final) variables such as
> those in a typesafe enum class; but those are prefixed by their classname
> anyway.
Not necessarily. I can always use a static final in a derived class w/o
the baseclass prefix, right?
> Donnie
>
>
>> -----Original Message-----
>> From: Donnie Hale [mailto:donnie@haleonline.net]
>> Sent: Saturday, January 05, 2002 10:01 PM
>> To: Velocity Users List
>> Subject: RE: ResourceLoader.init() question
>>
>>
>>
>>> -----Original Message-----
>>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>>> Sent: Saturday, January 05, 2002 9:30 PM
>>> To: velocity-user@jakarta.apache.org
>>> Subject: Re: ResourceLoader.init() question
>>>
>>>
>>> On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>>
>>>> Folks,
>>>>
>>>> Hopefully this is an easy one.
>>>>
>>>> I'm working with the up-to-date dev builds of Velocity as well as the
>>>> recently-posted velocity-tools stuff. I see that
>>> ResourceLoader.init() is
>>>> passed an ExtendedProperties parameter named "configuration".
>>> Where do that
>>>> object's properties come from? What properties can I expect to
>>> be in it? I
>>>> ask because the view.Webapploader class' init() method is using the
>>>> ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
>>>> application attribute set in VelocityViewServlet; and I was naturally
>>>> curious if that could not be passed in that "configuration" parameter.
>>>
>>> That init is constructed in RuntimeInstance
>>>
>>>>
>>>> And, just to be provocative, may I once again express my utter
>>> disdain for
>>>> protected member variables like ResourceLoader.rsvc. <g,d,&r>
>>>>
>>>
>>> Whu?
>>
>> I'm assuming you meant "why?".
>>
>> Primarily it's due to the "fragile base class syndrome". Derived classes
>> which depend on these items from base classes, and by its nature
>> a protected
>> member variable is not a rigorous contract b/w base and derived class, are
>> at the mercy of changes in the base class. Correspondingly, conscientious
>> base class developers are hamstrung in their attempts to refactor
>> or enhance
>> the base class when they know that derived classes will be broken if they
>> eliminate or change the type of a member variable.
>>
>> If base class developers are creating their class with the
>> expectation that
>> a derived class will need a certain service, formalize that
>> expectation even
>> if it's something as simple as a protected method returning the type in
>> question. Then the base class developer is free to change things at will,
>> providing adaptor functionality to continue fulfilling that contract as
>> necessary.
>>
>> There's also issues when the base class needs to add side-effect
>> behavior to
>> accessing one of its members, e.g. synchronization, logging, reference
>> counting, etc.
>>
>> FWIW...
>>
>> Donnie
>>
>>
>>>
>>> --
>>> Geir Magnusson Jr.
>> geirm@optonline.net
>>> System and Software Consulting
>>> "Now what do we do?"
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>>
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
One more thing on this. Variables should come from one of three scopes: a
local variable in the current method; a parameter to the current method; or
a member variable of the current class. For each of those scopes, at least
in Java (no header files :), determining the type of a variable is nearly
instantaneous. When I see something like "rsvc.info()" in the WebappLoader
class, and I know it's not from one of those three scopes, I then have to
start figuring out where it comes from, what type it is, etc.
That of course doesn't include static (hopefully final) variables such as
those in a typesafe enum class; but those are prefixed by their classname
anyway.
Donnie
> -----Original Message-----
> From: Donnie Hale [mailto:donnie@haleonline.net]
> Sent: Saturday, January 05, 2002 10:01 PM
> To: Velocity Users List
> Subject: RE: ResourceLoader.init() question
>
>
>
> > -----Original Message-----
> > From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> > Sent: Saturday, January 05, 2002 9:30 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: Re: ResourceLoader.init() question
> >
> >
> > On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> >
> > > Folks,
> > >
> > > Hopefully this is an easy one.
> > >
> > > I'm working with the up-to-date dev builds of Velocity as well as the
> > > recently-posted velocity-tools stuff. I see that
> > ResourceLoader.init() is
> > > passed an ExtendedProperties parameter named "configuration".
> > Where do that
> > > object's properties come from? What properties can I expect to
> > be in it? I
> > > ask because the view.Webapploader class' init() method is using the
> > > ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
> > > application attribute set in VelocityViewServlet; and I was naturally
> > > curious if that could not be passed in that "configuration" parameter.
> >
> > That init is constructed in RuntimeInstance
> >
> > >
> > > And, just to be provocative, may I once again express my utter
> > disdain for
> > > protected member variables like ResourceLoader.rsvc. <g,d,&r>
> > >
> >
> > Whu?
>
> I'm assuming you meant "why?".
>
> Primarily it's due to the "fragile base class syndrome". Derived classes
> which depend on these items from base classes, and by its nature
> a protected
> member variable is not a rigorous contract b/w base and derived class, are
> at the mercy of changes in the base class. Correspondingly, conscientious
> base class developers are hamstrung in their attempts to refactor
> or enhance
> the base class when they know that derived classes will be broken if they
> eliminate or change the type of a member variable.
>
> If base class developers are creating their class with the
> expectation that
> a derived class will need a certain service, formalize that
> expectation even
> if it's something as simple as a protected method returning the type in
> question. Then the base class developer is free to change things at will,
> providing adaptor functionality to continue fulfilling that contract as
> necessary.
>
> There's also issues when the base class needs to add side-effect
> behavior to
> accessing one of its members, e.g. synchronization, logging, reference
> counting, etc.
>
> FWIW...
>
> Donnie
>
>
> >
> > --
> > Geir Magnusson Jr.
> geirm@optonline.net
> > System and Software Consulting
> > "Now what do we do?"
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ResourceLoader.init() question
Posted by Donnie Hale <do...@haleonline.net>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Saturday, January 05, 2002 9:30 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: ResourceLoader.init() question
>
>
> On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>
> > Folks,
> >
> > Hopefully this is an easy one.
> >
> > I'm working with the up-to-date dev builds of Velocity as well as the
> > recently-posted velocity-tools stuff. I see that
> ResourceLoader.init() is
> > passed an ExtendedProperties parameter named "configuration".
> Where do that
> > object's properties come from? What properties can I expect to
> be in it? I
> > ask because the view.Webapploader class' init() method is using the
> > ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
> > application attribute set in VelocityViewServlet; and I was naturally
> > curious if that could not be passed in that "configuration" parameter.
>
> That init is constructed in RuntimeInstance
>
> >
> > And, just to be provocative, may I once again express my utter
> disdain for
> > protected member variables like ResourceLoader.rsvc. <g,d,&r>
> >
>
> Whu?
I'm assuming you meant "why?".
Primarily it's due to the "fragile base class syndrome". Derived classes
which depend on these items from base classes, and by its nature a protected
member variable is not a rigorous contract b/w base and derived class, are
at the mercy of changes in the base class. Correspondingly, conscientious
base class developers are hamstrung in their attempts to refactor or enhance
the base class when they know that derived classes will be broken if they
eliminate or change the type of a member variable.
If base class developers are creating their class with the expectation that
a derived class will need a certain service, formalize that expectation even
if it's something as simple as a protected method returning the type in
question. Then the base class developer is free to change things at will,
providing adaptor functionality to continue fulfilling that contract as
necessary.
There's also issues when the base class needs to add side-effect behavior to
accessing one of its members, e.g. synchronization, logging, reference
counting, etc.
FWIW...
Donnie
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "Now what do we do?"
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ResourceLoader.init() question
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/5/02 9:22 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> Folks,
>
> Hopefully this is an easy one.
>
> I'm working with the up-to-date dev builds of Velocity as well as the
> recently-posted velocity-tools stuff. I see that ResourceLoader.init() is
> passed an ExtendedProperties parameter named "configuration". Where do that
> object's properties come from? What properties can I expect to be in it? I
> ask because the view.Webapploader class' init() method is using the
> ResourceLoader.rsvc (since it's derived from ResourceLoader) to get an
> application attribute set in VelocityViewServlet; and I was naturally
> curious if that could not be passed in that "configuration" parameter.
That init is constructed in RuntimeInstance
>
> And, just to be provocative, may I once again express my utter disdain for
> protected member variables like ResourceLoader.rsvc. <g,d,&r>
>
Whu?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>