What is actually in a temp-table when the field is a Progres

It must be the reference. Just place two references to the same object

in two records in different temp tables to try out.

That's actually also the case where it makes a difference if you store

the same object twice or two references to the same object (when you

modify a property on the first reference and see it happen also at the

second reference)

As Mike stated, the ABL is storing a reference to the object in the temp-table.

Thanks.  That was my guess.

Thanks. Everything else would have meant that we already have

serialization and should be able to pass objects between sessions!

In connection to your collection discussion:

I doubt that a temp-table would be a good storage for a collection when it would be "by-value". IMHO an object instance should be able to be placed in a number of collections, which does require "by-reference" storage. The fact if an instance should be accessible using any number of collections (0..1.....n) depends on the fact if the original container (the creator) exposes a reference to an instance, not the actual storage of an objects state at runtime.

Don't you agree?

I agree that it would be wrong to have multiple collections containing the same object which were not actually the same object.

Frankly, I can't imagine why one would have the same object in multiple collections at the same time, so I had never thought about it this way.

Do you have a use case?

Do you have a use case?

Certainly, when the UI is accepted... :-)

Most .NET Controls that provide multi-selection capabilities, like the Infragistics Band, TreeView, ListView, ...

A row is member of the Rows Collection of any of the Grids Bands. The currently selected Rows are member of the UltraGrid:Selected:Rows Collection which is of the SelectedRowsCollection type.

In our SmartComponent Library all UI controls on a screen are by the nature of .NET Controls member in the Controls collection of the Form or it's contained Container Controls (like GroupBoxes, TabFolderPages, etc.). As one use case we store references to Controls that should be enabled in certain states of the UI (Add, Update) in Collections as well.

Both use cases require that an object is referenced by more than one collection. Certainly the quality of the references is different. The (first) one provides more or less a composition association between a container and it's contained object (with the difference that in certain - not very likely -  situations the child may survive the deletion of the parent or a child could be reparented/adopted).

I'm not entirely sure I am following you .... are these collections .NET collections?  If so, that doesn't count because it is based on the limitations of a .NET collection.

So, while I tend not to consider the UI, it being a special case, if nothing else, I am not clear whether there is a use case for an object being part of multiple ABL collections.

BTW, on further thought it was clear that what must be in the TT was a reference since any object added to a TT is also still an object outside of the TT.

I'm not entirely sure I am following you .... are these collections .NET collections?  If so, that doesn't count because it is based on the limitations of a .NET collection.

