RE: [Pythoncard-users] What Do We Call These Things?

My take on this is that a Hypercard application could be seen as a
collection of persistent object instances. In this case, each object
instance also knew about its display properties and could override them. So
the *class* would be "defined" to have a particular background (with a set
of buttons, etc.), but each *instance* (card) could have specific additions
(different background).

It seems to me that one could replicate much of this behavior using the
ZODB. But that would imply that we wanted the display mechanism and the
object data to be tightly intertwined and both stored in the database. That
is not how the Pythoncard framework is designed now. And I'm not sure
everyone would agree that this is a good idea. At the same time, I don't
think it would be too much of a stretch to imagine all the Pythoncard
resource files existing in the ZODB for the app. But then we have the same
problem as Zope - programmers want these kinds of things to be text files,
not buried in the database.

Just a bit of rambling.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Francois Granger
> Sent: Sunday, January 06, 2002 3:22 PM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] What Do We Call These Things?
>
>
> At 12:19 -0800 on 6/01/02, in message Pythoncard-users digest, Vol 1
> #123 - 2 msgs, you wrote:
>
> >Solutions. Can we really say, though, that a solution is a book
> >(which is what sort of flows naturally out of layouts and pages)? I
> >don't think so.
>
> That was the wording for ToolBook from Asymetrix back when they
> introduced the product in 1989 (?).
> ToolBook was a HyperCard clone running on Window. A stack was a book,
> and a card was a page.
> It is now a fully different product.
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users