[Info-vax] DCL's flaws (both scripting and UI)

[Simon Clubley]

On 2015-01-19, Craig A. Berry <craigberry at nospam.mac.com> wrote:
>
> New data types and automatic data conversions would be difficult to do
> compatibly, but if the new types were all objects and there were a
> distinct object notation, it might be possible to eliminate any ambiguities.
>

I'm not seeing that as a real problem.

For example, if the lexicals start returning objects containing a set
of items instead of individual items as is currently done with the
lexicals, there's no reason why the new lexicals could not be placed in
their own package and referenced as such.

The fact the new lexicals will be returning entire objects instead of
individual strings means the calling sequence is going to change anyway.

For example, consider f$parse().

You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.

For example:

$ ! Old way
$	oname = f$parse(fname, , ,"NAME")
$	odir  = f$parse(fname, , ,"DIRECTORY")
$	otype = f$parse(fname, , ,"TYPE")
$	write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
$
$ ! New way
$	oparse = sys.o$parse(fname)
$	write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
		" type = ", oparse.type

oparse would have a type of object (and a specific type of object).
However the variables within the oparse object would be of type string
and could be used as normal.

Furthermore, one could move objects around by assigning them to other
variables and the new variable would take on the type of the object
just as happens at the moment when a variable which was originally an
integer has a string assigned to it.

The above behaviour is totally compatible with existing DCL code and
you can mix-and-match old style and new style code in the same command
procedure.

In the above example, there's no reason why you could not say

$	if oname .nes. oparse.name
$		then
$ ! Do something
$	endif

as you would be comparing two string variables. The fact one of them
is contained within an object simply does not matter.

You may not be able to use string/integer operator names within objects
in order to avoid ambiguity when parsing multi-level objects, but apart
from that, I don't see any problem with the above approach.

It would also be nice to be able to write something like:

$	queue_list = sys.o$getqui(<whatever>)
$	for queue in queue_list
$		write sys$output "queue_name = ", queue.name
$	end for

That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world