Yes, that are .NET Collections (except for those that we implemented in the SmartComponent Library. But what does that matter? Your question about the use cases in this thread was generic about objects references by multiple collections. That use case or pattern has nothing to do with the platform. Actually the implementation of the Collection itself should be completly hidden, so who cares - for the sake of having objects in more than one collection - if the collection is using a temp-table internally.

So, while I tend not to consider the UI, it being a special case, if nothing else, I am not clear whether there is a use case for an object being part of multiple ABL collections.

As I make no distinction between ABL collections and .NET Collections (see above), do you see any bad/evil in the use cases I listed?

tamhas wrote:
[snip] 
Frankly, I can't imagine why one would have the same object in multiple collections at the same time, so I had never thought about it this way.
Do you have a use case?

Any UI design software would require this, surely:

A collection of objects on the toolbar (buttons / spacers / labels)

A collection of buttons

A collection of labels

So a button may be in 2 collections at the same time

Or am I sitting here in a complete fog ?

Multiple .NET collections  is not a use case for me since I would implement all of them in one class using what I am calling my SuperMap pattern ... briefly, like a Java Map class, only with multiple keys and methods for sort and search by each key.  One wouldn't normally do such a thing in .NET because of the fascination with generic collections, but I think it is the right approach in ABL for the use case of two objects connected by multiple relations.

What is the purpose of the collection of buttons or the collection of labels independent of where those buttons or labels appear?

Filtering by type and Strong typing (see Julians current thread in the GUI for .NET forum).

That's a different use case from those that I have described here. Feels like you're avoiding to comment or take them seriously enough?

Or am I sitting here in a complete fog ?

>

Maybe, but I hear California gets real foggy too

Another use case: you have a set of Skins ("appearances") that you can store in a cache somewhere. Assorted UI objects can have 0..* appearances. Appearances could further be composed of other appearances.

I'm not sure why UI is not considered 'real' enough a use-case. And I'm fairly sure that SWT or other OO UI frameworks do things in extremely similar ways: that is after all, the purpose of having a pattern, no? To do things in repeatable ways.

-- peter

How is having to cast to the right type enhanced by having a collection of buttons?

Or were you referring to the one about garbage code.

I am not excluding UI as being a valid use case, although, if that is the only place the need arises, that would mean that it was a special case rather than a general requirement.  I am thinking a lot about patterns for collections and related groupings at the moment, so I am interested in use cases I may not have considered.

I am not very interested in the case where the collections are .NET collections because 3GL collections have known limitations (which, however, have known positive characteristics too, hence my thread on the possibility of a lightweight collection object in ABL).

I.e., that one might have a ABL object in multiple .NET collections is mildly interesting to know, but doesn't tell me about the use case for an all ABL context.

3GL use cases aren't particularly relevant to this thinking because collections is what they do and the nature of a collection is that it is very limited in what it can do, so one doesn't really have a lot of choice.  I recognize that there are some ways in which this is a Good Thing in terms of the Model to Code relationship, but I'm not thinking this is the way I would solve the problem in a pure ABL context.

How is having to cast to the right type enhanced by having a collection of buttons?

When the type of elements is Button and not Toolbase there is no need to CAST. That could be implemented either using a generic collection or a specialized collection.

Are you saying that you would put the same object in two places so that it could be known under two types in order to apply methods under its underlying type without casting?

Sounds like a good way to write confusing code.  "Here, look, I am doing something to this button ... I wonder where it is on the screen or even if it is actually visible at the moment?"

Are you saying that you would put the same object in two places so

that it could be known under two types in order to apply methods

under its underlying type without casting?

I wouldn't do so - but I do understand why Julian asks for that.

What is the purpose of the collection of buttons or the collection of labels independent of where those buttons or labels appear?

To define / create them once only. A toolbar is a great example, since you'd only want to create an 'Open' button once per application, even though it might appear on multiple windows/forms/screens. It's an alternative to creating an OpenToolbarButton object.

-- peter

To define / create them once only. A toolbar is a great example, since you'd only want to create an 'Open' button once per application, even though it might appear on multiple windows/forms/screens. It's an alternative to creating an OpenToolbarButton object.
-- peter

This is getting really off track from Thomas' thread, but in the case of multiple buttons for the same action, it's not referencing a single object instance in multiple collections. Actually there is a root tool instance placed in the UltraToolbarsManager:Tools instance. Then there are one or many instances of Tool objects (with the same key as the root Tool) in the Tools collection of Toolbar objects. They will mostly look idnetically, but are different instances.

The Selected:Rows of the Grid is a much better example.

Doesn't sound like a pattern I will be putting in my basket.

But, how does puting the same object in the toolbar and in another collection by type achieve that goal?

tamhas schrieb:
But, how does puting the same object in the toolbar and in another collection by type achieve that goal?

If one collection is of type Collection and the other Collection is of type Collection.

Then you'd know by accessing a tool using oTextBoxToolCollection["mykey"] allows to reference the Text property and by accessing the same tool using oToolBaseCollection["mykey"] will only allow to access the properties that are common to all different Tool types (like Enabled and Visible).

(see Julians thread for details).

Actually the use of generic collections is not required. The same might be accomplished using specialized collection classes.     

I got the point in Julian's thread of wanting to get at the same object two ways.  I was questioning how getting at it two ways enhanced Peter's goal of only instantiating it once.

Yes, but the virtue of generic collections is that it is possible to regard them as infrastructuree, i.e., the means by which the 0..* relation from A to B is realized in the code without having to model a join class or other form of connector.  One can generate A with a pointer to a collection containing B without the collection being in the model.  If you go to specialized classes, they then have to appear in the model.