8 Oct
2003
8 Oct
'03
8:57 a.m.
Hi john
Well, I may be telling you wrong. I just read the #signal method on
the ANSI
standard, and it appears that "[self foo] on: Error do: [:e | 5]"
should be
"5". Now, I can't remember where I saw that it was undefined. Anyway,
I'll
change the #Smalltalk implementation so that "[self foo] on: Error do:
[:e |
5]" returns 5. You shouldn't need to change your code.
If you can check that this would be good to know what is the good way to
write exception handlers.
*) When you have an exception handler, the exception
block shouldn't
just
return since that isn't legal ANSI Smalltalk. For example, instead of
having
"[self something] on: Error do: [:ex | 5]" it should be "[self
something]
on: Error do: [:ex | ex return: 5]".
Didn't know about that, the way I wrote it seemed to me more natural.
But if this is the ANSI standard, I will change it of course. I might not be understanding you, but I believe that
it does handle
that
case. In my version, everyone only references the current page. When
you
create a new version, it creates a copy of the current object for
history
and then copies all of the data to the current object. The current
page is
always the same object -- it just gets different data copied into it.
Anyway, I don't believe either approach is the best. Instead I would
like to
see an object that is a structure holder. It would contain things like
the
title, parent, and the current structure. The structure object would
contain
the stuff that changes between edits. When a page object referenced
another
structure, it would hold the structure holder object instead of a
particular
structure. This gets around the #become: hack by putting another level
of
indirection in there. Furthermore, I believe it would be easier to
model
this in a db than the current approach.
This is an interesting idea.
I like this discussion because SmallWiki can become really excellent.
stef