[ScriptBasic] Object orientation

[Peter Verhas]

Dear Nigel and all others who are interested in this discussion,

You have created quite a long comment on object orientation and
portability. I appreciate that and before getting into fine details I
would like to state that you have dig into the code of ScriptBasic quite
deep and understood not only the code, but most of the design ideas
behind it. You asked for comments, so here are my comments:

Comments on OO:

ScriptBasic is not an object oriented language by will. It was designed
not to be. If ever you start to feel that you need an object or class
definition in a BASIC program -- and here I mean not only ScriptBasic
but any BASIC -- you probably grew more complex than the language
support and you should start to find another programming language for
the purpose you are targeting.

However the statement above does not mean that an extension module
should never be object oriented. I can easily imagine that an external
module in the future implements some object oriented feature and the
BASIC program uses these.

I agree with you that ScriptBasic does not currently support such
extension modules, but I 

You lack syntax and a kind of reference count support inside the
interpreter. Life would be easy if all things were available readily,
sure.

Regarding syntax the answer is easy: write an internal or external
preprocessor so you can do anything.

Regarding reference count:

Creating a new variable type may not be necessary. Creating a new type
needs the alteration of some core code and may introduce a lot of bugs
affecting a lot of BASIC programs that gain nothing from this
alteration.

There is a variable type 'INTEGER' stored as a C long that can be used.
This way you may count some extra references that are not really
references but really just numbers stored in the BASIC variables, but
that is a minor issue, especially if you happen to use 'large' numbers
as handles.

This eliminates the need for a new type, but you still lack the
reference counting. However you can do that using the readily available
interfaces for the module. There are three commands that can assign non
reference value to a BASIC variable. These are LET, BYVAL and UNDEF. Any
module can rewrite these functions asking the interpreter to make a copy
of the command table and then altering the copy of the command table to
point the command implemented in the module instead of the original
command inside the interpreter. You can virtually do anything.

Comments on portability:

I would categorize portability issues into two categories:

1. When current language features can not be implemented in a certain
situation on a platform, like BINMODE. If a BASIC program opens a file
in text mode and then switches to BINMODE later you can not implement it
on Mac (or can you close and reopen and position in the file?)

2. When the current code of the commands do not support some of the
features of the platform, but does not affect the language.

In case #1 I would press hard to find acceptable workaround, like
closing and reopening the file w/o the BASIC problem knowing about it.
It may cause some problem when there are file locks registered on the
opened file. In this case the program should raise an error: BINMODE and
TEXTMODE usually happens just after opening the file anyway.

If such a workaround can not be implemented then the languge needs to be
modified in the long run.

In case #1 and #2 if any command needs to be altered there is a
possibility to make a module, configured as preloaded on the specific
platform that redefines the commands that need new code.

I have never programmed a Mac. It just happened. ScriptBasic is portable
to/from NT and on UNIX favours. No Mac and no earlier Windows variants
were targeted. This is also the reason why some have problems installing
ScriptBasic on Windows ME.

Regarding opening modes: I will include your suggestions however I will
name these modes 'input_binary', 'output_binary' and so on, instead of
writing them in two words. This eliminates altering the syntax. What
would 'binary_binary' mean? (just kidding)


>>
By the way, why is LOCK
in with the F's in the user guide's index, when it begins with 'L'?
<<

Mistake.

>>
FORK - this is very Unix-specific, and is not implemented (except in an
extension module).  This should be deprecated and removed from the main
command library.  With modern threads, forking is a rather dated concept
anyway, despite its widespread use (and fan club) on Unix.
<<

It is going to stay there unimplemented.

>>
FILEOWNER - file ownership implies a multi-user system, as most desktop
operating systems are these days.  In any case, undef is returned on
systems
that don't have the concept.  This seems a bit out of place, as file
ownership functionality usually goes with group ownership and the
ability to
change owner and group.
<<

Yes, I may implement a function that calls chgrp under UNIX and
sets/gets the group under Windows NT. However group owner of a file
under Windows NT does not really play a real role.

>>
HOSTNAME -  ...  If a system doesn't have
sockets or a machine name in another form, then a port is probably best
to
return the name of the OS.
<<

You an write a module configured preloaded that redefines the hook
function 'gethostname' on those systems.

>>
One final point: I think we made needs to create a sockets.c like we
have a
threads.c
<<

thread.c

Sockets are implemented quite compatible under Windows NT and UNIX,
though there are some specific nice featurede under Windows NT that are
not implemented under UNIX, but those are not used under ScriptBasic.

Regards,
Peter