John Johnson wrote:


>> > 
>> > Would a Factory pattern work better in this case? I.e. have a base
>> > class, then derive the two different classes from that. Use a Factory
>> > to give you the instance you ask for. If you call
>> > Factory.instance(SOME_NAME) would return a SomeName instance, whereas
>> > Factory.instance(SOME_OTHER_NAME) would return a SomeOtherName
>> > instance. SomeName and SomeOtherName would both be subclasses of
>> > BaseClass.
>> 
>> It would indeed work, but I was hoping to be able to keep it down to one
>> object.  Here was something else I had tried:
>> 
>> class Hider
> ..
>> >> method 1
>> 
>> 
>> While this works as expected, it doesn't really hide method2.  It just
>> doesn't execute the specified code if @vartype2 if false.  Not quite what
>> I was hoping for, but it gives a similar effect.
> 
> You must also consider the maintainability of the code. I'm sure you
> have a good reason for wanting it to be one class, but does that
> outweigh being able to understand how it works when you come back to it
> next year? Or next month, in my case :-)

I understand what you mean.  I think I was trying too hard to conserve
memory/space.  I guess I thought that if I had one class that behaved in
such a way, it might be easier to maintain, but I can see where if I run
into getting a lot of methods in there, that determining which ones run for
one instance and which ones run for another would get kind of tough.

Perhaps there are other ideas for what I want I'm trying to accomplish in
the long run.  I wanted a simple way to have two (or more) completely
unrelated classes to send messages back and forth without having to even
know about each other.  I wanted something that would interfere the least
with each class.  The reason why I wanted to have the private methods to be
able to change on assignment was because I wanted some classes to only send
messages, some to only receive messages, and others that could do both. 
For now, I finally settled on this little bit of code:

module Status_messenger
    class Status
        def Status.set(val)
            @@status = val
        end
        
        def Status.get
            @@status
        end
    end

    def status=(val)
        Status.set val
    end

    def status
        Status.get
    end
end

This way, all I have to do is "include Status_messenger" in a class, and now
it can communicate with any other classes that have been "enabled" as well. 
I settled on a seperate class inside the module because I didn't want extra
class attributes to be created within each class.  I wanted it to interfere
as little as possible with everything else.  Unfortunately it doesn't allow
for some classes to send-only or receive-only, but for my small purpose,
it's not an issue right now.  Perhaps I'll work on it further one day.

Bah, I'm rambling...  sorry.  I'll go now.

Thanks again for your help and suggestions!

Jeremy