[REBOL] Re: [DEV] dbms3.r 01
From: joel:neely:fedex at: 13-Jan-2002 11:54
Hi, Gabriele,
Let me first offer a word of support to your approach. As is
probably obvious to anyone who has read the first refactoring
article on REBOLforces (hint, hint, hint ;-) I strongly believe
that there's much more value in seeing HOW code is designed and
constructed -- including false starts, bad ideas, backtracking,
refactoring, etc. -- than in simply having a finished product.
At the same time, it takes real courage to expose one's thinking
in near-real-time to an audience or a group of collaborators.
I applaud your bravery!
Gabriele Santilli wrote:
...
> DEVELOPMENT, part 1
>
> let's start with the low level functions to handle tables on disk.
> table on memory could be useful too, but should be easier to
> implement...
>
> i think we can proceed this way: let's create all three kinds of
> tables, then we can let the user choose...
>
Good plan IMHO. Whever you come to a fork in the road, take it!
Seriously, I've seen lots of great designs come from a decision
to allow downstream decision making rather than wiring one set
of assumptions into the fundamental design.
> ... let's start with tables
> on memory, that can be simply represented with blocks. our
> interface should include ways to: append a new row, pick a row,
> change a row, remove a row.
>
...
> some comments: the row-id will be the index of the row in the
> block, so it's an integer. this might be different for other kind
> of tables. also, the row-id of a row is not guaranteed to remain
> constant for a row...
>
My experience suggests that there's value in three kinds of access
to elements of a collection, which I'll call by semi-arbitrary
names for this discussion:
1) "physical" access -- corresponding to your notion of "row-ID"
in which traversal of a collection is done in the fastest
possible manner -- SINGLE VALUED.
2) "identity" access -- via a unique ID which is guaranteed
not to change throughout the lifetime of the collection (a
sort of "true name" of each entity) allowing references to
entities in the collection to remain valid even if the order
or structure changes -- SINGLE VALUED.
3) "criteria-based" access -- via a search expression, which
may refer to one or more attributes of an entity, possibly
represented as a function passed to an iterator which finds
and presents all entities possessing the specified property(ies)
-- SINGLE OR MULTIPLE VALUED.
I'd suggest that "row-ID" be as thoroughly hidden as possible,
e.g., only used within a loop that is scanning the collection
WITHOUT the possibility of modifying the collection or any of its
elements in a way that would cause the meanings either of "current
position" or "positions already visited" to change.
Otherwise (e.g., one entity that refers in a persistent way to
another entity) a "unique ID" should be used.
Just my $0.015 of the moment ;-)
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
