Dynamic-Polymorphing Class Object Challenge

Put on your thinking caps.....

I'm just curious in how many different ways the following concept could be

implemented. I have two in my head, thinking that opne might be better than the

other. I have done my best to avoid using coded examples in an effort to not

give any preconceptions.
I'm not necessarily looking for actual code, but rather pseudo code &

theoreticals (but I'm not going to deny actual code if you have it.)
Concept:
A sort of "Ad-Hoc" class. The class to be implemented as an ActiveX DLL that

would exhibit the following characteristics:
1) Dynamic Properties. In one instance (Obj1), I may need a property called

"Prop1", but in another (Obj2), it might be "Property1". Properties may need to

be added on the fly.
2) The class may or may not be "hard". "HUH?!" you say. Meaning that once the

property structure is set, it cannot be changed or added to. Let's say that Obj1

from the previous example is "hardened", but Obj2 isn't. If I assign a value to

the property "Property1" of Obj1, an error ocurrs. But, if I assign a value to

the property "Prop1" of Obj2, no error ocurrs, and I can retrieve the value

later. NO CHANGES to the object's structure should be allowed. For flexability,

could be an On/Off switch. Or, it can be set once and that's it.
3) Persistance. It must have a way to save it's state. May or may not be to

the hard drive. This includes both data and structure.
4) Serialization. Most good objects should do this.
5) Copy or clone method.
6) For a lack of a better term, Templating. Same as persistance, but structure

only. After the object is created, the structure is loaded and then optionaly

hardened.
7) Merge. Able to take the structure of one object and merge it (or the

properties) into another. For example, if I take Obj2 and merge it into Obj1

(assuming Obj1 isn't hardened), Obj1 would then have both "Prop1" and

"Property1" properties.
8) Data Overlay. As an addon to #7, optionaly include data as well as the

structure. Be able to indicate whose data over writes whose in the event that

common properties are found.
9) Simple. Above all else, it should be simple to use. Allow for the greatest amount of flexability in the least number of steps.

There's no prize. And like I said, no actual code is expected, I'm only looking for theoretical ideas. Although, if you want to spend the time trying to code something & would like ot share it, then by all means, be my guest. As for me, I already have worked out some ideas in my mind (I don't plan to post them for a little while to prevent preconceptions, but eventually, I will.)

What would be a practical application for this object? I mean why does it need to do all this and have said limitations?

Show us an example of its use.

Ok here is my entry, I decided to go ahead and give it a go. Is this what you mean?

For starters, it started out for fun, see if it could be done (I think it can). But then I started ti think about it a bit more, and I actually think I might have a use for it (haven't decided yet). That said, maybe if I walk you through the thought process I went through, you might be able to see what I was thinking.
It started w/ the object cloning thread else where. While going through it, I realized that I too have had prior needs to clone a data object, creating two distinct instances. At anyy rate, I was think how nice it would be to dynamically retrive properties, do a sort of for each, like you had mentioned. Then I started thinking about serializing and transfering the data from one copy to the other. As for the requirements.... no reason for them. Just didn't want to make it too easy.

VB Varients make this pretty easy. Simply hold an array of strings (property names), and array or varients (values), or one array of a UDT that holds both of the above. Then, Some functions for Adding properties, removing them again, setting values, getting values, hardening, cloning, and merging. Cloning and merging would utilize the first four functions, in a loop.

Z.

So it's kind of like exploratory research, that's cool. That's the main reason I gave it a try.

Actually, at some point I am going to have to write one of these in C++, for a database system I am working on. Essentially, you can add properties to the thing, but you also attach a query string to the property. When you attempt to read from the property the first time, it queries the database for the value, and gives it back. From then on, it just uses that value.

Z.

Why does it have to be in C++?

Quote:

---

Originally posted by Edneeis
So it's kind of like exploratory research, that's cool. That's the main reason I gave it a try.

---

Bingo. Sorry that didn't come out better.

At any rate...
This is exactly what I was talking about. Each of us knew to get from point A to point B. But took different routes to get there. Edneeis used a collection, UDT and PropBags to get there. Zaei suggested UDTs and arrays. On the other hand, I'm using XML document to hold everything. I'll post that in a minute, I'm finishing the demo.
Each has their own drawbacks, and their advantages. One may work in one situation, but necessarily in all situations.

Sometimes, I've seen people so dead set on doing it one way, and not open to other ideas. My goal for this was to promote some kind of discussion to show that there is more than one way to do the same thing. Edneeis had an elegant solution using the PropBag, I never would have though of that. Instead, I used XML, saving it to an XML file to persist my data.

Oops, I forgot about the serialization... Pretty simple, especially since VB can read and write arrays to binary data with a single call.

C++ because that is what I use 90% of the time =).

Z.

Here's my solution -- this is the one that's been running around in my brain all afternoon.
Took me awhile, but I got it.
One caveat: It uses MSXML (v2.0) so, to use it, you'll need to get MSXML from Microsoft.

You know, using strings, you could actually add properties to properties...:

Code:

---

PropThing.AddProperty("Prop1")
PropThing.AddProperty("Prop1.Sub-Prop1")
PropThing.SetProperty("Prop1.Sub-Prop1", 10)
PropThing.SetProperty("Prop2", 20) ' adds a property under the hood

---

Simple. Since you are simply storing the property name as a string, Prop1, and Prop1.Sub-Prop1 are two unrelated properties... ::shrug:: might be useful =).

