Hi Allan,
Funny you mentioning this because what you are describing sounds like LISP
(DrScheme).
The Scheme language (derived from LISP) is heavily list centric and you roll
your own everything.
The object (list) is a data abstraction of paired objects - but the
underlying data construct is hidden (for the most part. While I am talking
about list objects in Scheme the data abstraction can be applied to any
language.
When I first started using Scheme (coming from DELPHI) my head hurt. Now I
can read the code as easily as English (I really need to get a life :).
First off, might I suggest you strip away some of the object descriptors and
get dirty in the data abstraction - you can add object characteristics later
using whatever creators / mutators / operators you want.
BTW - I work mainly in INTERBASE so I have a fair idea about what you are
trying to do (I hope :)
This is an example of a list of lists:
(("Smith" ITB001 (1 2 3 4)) ("Anderson" ITB002 (3 4 1 2)))
You can add more branches and leaves as you like to cover whatever property
your data abstraction requires. And you can create the tools you need - but
it seems that despite the question, this is not what you really 'want'.
I am wondering if you are looking too closely at Delphi (and components) as
opposed to thinking about what data needs to be collected, how is the data
related, how the data is to be stored (tables), and what information will
you want to get from it? I'm dancing across whole areas of course but that
is broad brushstroke stuff.
Further, storing the data to one side - how do you intend accessing it,
business rules etc. This is a database object. Depending upon what
database solution you want (mySQL, Interbase etc) you will need to have a
bridge between your data and your program that is, hopefully, transparent
and crafted on the data abstraction you designed. If you design well, then
you won't need to be overly concerned about minor changes to the data
abstraction in terms of the impact on the system or performance.
At the risk of insulting you, think data and relationships to design your
system using relational tables. BTW - tables are objects with properties
too. If I am on the wrong track, I apologise. However, if all you are
looking for is a push to design the system (data / tables / relationships)
then let me know and I'll see where I can help.
Kindest regards,
Mike Culleton
----- Original Message -----
From: "Alan Colburn" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, May 20, 2007 6:27 AM
Subject: Re: OOP -- Persisting Lists
>
> Suppose your application needs a list of lists. I'm having trouble
> figuring out how and where one persists object data--whether using a
> database or some other file format for storage.
>
> Many examples illustrate the point but, for the sake of argument, imagine
> a classroom with students completing assignments. An Assignment class
> could include fields for pointsEarned, pointsPossible, etc. A Student
> class would include a field containing a (TObjectList descended) list of
> Assignment objects. A Classroom object, in turn, would include a field
> containing (TObjectList descended) list of Student objects.
>
> Now, how does one go about saving all this in a file? It seems like a
> Classroom object, when saved, would need a field made up of Student
> objects which, in turn, requires a field of Assignment objects.
>
> Can you sense my confusion? I'm used to database (or file) fields made up
> of strings, integers, memos, etc. I don't understand how fields made up of
> object lists would work ...
>
> As always, thanks in advance -- Al
> _________________________________________________________________
> Add some color. Personalize your inbox with your favorite colors.
> www.windowslive-hotmail.com/learnmore/personalize.html?locale=en-us&ocid=TXT_TAGLM_HMWL_reten_addcolor_0507
> _______________________________________________
> Delphi mailing list -> [email protected]
> http://www.elists.org/mailman/listinfo/delphi
>
> ----------------------------------------------------
> This message has been processed by Firetrust Benign.
>
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
