I know someone has done this already. I know you know this someone. So:
Anybody out there who has implemented a versioned class mechanism?
� la
(define-versioned-class frgo ()
((slot-1 :accessor slot-1 :initform nil :initarg :slot-1)))
(setq *i* (make-instance 'frgo))
(active-version *i*)
=> 1
(setf (slot-1 *i*) "1")
(slot-1 *i*)
=> "1"
(make-new-version *i*)
=> 2
(active-version *i*)
=> 2
(setf (slot-1 *i*) "2")
(slot-1 *i*)
=> "2"
(setf (active-version *i*) 1)
(active-version *i*)
=> 1
(slot-1 *i*)
=> "1"
(setf (active-version *i*) 2)
(active-version *i*)
=> 2
(slot-1 *i*)
=> "2"
Hmmm, nobody? Really?
(I seem to remember having read an artice somewhere about a software
version control system written in Lisp that had implemented versioned
object classes ...
And no, searching the WWW did noz turn up something ...
Any pointers highly welcome! Thx!
Kind regards
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank GOENNINGER wrote:
> I know someone has done this already. I know you know this someone. So:
> Anybody out there who has implemented a versioned class mechanism?
>
> � la
>
> (define-versioned-class frgo ()
> ((slot-1 :accessor slot-1 :initform nil :initarg :slot-1)))
>
> (setq *i* (make-instance 'frgo))
> (active-version *i*)
>
> => 1
>
> (setf (slot-1 *i*) "1")
> (slot-1 *i*)
>
> => "1"
>
> (make-new-version *i*)
>
> => 2
The day (make-<X>...) does not return an instance of X is the day I
switch to Javascript.....hang on....
>
> (active-version *i*)
>
> => 2
>
> (setf (slot-1 *i*) "2")
> (slot-1 *i*)
>
> => "2"
>
> (setf (active-version *i*) 1)
> (active-version *i*)
>
> => 1
>
> (slot-1 *i*)
>
> => "1"
>
> (setf (active-version *i*) 2)
> (active-version *i*)
>
> => 2
>
> (slot-1 *i*)
>
> => "2"
>
> Hmmm, nobody? Really?
No, but Costanza probably has a complete library for it. I mean, if you
need CLOS flogged beyond all reason, where else to turn?
Just tell me version is a cells-mediated slot!
Well, OK, I confess I did a system where data never got erased and
changes were just overlays such that old data was recoverable at will,
but that was at the application level.
The trick was simply to have...well, why not? Just treat setf (svuc ) as
(push new value slot) and read as (car slot value). Just not sure I
would see version numbering as useful: this guy might get changed ten
times and this guy twice and I do not need version 5, I need "version
at point of time" or something else.
kzo
Kenny <·········@gmail.com> writes:
> Frank GOENNINGER wrote:
>> I know someone has done this already. I know you know this someone. So:
>> Anybody out there who has implemented a versioned class mechanism?
>>
>> � la
>>
>> (define-versioned-class frgo ()
>> ((slot-1 :accessor slot-1 :initform nil :initarg :slot-1)))
>>
>> (setq *i* (make-instance 'frgo))
>> (active-version *i*)
>>
>> => 1
>>
>> (setf (slot-1 *i*) "1")
>> (slot-1 *i*)
>>
>> => "1"
>>
>> (make-new-version *i*)
>>
>> => 2
>
> The day (make-<X>...) does not return an instance of X is the day I
> switch to Javascript.....hang on....
Yeah, yes, true - ah, that really was just a very simplified way of
mocking up a (what I call a) "Live Requirement"...
>> Hmmm, nobody? Really?
>
> No, but Costanza probably has a complete library for it. I mean, if
> you need CLOS flogged beyond all reason, where else to turn?
>
> Just tell me version is a cells-mediated slot!
Well, yes, of course. What else?
>
> Well, OK, I confess I did a system where data never got erased and
> changes were just overlays such that old data was recoverable at will,
> but that was at the application level.
The more I think of it I figure I need it at the slot level. So I will
probably end up with my own slot classes. Or copy the cells mechanism ;-)
>
> The trick was simply to have...well, why not? Just treat setf (svuc )
> as (push new value slot) and read as (car slot value). Just not sure I
> would see version numbering as useful: this guy might get changed ten
> times and this guy twice and I do not need version 5, I need "version
> at point of time" or something else.
Oh, there's going to be some very sophisticated "versionioning /
revisioning policies" in there that each will have its own "object
factory" according to the rules formulated in such a policy.
"Point in time" will be just one.
As to the why: I want to have clear control what a consistent dataset
means. Imagine I have several indepdendent objects each having its own
version nr and I want to say that these objects are representing a
"logically consistent set of information/data". I would need to store
that info somehow... And: I want to "go back" to that state later
on. This is a concept called Baselining in Product Data Management
systems...
>
> kzo
Thanks!
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank GOENNINGER wrote:
> Kenny <·········@gmail.com> writes:
>
>
>>Frank GOENNINGER wrote:
>>
>>>I know someone has done this already. I know you know this someone. So:
>>>Anybody out there who has implemented a versioned class mechanism?
>>>
>>>� la
>>>
>>>(define-versioned-class frgo ()
>>> ((slot-1 :accessor slot-1 :initform nil :initarg :slot-1)))
>>>
>>>(setq *i* (make-instance 'frgo))
>>>(active-version *i*)
>>>
>>>=> 1
>>>
>>>(setf (slot-1 *i*) "1")
>>>(slot-1 *i*)
>>>
>>>=> "1"
>>>
>>>(make-new-version *i*)
>>>
>>>=> 2
>>
>>The day (make-<X>...) does not return an instance of X is the day I
>>switch to Javascript.....hang on....
>
>
> Yeah, yes, true - ah, that really was just a very simplified way of
> mocking up a (what I call a) "Live Requirement"...
>
>
>>>Hmmm, nobody? Really?
>>
>>No, but Costanza probably has a complete library for it. I mean, if
>>you need CLOS flogged beyond all reason, where else to turn?
>>
>>Just tell me version is a cells-mediated slot!
>
>
> Well, yes, of course. What else?
Whew! Now just tell me you are using TripleCells!
>
>
>>Well, OK, I confess I did a system where data never got erased and
>>changes were just overlays such that old data was recoverable at will,
>>but that was at the application level.
>
>
> The more I think of it I figure I need it at the slot level. So I will
> probably end up with my own slot classes. Or copy the cells mechanism ;-)
>
>>The trick was simply to have...well, why not? Just treat setf (svuc )
>>as (push new value slot) and read as (car slot value). Just not sure I
>>would see version numbering as useful: this guy might get changed ten
>>times and this guy twice and I do not need version 5, I need "version
>>at point of time" or something else.
>
>
> Oh, there's going to be some very sophisticated "versionioning /
> revisioning policies" in there that each will have its own "object
> factory" according to the rules formulated in such a policy.
> "Point in time" will be just one.
>
> As to the why: I want to have clear control what a consistent dataset
> means. Imagine I have several indepdendent objects each having its own
> version nr and I want to say that these objects are representing a
> "logically consistent set of information/data". I would need to store
> that info somehow... And: I want to "go back" to that state later
> on. This is a concept called Baselining in Product Data Management
> systems...
Or as Senator Howard Baker coined it, what did we know and when did we
know it?
Yes. One of the things I noticed after implementing the CliniSys
no-value-ever-gets-deleted solution (required by the FDA) was that we
suddenly had the ability to run time backwards, kinda like an
archaeological dig peeling away history. Cells made things stay
consistent at any point in time, and time-stamped transactions (just
lists of changes) gave us not only the ability to replicate in an
orderly fashion but also would have let us unwind history cleanly.
Hmmm. I guess the Cells datapulse-id could play that role now, but
CliniSys was done under Cells2.
kt
Kenny:
> Just tell me version is a cells-mediated slot!
Frank:
> Well, yes, of course. What else?
Kenny:
> Whew! Now just tell me you are using TripleCells!
Oh yes, why do you think I asked all those questions weeks ago about
TripleCells ?! ... AllegroGraph humming aways beatifully already...
> Well, OK, I confess I did a system where data never got erased and
> changes were just overlays such that old data was recoverable at will,
> but that was at the application level.
Frank:
> The more I think of it I figure I need it at the slot level. So I will
> probably end up with my own slot classes. Or copy the cells mechanism ;-)
Kenny:
> The trick was simply to have...well, why not? Just treat setf (svuc )
> as (push new value slot) and read as (car slot value). Just not sure I
> would see version numbering as useful: this guy might get changed ten
> times and this guy twice and I do not need version 5, I need "version
> at point of time" or something else.
>
> Oh, there's going to be some very sophisticated "versionioning /
> revisioning policies" in there that each will have its own "object
> factory" according to the rules formulated in such a policy.
> "Point in time" will be just one.
Frank:
> As to the why: I want to have clear control what a consistent dataset
> means. Imagine I have several indepdendent objects each having its own
> version nr and I want to say that these objects are representing a
> "logically consistent set of information/data". I would need to store
> that info somehow... And: I want to "go back" to that state later
> on. This is a concept called Baselining in Product Data Management
> systems...
Kenny:
> Or as Senator Howard Baker coined it, what did we know and when did we
> know it?
>
> Yes. One of the things I noticed after implementing the CliniSys
> no-value-ever-gets-deleted solution (required by the FDA) was that we
> suddenly had the ability to run time backwards, kinda like an
> archaeological dig peeling away history. Cells made things stay
> consistent at any point in time, and time-stamped transactions (just
> lists of changes) gave us not only the ability to replicate in an
> orderly fashion but also would have let us unwind history cleanly.
>
> Hmmm. I guess the Cells datapulse-id could play that role now, but
> CliniSys was done under Cells2.
Yes, I think so, too. I would have to "enhance" the data pulse to being
a structure holding a few more data snippets...
Cheers
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank GOENNINGER wrote:
> Kenny:
>
>>Just tell me version is a cells-mediated slot!
>
>
> Frank:
>
>>Well, yes, of course. What else?
>
>
> Kenny:
>
>>Whew! Now just tell me you are using TripleCells!
>
>
> Oh yes, why do you think I asked all those questions weeks ago about
> TripleCells ?! ... AllegroGraph humming aways beatifully already...
Ah, man, yer havin all the fun! But...it works?! I tossed that off in a
few days just to have something to show at ECLM.
That's great, tho. With a lightweight representation like RDF you can
get away with murder storing extra info.
> Yes, I think so, too. I would have to "enhance" the data pulse to being
> a structure holding a few more data snippets...
No doubt. Have fun! I may have to console myself by doing Cells/JS. Dojo
has a subscribe/notify scheme-- nice, but declarative/transparent is nicer.
kt
On Nov 9, 8:11 pm, Frank GOENNINGER <·············@nomail.org> wrote:
> Anybody out there who has implemented a versioned class mechanism?
You might find Martin Fowler's summary of "patterns for things that
change with time" interesting:
http://martinfowler.com/ap2/timeNarrative.html
Thomas Munro
Thomas Munro <············@gmail.com> writes:
> On Nov 9, 8:11 pm, Frank GOENNINGER <·············@nomail.org> wrote:
>> Anybody out there who has implemented a versioned class mechanism?
>
> You might find Martin Fowler's summary of "patterns for things that
> change with time" interesting:
>
> http://martinfowler.com/ap2/timeNarrative.html
>
> Thomas Munro
Thanks, Thomas, good stuff there!
Regards
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank GOENNINGER wrote:
> Thomas Munro <············@gmail.com> writes:
>
>
>>On Nov 9, 8:11 pm, Frank GOENNINGER <·············@nomail.org> wrote:
>>
>>>Anybody out there who has implemented a versioned class mechanism?
>>
>>You might find Martin Fowler's summary of "patterns for things that
>>change with time" interesting:
>>
>>http://martinfowler.com/ap2/timeNarrative.html
>>
>>Thomas Munro
>
>
> Thanks, Thomas, good stuff there!
>
Yes, and it reminds me... I am embarrassed to say I am so in love with
myself and my own code that I forgot about this:
http://www-formal.stanford.edu/jmc/elephant/elephant.html
Some AI crackpot at Stanford, grain of salt and all that.
kt
Kenny wrote:
> Frank GOENNINGER wrote:
>
>> Thomas Munro <············@gmail.com> writes:
>>
>>
>>> On Nov 9, 8:11 pm, Frank GOENNINGER <·············@nomail.org> wrote:
>>>
>>>> Anybody out there who has implemented a versioned class mechanism?
>>>
>>>
>>> You might find Martin Fowler's summary of "patterns for things that
>>> change with time" interesting:
>>>
>>> http://martinfowler.com/ap2/timeNarrative.html
>>>
>>> Thomas Munro
>>
>>
>>
>> Thanks, Thomas, good stuff there!
>
>
> Yes, and it reminds me... I am embarrassed to say I am so in love with
> myself and my own code that I forgot about this:
>
> http://www-formal.stanford.edu/jmc/elephant/elephant.html
Specifically:
http://www-formal.stanford.edu/jmc/elephant/node3.html#SECTION00030000000000000000
kt
>
> Some AI crackpot at Stanford, grain of salt and all that.
>
> kt
Kenny <·········@gmail.com> writes:
> Specifically:
>
> http://www-formal.stanford.edu/jmc/elephant/node3.html#SECTION00030000000000000000
Yes, that's the idea.
(define-versioned-model frgo (time-based-versioned-class)
(slot-1 (c-in nil)))
(setq *frgo* (make-instance 'frgo))
(setf (slot-1 *frgo*) 1)
(slot-1 *frgo*)
=>
1
343530564
Where 1 is the value and 3434... is the timestamp the value has been
set.
(setf (slot-1 *frgo*) 2)
=>
2
3435320794
(with-effective-time 3235320794
(slot-1 *frgo*))
=>
1
343530564
(with-effective-time 3435320795
(slot-1 *frgo*))
=>
2
3435320794
Doesn't work yet but getting there ;-) There are a few more requirements
as to validity and effectivity, but hey, they'll come later ...
Cheers
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank GOENNINGER wrote:
> (I seem to remember having read an artice somewhere about a software
> version control system written in Lisp that had implemented versioned
> object classes ...
>
> And no, searching the WWW did noz turn up something ...
>
> Any pointers highly welcome! Thx!
Eric Tanter recently had a paper about "Contextual Values" which seems
like what you want. I'm not sure whether it's already available online,
but you can probably ask him...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Frank GOENNINGER wrote:
>
>> (I seem to remember having read an artice somewhere about a software
>> version control system written in Lisp that had implemented versioned
>> object classes ...
>>
>> And no, searching the WWW did noz turn up something ...
>>
>> Any pointers highly welcome! Thx!
>
> Eric Tanter recently had a paper about "Contextual Values" which seems
> like what you want. I'm not sure whether it's already available
> online, but you can probably ask him...
>
> Pascal
Ah - thanks for the pointer!
Regards
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."