Z.

Quote:

---

Originally posted by Zaei
You know, using strings, you could actually add properties to properties...:

Code:

---

PropThing.AddProperty("Prop1")
PropThing.AddProperty("Prop1.Sub-Prop1")
PropThing.SetProperty("Prop1.Sub-Prop1", 10)
PropThing.SetProperty("Prop2", 20) ' adds a property under the hood

---

Simple. Since you are simply storing the property name as a string, Prop1, and Prop1.Sub-Prop1 are two unrelated properties... ::shrug:: might be useful =).

Z.

---

You sure could.

BTW: I like the idea behind the C++ object you mentioned. My only concern about it would be trying to access several properties in a row. Won't there be a performance hit as each query is executed?

Likewise using Variants you could have a property be a whole other collection.

Quote:

---

Originally posted by Edneeis
Likewise using Variants you could have a property be a whole other collection.

---

:eek:

Ahhh.... Extendialism Programming!!!!

:D :p

You would take a performance hit when FIRST accessing the property, but after that, the property would be cached, and would only go out to the database when ordered specifically to.

Z.

What I meant was, what if I need to access 12 properties. Will it make 12 trips to the DB getting each property? Or will it go once, getting all 12, the first time I access the first property.

It would be like this:

Code:

---

' first time access, go to the database, and query
' with the query attached to "Prop1"
x = PropThing.GetProperty("Prop1")
' Second access, dont go to the DB, just return the cached property
x1 = PropThing.GetProperty("Prop1")
' First access, go to DB
x2 = PropThing.GetProperty("Prop2")

---

So the first time you try to access a property, it would go to the DB to get it. After that, it would use the saved value. So, if you accessed 12 properties in a row that had never been accessed before, it would go to the database 12 times. If you then accessed them 12 more times, it would give you abck the cached data, and not go to the database.

Z.

I like your XML idea Techgnome, it's like a really cool XML wrapper only better. Good job.

One thing you left off the set options on the properties so it can't hold objects right now. XML can handle serializing objects can't it? I really like how you let the XML take care of most of the difficult stuff, like I did with the collection but the XMLDOM can do more.

With the DB idea if all the properties are in the same table maybe it should get the whole table on the first property and cache all the properties at once so it makes less trips to the DB.

Well, the properties can be anywhere in the database, plus the object can have properties added at any time. Also, the database is really designed for fast access to unique fields, so I wouldnt be able to search for more then one property at once.

Z.

My main reason for going with XML was because it was easy to save to the HD (which is what I needed for my project) and load it back. My "linked list" class also uses the XML concept, but to an even greater degree by allowing attributes to be set. But I also liked your idea of propbags. Less overhead & you didn't use any additional items (such as the XML parser).

As far as serializing objects.... if you can get it to binary data, you can use the CDATA[ construct in XML to store the bytes.
Not really that difficult, but could be a pain since the developers of the MSXML object didn't make it easy (at least not as easy as setting an attribute or tag element.

Here is my go at the Property thing... I didnt try the Merge Function, but everything else is there.

Z.

He's got one up on us Edneeis, I didn't think about removing properties. I also like the idea of a Release method that essentially clears out the object.
One thing of note was the (De)Serialization. When deserializing, you write out each property in a name/value pair, but in the serializing, you only read in the first one. But then again, I had only asked for theoreticals.

The Put method writes out the entire array to disk in one go. For some reason when I tested the same with the Get method, it didint work, so i just did it in a loop.

Z.

I forgot the hardening of the object. Here is an updated version.

Z.

Anyone else going to take a crack at this one?

Z.