[Info-vax] A SYS$ version of F$EDIT

[Stephen Hoffman]

On 2019-06-01 01:41:23 +0000, Dave Froble said:

> Well, C is going to suck, whatever ....

If I want better string handling and C-like capabilities, I'll look at C++.

As for available C and C++ dialects, Objective C and Objective C++ 
syntax and capabilities make those of OpenVMS BASIC look sad.

> So, what does F$EDIT do?
> ...


The following is one part of the documentation for the string-handling 
capabilities available in one of the C environments I'm accustomed 
to—Objective C and Objective C++—and with string-handling capabilities 
well past those of OpenVMS BASIC.

https://developer.apple.com/documentation/foundation/nsstring?language=objc


The following is completely bogus and too-quickly invented BASIC syntax 
to try to illustrate some of what is available.

declare string myfilestring
declare string mysitestring
declare string myotherstring
declare boolean mycompare

myfilestring = initWithContentsOfFile( filename="Filename", 
encoding=NSUTF8StringEncoding, error=errorLabel )

myotherstring = uppercaseString( object=myfilestring )

myotherstring = decomposedStringWithCanonicalMapping( object=myfilestring )

mysitestring = initWithContentsOfURL( url="http://example.com/", 
encoding=NSUTF8StringEncoding, error=errorLabel )
mycompare = caseInsensitiveCompare(object1=myotherstring, 
object2=myfilestring )

etc.

But if implementing this new BASIC, definitely have a look at what 
newer BASIC implementations did, and copy those.  BASIC is already 
wordy, and I'd prefer less-wordy and less glue-code.

With Objective C, Objective C++, Swift and related, it's quite possible 
to get what OpenVMS would consider strings back and those strings 
returned from the objects in various formats and encodings, as well as 
obtaining objects that can contain data loaded from URLs or from files, 
and to easily convert among native data types and objects containing 
specific sorts of data.

Most folks using OpenVMS BASIC don't—or cannot—load an entire file into 
a string. In other environments, that approach works quite well and 
saves writing a fair amount of code-shuffling code.  Bespoke code, as 
the other thread discusses.  I can treat the whole file, or the whole 
web page, or whatever the REST server referenced by the specified URL 
returns as its response, as one big string (string object), and process 
that string object as needed.  The amount of RMS record-shuffling code 
that this avoids requiring is not small.  And yes, there's a 
write-it-all-to-a-file method, too. Among other available methods.  And 
yes, the frameworks have to load and deal with the paging and the rest. 
 But that code works and works well.  And it's already written.  And 
yes, there are still cases where the scale of data involved suggests or 
encourages or requires switching to SQL or other subset-of-everything 
access operations due to performance requirements.  Even then, that 
tends to be a subset of all the file contents (objects) and strings 
(objects) I'm working with within a particular app.



-- 
Pure Personal Opinion | HoffmanLabs LLC