> Uli: since we are now down to 13 bytes housekeeping
> data per block in XBlockFile, I will continue
working
> on XStackFile when I next have some time to program.
It's great to hear the noise of machinerie running
again. Silence is golden, but not in this case eh!
> Uli: Since my technique of writing down my thoughts
> and then waiting for input from others like Anthony
> paid off the last time, I'll try this again.
Excellent plan. :)
> Uli: It also helps me think it through correctly
> before implementing it.
A non-trivial benefit, to be sure. :)
> Uli: I encourage all others to do the same. It
> also helps our big group of non-programmers, as
> they can see something is happening.
Though it bugs me to qualify scripting as not really
programming, include me in that group nonetheless. I
have been confronted head-on with this sterile debate
of late, notably in the context of my doctoral studies
in Cognitive Computing. It's an uphill battle.
> Uli: XStackFile is an interface that provides some
> central functions to access different parts of a
> stack, which are stored in collections of blocks in
> an XBlockFile. There is a function to get at stacks,
> bgs, cds and parts, and properties of any of these.
Excellent. This is exactly what I need right now. I
have been saving and restoring the properties of
FreeGUI's components by writing and reading text
files. My way is a kludge though. I would much prefer
using your XBF. Is it in the format of an external
cmd/function ?
> Uli: These handlers take a "create" parameter which
> you set to TRUE to have it create the blocks in case
> they don't exist already.
My first impression is that I would set it to true
almost invariably. When would it be astute to set the
"create" parameter to false?
> E.g. if a button never had anything assigned to its
> contents, it will not have a block for contents,
> thus saving 13 bytes. Same goes for scripts etc.
> If they're empty, they won't have that block. So,
> essentially, an object with lots of properties set
> and lots of data and scripts in it will be larger
> than it would be in HyperCard, but the average
> object will be smaller, hopefully.
Good thinking. In which case you would set the
"create" parameter to true, correct?
> Properties are stored two ways: The ones that can
> be stored at a fixed size are all kept in one block,
> at different positions. Properties that are variable
> in size, like script and contents, will each have
> their own block.
That's pretty much how I handled the properties in
FreeGUI. The content and the script have their own
individual files, while the fixed-length props are all
in one tab-delimited text-file.
> However, since mashing together all these data bits
> in one block would mean we'd have to move around
> lots of data if their size changed, I'm only doing
> this for fixed-size properties.
Makes sense, although I have often noticed that long
processes are often not as long as we fear they will
be. Perhaps this is merely because knowing ALL that is
going on (as a developer) makes us more patient as a
user. Who knows. (shrug)
> User properties will always be considered variable-
> size, as it is hard to anticipate how the scripter
> will use them.
This is wise.
> However, you will not notice all of this as a
> programmer, as XStackFile already hides this fact
> from you. You just request a property, and it will
> know where to look for it and how to get it.
This is awesome. It's what OOP is all about! :)
> What I am not quite clear about in my head is how
> the look-up of objects by name or number will work.
You could chain through the pointers of the objects
composing the set/list each and every time. But I
suppose this entails loading all of the objects (e.g.
inefficient). Or you could do this once and create a
list (e.g. index them).
In my text-file architecture, I merely have to list
the folders of the proper level of the HFS. Makes me
wonder, by the way, how the Macintosh Finder handles
this, and by extension whether we should do something
similar to what the Finder does. Or something radical
like an SQL database management system. Comments?
> For numbers we'll probably have a list in every bg,
> card and stack of the order of its sub objects
> which we can search, but as names are stored with
> the object itself and not in its parent, this will
> probably be a bit more costly.
Any idea how HyperCard does this now? Or some other
program's way of doing this? Some open source library
perhaps?
> But I will very likely hide this away inside
> XStackFile, because there streaming can be employed
> to avoid loading all sub-objects of a card or stack
> just to look up one by name.
Hard to disagree with that. ;-)
> XStackFile supports multiple stacks in one file.
Does that add another level of complexity to XBF, or
is it relatively straightforward? If it unduly
complicates things, then I naively suggest that we aim
for a single stack file-format (e.g. to be more
expeditious).
With XBF and FreeGUI knitted together, we will almost
have a full-fledged application on our hands. For,
with FreeGUI, we will be able to browse a stack, view
& edit its properties ; and with XBF, the properties
will be saved and restored efficiently. Moreover, if
XBF is packaged as an XCMD, then FreeGUI does not need
anything other than HyperCard to run .. immediately.
And, of course, there is always MetaCard's Starter-Kit
too.... while we await FreeCard's own HyperTalk
interpreter.
More on this tomorrow and throughout the week, Uli,
because it is getting late here in Quebec (Canada).
Warm greeting,
Alain Farmer
mailto:[EMAIL PROTECTED]
PS: Feel free to "ramble" any time you wish, Uli. ;-)
__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freecard-general
