Re: Ensuring uniqueness of an object at creation time

Hi Brian,

Thank you very much for replying.

On Sun, Feb 27, 2011 at 5:14 AM, Brian Candler <[e-mail]> wrote:
>
> Abinoam Jr. wrote in post #984123:
> > I found my way through overriding the Person.new method.
> > (Thanks "The Ruby Programming Language" book).
> > So that the new instance is not even allocated if there's already one
> > with
> > the same name.
>
> There's no need to do that. You could just raise an exception from
> within the initialize method.

Person#initialize is called by Person.new
The Person.allocate is called _before_ Person#initialize.

So, if I raise an exception at initialize point the object was already
allocated.

> > The logic behind the uniqueness of the instances is hold by the class
> > itself, not by the (running) code.
> > This is desirable for me in this specific set because I'm parsing an xml
> > file with tags in a recursive manner.
>
> I think it's a poor design choice to enforce uniqueness within the
> class, because it limits the usefulness of your Person class - you could
> not have two XML parsers parsing two separate documents, for example, or
> send and receive Person instances using DRb.
>
> I think it would be better to have a 'person collection' object which
> enforces the uniqueness. You create a new person, and get an error if
> you try to add it into the collection where one already exists.
>
> This is the same sort of model as you get with SQL uniqueness
> constraints within a table, of course.
>
> Regards,
>
> Brian.

I think I was not clear enough. (I tried to simplify it, and ended
OVERsimplifying it).

Look at this xml snippet.

<messages>
    <message>PREPARE_A</message>
    <message>COMPLETE_A</message>

    <message>PREPARE_B</message>
    <message>COMPLETE_B</message>

    <message>PREPARE_C</message>
    <message>COMPLETE_C</message>
</messages>

After declaring all those messages, I just want to use them in my
rule/action table.

<rule id="active_prepare_b">
    <pre>
         <current_state>active</current_state>
    </pre>
    <post>
        <send_message>PREPARE_B</send_message>
        <next_state>completing</next_state>
    </post>
</rule>

Look at the <send_message>PREPARE_B</send_message>
This "PREPARE_B" message is the same of the previously declared one.
I'm just "using" it.
In this specific case of <message> its "uniqueness" is based on message text.
(There's other classes that has its uniqueness based on something different)
"If it smells like dog, it should be a dog" (Or "THAT specific" dog).
If it's a message and has the same text, it should be the SAME message
(not a new one).

So, I don't want to raise an exception, I just want to return the
existing object without even allocating a new one.

This kind of behavior makes me able to design my parser in a
"generic"/"agnostic" manner.
I just have to have a 'table' mapping xml tags to classes.
The parser just get the tag, see what class should be instantiated,
and calls the <class>.new and iterate to the next tag.
It's up to the class all the logic to ensure its uniqueness.

But, I'm feeling I'm forgetting something.

What do you think?

a = :prepare_b
b = :prepare_b

With Symbol, if it has the same value, it's the SAME Symbol, not different ones.

a = "prepare_b"
b = "prepare_b"

With String, even if they have the same value, they are different objects.

I would like to resemble/extend this kind of behaviour to more generic objects.

Thank you again,
Abinoam Jr.