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

[David Froble]

Stephen Hoffman wrote:
> 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.

Just call me "tape drive" ....

> 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.

Can't type worth a damn 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> 
> 
> 
>