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

[Stephen Hoffman]

On 2015-01-22 16:31:09 +0000, David Froble said:

> johnwallace4 at yahoo.co.uk wrote:
>> 
>> Or maybe just think of an object as an aggregration of data items and
>> routines to access the items. Some of the data and routines are visible
>> to the world at large, some routines and data may be considered private
>> (so that the internal implentation details of an object can be kept
>> hidden, visible only to Those Who Need to Know, whilst the outside
>> visible stuff interfaces in a known and controlled way).
> 
> Would not that description fit things such as the VMS system services?

Not really.   Well, only if you could create your own sys$getjpi with 
your own new itemcodes and also with a few itemcodes that explicitly 
overlap the OpenVMS version, and where your version will intercept all 
calls to the OpenVMS sys$getjpi version.    Your intercepted itemcodes 
might just do something like fetch the VMS itemcodes and increment the 
value returned by the VMS version of the itemcodes for instance, and be 
built largely using the VMS code for the itemcode.

You could also transparently store or return additional data, too.    
You're working with what's conceptually a wad of code and data, and not 
really with any subroutine that's "called".  This differs from what 
happens with system services.   On OS X, you "message" what are called 
"methods", and the "methods" can then perform the requested tasks.   
You can create and initialize a new object, potentially store data in 
it, and use the code associated with the object.  When the object is 
deallocated, the code is no longer available.  Your object typically 
"inherits" from another, and you can then override the behaviors and 
the code of the parent object, where you need to.

This is all rather different from traditional sequential-style 
programming; from calling system services or calling subroutines.

Given there's still a traditional computer underneath, if you drill 
into the implementation of an object-oriented environment, you'll find 
machine code, and you could certainly create all of that machine code — 
whether in BASIC or assembler — necessary to present the abstractions 
that OO programming might use.   But then you end up owning all of that 
code, and all of the abstractions.

OO is also heavily dependent on what's available in the underlying 
frameworks, and what's available in some can be quite powerful — with 
the Cocoa frameworks, you can get all sorts of data back from messages 
sent to an object containing a string, for instance.  Makes for much 
less code, particularly when compared with how much work can sometimes 
be involved with setting up for a system service or RTL call on VMS.  
Yes, there's still code underneath to do the tasks, too.

OO is pretty handy for some tasks.  Can sometimes be quite be useful 
for creating bigger applications, too.   It's not so good for other 
tasks.


>> Objects are commonly spoken about in the same sentence as classes.
> 
> Maybe that explains it.  I've never under "classes" either.

Time for some reading and some playing in your copious spare time, 
then?  Have a look at 
<http://programmers.stackexchange.com/questions/34584/how-to-explain-oop-concepts-to-a-non-technical-person> 



-- 
Pure Personal Opinion | HoffmanLabs LLC