SPUG: Hashes and subroutines

[Croote, Rick]

> -----Original Message-----
> From: spug-list-bounces+rick.croote=philips.com at pm.org [mailto:spug-
> list-bounces+rick.croote=philips.com at pm.org] On Behalf Of Christopher
> Howard
> Sent: 2009 Jan 07 11:37 AM
> To: Bill Warner
> Cc: Seattle Perl Users Group
> Subject: Re: SPUG: Hashes and subroutines
>
> On Mon, 5 Jan 2009, Bill Warner wrote:
>
> > I love Higher Order Perl, and I have nothing against this technique,
> > but chances are it's going to resemble a class, or a system of
> > classes, before you know it. Have you thought about the problems in
> terms of an object model? Then you can just  as easily write 'no strict
> "refs"; $o->$method(@args)' .
> >
> > Thanks,
> >
> >  b
> >
> >
>
> I'm not entirely against object oriented programming, but I generally
> try to avoid it until I see a very clear need for it. E.g., a need for
> multiple instantiations of an object, or a need for inheritance in a
> class hierarchy.
>
> I'm inclined to see a big difference between maintaining separate
> namespaces, and real object oriented programming.
>
> Anyone else feel the same way?
>
> --
> Christopher Howard
> http://indicium.us

Totally disagree.  I use namespaces only for classes, or the temporary extending of an existing class.

In the group I work with all modules are created in object oriented fashion, without exception.  It is just too easy to not do it.  Further, to wait until there is a clear need is often too late, with too much investment in what "is" or too high of a risk for change.  I tell all developers that I work with to never assume that an object will never be used elsewhere, in fact, the opposite, assume it will be used, but do not over develop for the current needs, only implement what is currently needed.  This has reaped great benefits for our group, allowing us to create enough business infrastructure that allows for even faster development on projects that were never thought of at the time the infrastructure was put into place.

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.