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

David Froble davef at tsoft-inc.com
Mon Jan 19 22:21:44 EST 2015


Simon Clubley wrote:
> On 2015-01-19, John Reagan <xyzzy1959 at gmail.com> wrote:
>> On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>>
>>> 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.
>> You mean like SYS$FILESCAN?  What's your issue with multiple calls
>> to F$PARSE?  The overhead?  You are writing in DCL after all...
>>
> 
> Using the traditional approach, the code is not nearly as concise is it
> could be. There's also the overhead of calling the lexical multiple
> times instead of just calling it once and returning an object containing
> all the parsed fields.
> 
>> And you want the lexical to populate all the fields even if you
>> aren't going to use them?  Isn't that more expensive?  Imagine the
>> overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?
>> Ugh.
>>
> 
> As computers have become faster and cheaper, the tradeoffs between
> program development time and code execution time have changed.
> 
> I see Jan-Erik has also posted a queue example in Python which does
> pretty much the same thing. If I read that code correctly, it appears
> to populate an object in a similar way to the one I am suggesting.
> 
> Simon.
> 

Then   why   not   use   the   existing   solution   ???



More information about the Info-vax mailing list