[REBOL] Re: Project introduction ... Re: Re: RFC: Rebol Framework
From: robert:muench:robertmuench at: 9-Oct-2002 11:30
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
> On Behalf Of Petr Krenzelok
> Sent: Tuesday, October 08, 2002 5:36 PM
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Project introduction ... Re: Re: RFC: Rebol Framework
> 1) I like objects - I always did - the path navigation is easy :-)
Hi, yes that's right but using objects for records has some
disadvantages:
- Extending objects isn't that easy
- Objects take quite some space on disk (more than blocks) because empty
object fields are saved too. Blocks just contain the name/value pairs
that have a value
> That's the first thing someone will have to explain me - why
> naked-objects or RFM uses blocks and name value pairs? Is there any
> advantage?
Yes, it's a very simple and basic system. You might remember that I
asked around what's the best pattern for storing data with Rebol. I
tried objects and I tried blocks. For me blocks are more user-friendly.
You can iterate through this series, you just can add a name value pair,
you can nest blocks easly etc. With name/value pairs in blocks both
pieces show-up to you the same way. Why make a distinction between the
name and the value of a field?
> 2) As you can see, I need some relations - each building has its
rooms,
> - typical parent child relationship. That relationship can be
expressed
> in RFM, if I understand it correctly, but what if child can have its
own
> child relationships etc.?
Than just add it. My idea is that you have a set of relations:
parent-child, used-by, responsible-for etc. Now you just add a relation
from master to detail and select a type, that it. You will get a
directed-graph of different relations.
> 3) Can objects be extended in the real time by adding another
> attribute?
Yes, that's why I use blocks. And objects of the same class don't have
to have the same structure. Only those name/value pairs that make sense
are present.
> Should I rebuild the rest of objects then, or just prepare
> query engine that there can be some object field, which doesn't have
to be
> found with previous version of object?
;-) That's why I use name/value pairs. My idea is that in such a case
the user can say: "Hey, for this record I need an other field. Let me
see what kind of fields do I have available." Now a list of pre-defined
fields will show up. Each field will have an explanation what it should
be used for. If the user finds an appropriate field, he just selects it.
If not you can add a new field, give it a description and use it in your
current record. If you now see that you will need this field for all
records, just add the field to the object-template. You see what I mean?
> 4) I have to keep in mind, that my system will have to be
> multilingual ...
Fine, just add a label field to the field record and add different
languages:
[fieldname "surname" label [de "Nachname" fr "..."] description "Use
this field for surnames of persons"]
> Don't get me wrong - I started with few testing scripts, from the
> scratch, as I need to understand from the very beginning how things
> model for me, what is good and what turns into being
> incorrect aproach, etc..
No problem, that's how I do it too.
> I come from relational database world so things like associative
> model of data, dynamic systems, etc., are rather new to me.
Well, this will be the biggest step to do for you. I only know a few
people that got it yet. Especially people with long RDBMS experience
have big problems in understanding and seeing the advantages. Robert
