The debate rages on concerning the pros and cons of
including the DO and SEND commands of HyperCard and
SuperCard into FreeCard.
I am among those that (unrealistically!!!) expect
FreeScript to support the DO and SEND commands.
I use the SEND command a lot because most of my
solutions are multi-stack systems, including my
server-side solutions that use one generic CGI program
that SENDs messages to one or more stacks. The CGI
rarely needs to be changed, whereas the pages
(content) produced by the stacks are in a constant
flux. Happily, the stacks remain editable. So long as
the CGI program can SEND to the stacks, my approach
remains viable. Otherwise, everything, including the
ever-changing content, will have to be in the
non-editable CGI program. Furthermore, not being able
to SEND to the a card means that all pages, even the
exceptional ones, must share the same stack script.
What a hassle!
Which brings me to my next point. What other HyperCard
and HyperTalk features are we NOT going to do?
1. Apple's Open Scripting Architecture comes to mind.
Do we support several scripting languages inside our
Script Editor? Do we support AppleScript? --
AppleScript and MacPerl support is one of HyperCard's
hottest features in my opinion. If we don't, then what
do we do with HyperTalk syntax related to this
feature?
2. Do we support HyperCard's Translator Interface and
the corresponding language property?
3. Do we support XCMDs and XFCNs? This is arguably
HC's hottest feature of all. Without externals to
augment HC's access and other capabilities, HC becomes
much less interesting. If we don't support them, then
what do we provide instead? As an alternative, do we
make it ridiculously easy for users to integrate new
code segments directly into FreeCard's source?
Which brings me to my final point. MacPerl is the
Mac-specific version of the well-known multi-platform
open source programming language Perl. The core of
Perl's functionality is the same for each platform,
but MacPerl goes a step further by providing some
Mac-specific extensions/modules/packages to fully
exploit the specific advantages of the Mac.
1. Is this approach viable for us ?
2. Among the Mac-specific stuff that MacPerl provides,
there is the Open Scripting Architecture, and most of
the Toolbox too.
3. The relevance for us is that the MacPerl app and
its Mac-specific extensions/modules/packages are open
source and they are written in C/C++.
4. How realistic would it be to adapt MacPerl's source
code to give us an enormous leap forward in the
development of the Mac version of FreeCard? Or, more
generally, to adapt Perl's source code to give us an
enormous leap forward in the development of the core
(multi-platform) version of FreeCard?
5. I am NOT suggesting that FreeScript ressemble in
any way the dweeby syntax of MacPerl. I am not
necessarily suggesting we do this, but we could take
MacPerl as a starting point -> less terse -> less
dweeby -> implement HyperTalk-like FreeScript syntax
(in C) -> FreeScript
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
