"filtered view" upon lists?

[Wildemar Wildenburger]

Steve Holden wrote:
 >> I think SQL views are the direct analog.
 >>
 > I don't think they are. If you add a non-conforming row to a SQL view 
it doesn't appear int he view. If you modify a row in an updateable view 
so it no longer confirms with the view's conditions it disappears from 
the view.

Me and my wording again: I typed 'direct analog' but meant 'somewhat 
analog'.

 > Also you don't say whether changes to l are supposed to be reflected 
in f in the same way that changes to f are reflected in l.

Right. Yes, the synchronicity (a word?) is meant to be in both directions.

 > It might be better if you were to explain your use case: what is this 
beast supposed to be for?

I have a database of interconnected objects. Each object has a list 
tuples; these tuples hold references to other objects and details about 
the type of connection.
The 'views' I am imagining are sub-lists of this one list, based on the 
connection types. Order is important here, that's why I'm not using sets.
BTW: I have gone the way of nested lists before and found it too rigid 
and complicated to use.


 >> A bit clearer now?
 >>
 >Hardly at all. Frankly it doesn't seem as though you really know what 
 > the specifications are yourself, so you can hardly expect us to 
divine > them by use of our psychic powers. Besides which, psychic 
powers cost > extra ;-)

Right again. I'm not sure what I want yet as I'm still exploring ideas. 
If something /like/ the above had existed (which by now I'm gathering is 
not the case) I'd just adapted my ideas to the specs given.


 > So give us that use case so we get a bit more insight into why you 
even see the need for such a thing and how you want it ti behave. Or is 
all this just theoretical?

No no, its very much real. Just not as fleshed out as it might be --- 
I'm sort of an explorative coder; I usually don't know how something is 
going to work until it works.

Thx for the effort :)
wildemar