Chip,
The trouble with this suggestion is that a simple typo could *create* a
new directory, which must then be manually deleted.
Of course one could make the same mistrake with "mkdir" itself, but
there the irror would be more obvious :-)
Les
On 2/4/2016 1:26 PM, Chip Davis wrote:
> IMHO this is a software blivet (Def: "50 kg of manure in a 40 kg bag").
>
> The DIRECTORY() function is trying to do three things with the ability
> to return only one string:
> 1. Return the current directory
> 2. Create a new directory
> 3. Change to a new directory
>
> This is at least one operation too many, because the returned string
> that makes sense for one operation does not make sense for others.
>
> I argue that is should _always_ return the current directory, because
> that is its default behavior, and to make it easy to revert to that
> directory after (potentially) changing it.
>
> That does not eliminate the possibility of indicating whether or not
> the creation of a new directory was successful.
>
> So if I had designed that routine, here is the set of behaviors:
>
> DIRECTORY() returns current directory
>
> DIRECTORY('existing-dir') returns current directory, then makes
> 'existing-dir' the current directory
>
> DIRECTORY('new_dir') returns current directory, then creates
> 'new-dir', then makes 'new-dir' the current directory IFF creation
> successful
>
> Because of the aggregation of the three operations, when changing
> directories a prudent programmer should always compare the response
> from DIRECTORY() to see if it matches the argument passed. If so, the
> operation was successful.
>
> If not, either something happened to 'existing-dir', or the creation
> of 'new-dir' was not successful. Regardless, further operations to
> that directory should not be attempted.
>
> This is no more effort that testing for a null string returned value
> and far more consistent.
>
> -Chip-
>
> On 2/4/2016 10:42 AM, Les Koehler wrote:
>> I find the Regina OS/2 Help just as confusing! First, it starts with a
>> simple declarative and non-contradictory sentence:
>>
>> ----- clip -----
>> Returns the current directory for the running process, and optionally
>> changes directory to the specified new directory.
>> ----- eclip -----
>>
>> I've seen this technique in ooRexx before and it's quite logical. It
>> provides, in one operation, the name of the directory to restore *and*
>> switches to the new (presumably valid) directory. Neat!
>>
>> However, the sentences that follow *modify* the previous declarative
>> sentence, thus creating confusion:
>>
>> ----- clip -----
>> If the new directory
>> exists, and the change to new directory succeeds, the new directory is
>> returned. If the new directory does not exist or an error occurred changing
>> to that new directory, the empty string is returned.
>> ----- eclip -----
>>
>> The original Object Rexx Beta Draft was much clearer:
>>
>> ----- clip -----
>> returns the current directory, first changing it to NewDirectory if an
>> argument is supplied and the named directory exists. If NewDirectory is
>> not specified, the name of the current directory is returned. Otherwise,
>> an attempt is made to change to the specified NewDirectory. If
>> successful, the name of the NewDirectory is returned; if an error
>> occurred, null is returned.
>> ----- eclip -----
>>
>> Maybe its just me, but this is a prime example of non-professional
>> writers trying to *improve* what an expert writer wrote to begin with!
>> Generally speaking, we should guard against such changes.
>>
>> Les
>>
>>
>>
>> On 2/4/2016 2:59 AM, Jon Wolfers wrote:
>>> Hi Bert,
>>>
>>> this thread has suddenly become quite complex and sensitive. I hope that
>>> the nuances in my reply come through.
>>>
>>> Firstly, I did see your response about your experience on VM. I would not
>>> expect VM to behave in the same way as Windows. The filesystem is
>>> different. It is nearly a quarter century since I had my hands on a VM
>>> system, but I don't remember there being a directory structure at all just
>>> filename filetype and Disk[mode] - perhaps I'm remembering wrong.
>>>
>>> Secondly, the code as you posted it doesn't demonstrate how the directory
>>> function actually behaved at that time, in fact, reading your post I can't
>>> even be certain of how you expected it to behave. I read several
>>> possibilities into this scenario, including one where the documentation was
>>> just as ambiguous then, and the interpreter writers intention was the same
>>> then as the observed behaviour today.
>>>
>>> You say "all implementations of the language should match" and you go on to
>>> establish a principle of prior precedent. Now I don't know what you mean
>>> by 'should', I would agree that *gratuitous* change should be avoided. I
>>> think that the reason that this is desirable is not because the language
>>> needs to be fixed in stone, but because changes cause programs out there to
>>> break.
>>>
>>> I don't know how the directory BIF worked on Object Rexx for OS/2 or the
>>> system interpeter on VM, but I have verified to my satisfaction by looking
>>> at the code in the ooRexx repository that the current behaviour has been
>>> present on ooRexx for Windows and Linux for at least the last eight years,
>>> and possibly more.
>>>
>>> I don't know how other interpreters work - although looking at the manuals
>>> I have for Personal Rexx & Kexx I see that they each handle this very
>>> differently. Regina appears to have a directory BIF for OS/2 only and the
>>> helpfile seems to indicate that the behaviour in Regina for OS/2 is exactly
>>> the same as what happens in ooRexx currently. I hope Mark doesn't mind,
>>> but I quote the Regina OS/2 help below.
>>>
>>> Now, given that it isn't possible to have all rexx interpreters working
>>> exactly the same, because we see such a spread of behaviour, and that the
>>> current behaviour in ooRexx for Windows and Linux has been in place for a
>>> long time, I would say that changing this behaviour to match some behaviour
>>> that might have existed on some interpreter on some platform in the past
>>> would break more currently active code than recognising that this change
>>> may have occurred in the past and that the helpfile is ambiguous and
>>> correcting the helpfile suitably.
>>>
>>> I hope that that makes my position on this clear. Sorry if it opens a can
>>> of worms.
>>>
>>> Jon
>>>
>>>
>>> Regina's Directory BIF for OS/2 helpfile:
>>>
>>>> DIRECTORY([new directory]) - (OS/2)
>>>> Returns the current directory for the running process, and optionally
>>>> changes directory to the specified new directory. If the new directory
>>>> exists, and the change to new directory succeeds, the new directory is
>>>> returned. If the new directory does not exist or an error occurred changing
>>>> to that new directory, the empty string is returned.
>>>
>>>
>>>
>>> On 4 February 2016 at 02:03, Bertram Moshier <bertrammosh...@gmail.com>
>>> wrote:
>>>
>>>> Hi Jon,
>>>>
>>>> .
>>>>> I would say that this is a documentation bug as the documentation lists
>>>>> two different behaviours which can't both be right, and the code only
>>>>> displays one of these behaviors.
>>>>
>>>>
>>>> I think my earlier email about find a VM/CMS example went though, but in
>>>> case it didn't (I sent it from a tablet). I found an example in my old
>>>> notes, while at Cray Research, Inc, of using it as:
>>>>
>>>> Current_Dir = directory(New_Dir) where New_Dir was a valid location.
>>>>
>>>> I also think I successfully used this coding using classic Rexx under OS/2
>>>> Warp, but have yet to find my old OS/2 Warp drives.
>>>>
>>>> As all implementations of the language should match and VM/CMS, OS/2 Warp,
>>>> MVS, etc all came earlier, I'd say the documentation and code both are off
>>>> in their own ways. The documentation needs to be clear, obviously. Also
>>>> the implementation should allow functions, such as the directory, to
>>>> function the same regardless.
>>>>
>>>> Would this be two bug reports or one for two areas?
>>>>
>>>> Bert.
>>>>
>>>>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
