Fixing and enhancing the WebCard card constructor
I fixed a bug in the initial code of WebCard, my RetroChallenge 2024 project.
An infinite loop in the constructor of the Web card type caused a stack overflow that aborted Medley. The Web constructor was supposed to call the constructor of the parent card type Text. But I misunderstood the NoteCards API and used NCP.CardTypeFn which ended up calling the Web constructor itself, hence the infinite loop.
The fix was easy: call the supertype's constructor with NCP.ApplySuperTypeFn. Troubleshooting the issue was a great learning experience.
With the bug out of the way I fleshed out a bit more of the Web card constructor. I wrote code to query the user for a URL and store it in the property list of the card. This gives persistence for free as NoteCards automatically stores properties to and retrieves them from notefiles.
There's still some card initialization to do in the case the constructor is passed the option to not display the card, but I'll leave it for later.
In my initial plan the constructor would query the user also for an optional card title but I dropped the idea. NoteCards already allows adding and editing card titles, so forcing this from the constructor seems redundant and possibly confusing. Like NoteCards, by default WebCard names new cards Untitled.
Reporting my progress and plans to the Medley Interlisp team sparked an interesting conversation on rapid prototyping in Interlisp and the Lisp development style. For example, I learned the Interlisp advising functionality was designed as a prototyping tool.
I'm not yet sure what to work next, whether to handle card editing or go straight for the website visiting functionality. The latter is the only missing piece of an early prototype.
Discuss...
Email | Reply @amoroso@fosstodon.org