Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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" ;