• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Stacksmith: Reverse Engineering HyperCard

cheesestraws

Well-known member
where certain parts of a stack are just objects on a card nobody will ever visit. Like, icons are just graphic objects in the current stack

This is kind of a technique I used to use in HyperCard, but ...

Hence why I haven't pulled the trigger on any one solution, because I might want to have icons and templates in a special section of the stack (like the resource fork was in HyperCard) with a special picker UI.

this is the kind of technique I'd have like to use :)
 

uliwitness

Active member
Sorry, didn't mean to derail the thread. Type discussions are only really relevant to HyperTalk-likes in very specific ways...

For me this is useful feedback, so go right ahead. If you want to take this elsewhere, I like to hang out on the Discord for /r/ProgrammingLanguages...
 

bdurbrow

Well-known member
Hmm… should be obvious, but if you do a GUI for class creation, it would be nice if it could be exported/imported from some text-based format like XML, or even just having it’s “native” format be a script kinda like what I suggested earlier. This would allow one to use tools like BBEdit to do bulk transforms for refactoring purposes, or for automating data import. You’d be surprised how often I’ve wished I could do that when working in FileMaker Pro’s GUI based scripting system.

Also, I think it’s important to have the ability to export all the data that’s stored in a stack file including custom classes and object instances; or have the base file format be easily parseable. From time to time, I’ve been asked by someone to help when they’ve put years of data into a database or application, and reached the end of it’s capabilities; only to find that getting that data out in a meaningful way was sufficiently difficult that I had to tell them to type it in again. Or worse; the publisher goes out of business (be that due to a lack of cash, or due to being bought up and killed by a competitor) and eventually the old hardware dies, and they can’t migrate forwards.

This is, FWIW, why all my apps’ native file format is JSON, compressed with ZipKit’s inflate/deflate routines; and there’s also an uncompressed option in the open/save operations.


Personally, I really do think it should have a lightweight type system; even if you go with a factory-method style OO system. By that I mean that an object should have an “is a” property that can be queried and filtered for; and a set of protocols that can also be queried and filtered for. I would avoid multiple inheritance as that gets messy fast.

This is the sort of thing that a power user would find useful, but a basic user need not be concerned with just to tie some actions together.

:unsure:
 

uliwitness

Active member
Hmm… should be obvious, but if you do a GUI for class creation, it would be nice if it could be exported/imported from some text-based format (...) This would allow one to use tools like BBEdit to do bulk transforms for refactoring purposes

Stacksmith's current format actually is XML. Kind of like HTML, though structurally more like HyperCard's original file format. I'll likely keep this format, as it works well as "source code" for checking into version control and for archiving as you say. That said, performance for database-like use cases and distribution as a standalone will probably mean I'll also add a binary format one day.

Personally, I really do think it should have a lightweight type system; even if you go with a factory-method style OO system. By that I mean that an object should have an “is a” property that can be queried and filtered for; and a set of protocols that can also be queried and filtered for. I would avoid multiple inheritance as that gets messy fast.

This is the sort of thing that a power user would find useful, but a basic user need not be concerned with just to tie some actions together.
Yeah, I've been mulling multiple approaches in my head, but none have really felt right so far. I want something that's practical, but also simple to explain. I will have to experiment some more it seems.
 
Top