From koffice  Thu Sep 30 16:59:01 1999
From: "John R. Zedlewski" <zedlwski () princeton ! edu>
Date: Thu, 30 Sep 1999 16:59:01 +0000
To: koffice
Subject: KScript ideas
X-MARC-Message: https://marc.info/?l=koffice&m=93871074110424

Ok, so I've been looking in to  writing a module for kscript, and I have a couple of ideas,
comments, and suggestions to help make KScript the easiest, most compact, useful language it
can be.
1) In functions, all variables should have "in" implied, unless otherwise stated (or all have
inout, if you're a reference passing kind of guy, Torben, whichever you think is better).  In
my view, having to specifiy "in" for every variable would be like having to specify "not a
reference or pointer" in every function in C.  I know it makes things look more like CORBA that
way, but developers would always be able to explicitly state "in" as well, and being able to
leave it off would make non-CORBA-savvy C programmers more comfortable.
2) Modularity.  It looks like this is already planned, but the widget demo doesn't import any
modules to create a bunch of Qt widgets.  Since a large number of KScript apps (e.g. KSpread),
won't frequently use Qt or KDE widgets, wouldn't it make sense to have to "import module Qt"
before using them so that the namespace and memory aren't always cluttered with unneeded bits?
Also, is there any example for how someone could create a KScript module in C++?  I saw one
example that called "import module1", but I couldn't find the implementation of module1.
3) main { } unnecessary.  I don't really know of any scripting language that makes you specify
a main explicitly; that's one of the charms of scripting: just type in three lines of code and
then run it.  Of course, if it keeps the code neater, it could be optional to specify a main
function.
If this requirement were taken out, then we could also add a -e flag to kscript like Perl has,
so that it would automatically execute a short bit of code without having to save it in a file.

4) A really kick ass Kded module that's easy to use. . .

Anybody else have thoughts?  I'd be interested in coding on some of these ideas too, if other
people think they're worthwhile.

--JRZ