In talking with people, I'm looking at extending my Hash::Merge class to include OOP abilities. Certainly not a huge problem, at least from the standpoint of creating a Factory-like object similar to CGI.pm which basically gives a way to handle operations with some degree of specification, as opposed to being a data-storage object.

However, in this case, it also seems worthwhile to develop a tied hash variable such that one can continually merge hashes into the tied hash, eg: my $tied_hash = ...; $tied_hash->merge( %new_hash ). (and for those reading and wondering about a mix of hash and object, see Object and tied hash all at once?). Now, I would think the best way to do this functionality is to create the subclass inside this class *preferably* in the same file only because the main Hash::Merge class would have a Factory method to generate an instance of this tied hash:

my $tied_hash = Hash::Merge::create_tied_hash( %defaults );
as opposed to:
my $tied_hash = \tie( %defaults, "Hash::Merge::Tied" );
It's not that I'm tried to hide this tied class, but I feel that the factory method is more intuitive towards my module, since Hash::Merge functions will have to be used if you are only on planning on using the tied class. Placing this subclass in the same file of course will prevent someone from 'use'ing it, from my understanding, since use is looking at the file structure and not inside the files.

However, from an openness standpoint, it's probably better to have this tied as a separate file. Nothing will break because of that, but again, to me, it doesn't seem 'right', as a user can directly create this tied variable without using the Factory method of the Hash::Merge class. But again, there is nothing *special* about the Factory method that cannot be moved into the new method of the tied class.

So is it generally bad form to try to insulate the users from subclasses that they shouldn't know too much of the specifics of, or is it better to have as open an interface as possible for this?

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
Re: Use of embedded classes
by dragonchild (Archbishop) on Nov 06, 2001 at 20:42 UTC
    My vote is open interfaces, as much as possible. All you gain by bundling the two classes in one file is to unnecessarily prevent a user from doing something.

    Maybe I think your tied hash is the best thing in the world, but want to improve it a little? Maybe I think that both are great, but want to extend Hash::Merge in a way that requires me to extend the base tied hash? It is easier for me to inherit from two paired classes than it is to rewrite the file.

    You'll be bundling them, so people who don't want to know don't have to. People who do can easily use it.

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

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.