Some nits I need to pick with your code:

1. In

   Package main:
   [download]

   You have a syntax error. Change the ":" to a ";" and you have it made.
2. Next, to get the effect you are after

   my $foo = HeckIfIKnow::new(
     -opt1 => '3456',
     -opt2 => '1234'
   );
   [download]

   becomes

   my $foo = new HeckIfIKnow(
     -opt1 => '3456',
     -opt2 => '1234'
   );
   [download]

$VAR1 = bless( {
                 '3456' => '-opt2',
                 '1234' => undef
               }, '-opt1' );
[download]

$VAR1 = bless( {
                 '-opt2' => '1234',
                 '-opt1' => '3456'
               }, 'HeckIfIKnow' );
[download]

I'll cut off the people who will tell you, don't use new, since if you have a function called new in your main:: space, it'll break your program.

BUT, tell me.. you have a function that's called add, it adds two things, right? You have a function called, parseString, it parses strings, right?

Why would you have a main:: funciton called new? New what? New time of day? New cheese? A function called new is badly named. :P

Update: See this node for more details on ->new vs new and someone actually having the problem.


Play that funky music white boy..

I'll cut off the people who will tell you, don't use new, since if you have a function called new in your main:: space, it'll break your program.

Uh, no. Although there is no rule that OO constructors be called "new" it's a pretty standard convention. Some modules (notably DBI) use an alternative constructor name, but it certainly does NOT break anything if you have a subroutine named "new" in package main.

Why would you have a funciton called new? New what? New time of day? New cheese?

It's a constructor. It makes a new object. That's why it's called new.

As for the original question, I'm rather fond of Class::MethodMaker. Works for me, though YMMV.

Gary Blackburn
Trained Killer

To address the OP's question ... there are a few commonly-used classes (Class::MethodMaker and Class::Struct) that I would examine, if I were you. Personally, I found the exercise of creating my own OO-base class to be both fun and edifying.

As for what's wrong ... I can't say this with certainty, but it looks like you're using classes as a way to created HashesThatCanDoStuff. It's still primarily a data structure, just jazzed up. Now, that's fine and all, but it's not OO. OO is three things (q.v. http://c2.com/cgi/wiki?ObjectOriented for more info):

1. Encapsulation (You can't poke inside the Foo)
2. Inheritance (You can make a Bar that is-a Foo)
3. Polymorphism (A method of Foo will do different things depending on the calling context)

While Perl's OO gives you 2 & 3 without you doing anything, HashesThatCanDoStuff don't have Encapsulation. (In fact, pure data-hiding is non-trivial in Perl, but that's another story.)

You're right, it's not full blown OO -- and that is a fault with my shortened constructor. I realized this last night when I realized my shortened constructors had pretty much lost that loving feeling (i.e. probably made inheritance about useless). Any suggestions about how to make HashesThatCanDoStuff a little more flexible?

Aside: I'm not really going for HashesThatCanDoStuff at all, I'm after named parameters, and the data structures would have been, most likely, used to implement Composites via named parameters. After all, a hash is a hash, but what you put in it makes it special :)

What do you mean by "named parameters"? "Composites"? "named parameters", to me, are a way of passing information to a function. It doesn't have much to do with OO, specifically.

I would look at the problem differently.

• What system are you trying to model?
• What are the things that do stuff in that system?
• What is the minimal set of actions that each thing needs to be able to do?
• How will those things interact?

Once you know those things, then you can start working out what attributes each class needs to have in order to fulfill its requirements. Then, and only then, can you figure out where that information needs to come from. You may find out that most of it shouldn't come from the client at all!

Now, to answer the question "How do I pass attribute/value pairs to a constructor?" ... your very short constructor is actually the canonical (if non-resilient) way of doing it. *shrugs* Personally, I'd never use that outside of golf, but that's just me. There's CPAN code you use every day that uses that (or similarly terse) constructs. Heck, CGI doesn't even use strict!

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Your ref construction is the one he disliked at ref($proto) - just say no!. (Further explanation available at A Cat's eye view of OO.) Unless you really think that you will be using new as a clone() method, you can drop that one. Furthermore, while you are at it, the usual way that new will be called is with the package name (aka class) as the first argument. Calling it $obj is misleading at best. Furthermore if you have gone to the work of creating a hash, why dereference it and build another to take a reference to that? You had a perfectly good hash.

With those changes your code turns into:

package HeckIfIKnow;

sub new {
   my ($class, %opts) = @_;
   return bless(\%opts, $class);
}
[download]

package main;

my $foo = HeckIfIKnow->new(
   opt1 => '3456',
   opt2 => '1234',
);
[download]

Thanks, good input. This was all hand typed with a small font, so some of the typos were just that... but I'll take your advice on not needing a clone() and the hash efficiency. You are probably right about needing to do it by hand for a while first too. I guess I was just getting excited about wanting to play with my new toys. Thanks!

I'm very fond of Class::MakeMethods. It starts simple, and grows to whatever level of complexity you can handle.

qq