problem with circular references in OO

[rapataa]

hi,

I have a few objects that won't work together : user, task & tasks.

The object "tasks" contains the "task" objects of 1 "user".
A User has a tasklist eg "tasks" (which contains task objects)
And one task is assigned to a user.

So, in theory you het this:
tasks[1].user.tasks.[1].user.tasks[1].user.tasks[1].user. ...

There must be a way possible to 'stop the loop'

thankee :)

[Cor Ligthert]

Rapataa,

I do not see the problem.

I understand that every user object has a property "tasks" which is a
collection from "tasks".

In the "task" object you have a property wich is a collection from users
who do that "task"

The task can never be a subclass from users, as that is what you want to do,
because there is not a real fysical relation between those two.

To give another example
A room is a part of a building, so that has a relation.
A pencil on a desk has only a temporaly relation with that desk.

I hope this helps.

Cor

[Adam]

I don't see this as a problem.

Is this not like the a real world example (ish) of two Brothers. Where
a brothers.Brother.Brother... etc.

Adam

[RCS]

I agree with these guys.

If you have this sort of setup in a treeview for example, the worst that
will happen is some silly user will go down like 4 iterations and realize it
will keep repeating - and that's it, no harm done.

I did have an app that had this setup (and had a treeview) and what I did
was whenever you went to a known level (like "person", or "task"), instead,
I would automagically open up the right part of the treeview and make that
selected, in other words:

Toplevel
--Users
----Doe, John
--------Tasks for John Doe
------------Task 1 (this shows the same thing as TopLevel\Tasks\Task 1)
------------Task 2
------------Task 3
--Tasks
----Task 1 (click on a user at this level auto-redirects you to
TopLevel\Users\Doe, John)
----Task 2
----Task 3

In the above example, if you saw that Tasks for John Doe\Task 1 has a link
or whatever to John Doe again, don't open another branch below it, instead,
re-select TopLevel\Users\Doe, John.

So in essence, you sort of "get" what they are trying to do and keep the
tree pruned back as far as you can - just for usabilities sake. But
technically, there isn't anything wrong with what you are doing, the only
issue is if you want to make it a little more managable for your users.
"rapataa" <[e-mail]> wrote in message
news:a7**************************@msgid.xenosite.n et...

hi,

I have a few objects that won't work together : user, task & tasks.

The object "tasks" contains the "task" objects of 1 "user".
A User has a tasklist eg "tasks" (which contains task objects)
And one task is assigned to a user.

So, in theory you het this:
tasks[1].user.tasks.[1].user.tasks[1].user.tasks[1].user. ...

There must be a way possible to 'stop the loop'

thankee :)

[Nick Malik [Microsoft]]

Just to add to these answers, the XmlNode object in the framework has the
ability to refer to Parent and Child nodes, and can produce this same
effect. Drill down in the debugger some time. It's fun to loop back on
yourself...

I, too, see nothing wrong with it.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"rapataa" <[e-mail]> wrote in message
news:a7**************************@msgid.xenosite.n et...

hi,

I have a few objects that won't work together : user, task & tasks.

The object "tasks" contains the "task" objects of 1 "user".
A User has a tasklist eg "tasks" (which contains task objects)
And one task is assigned to a user.

So, in theory you het this:
tasks[1].user.tasks.[1].user.tasks[1].user.tasks[1].user. ...

There must be a way possible to 'stop the loop'

thankee :)