Mark, don't get me wrong. I'm not upset or angry or feel like evil is being
done behind my back. And I am truly grateful for your efforts to fix the bugs
in ooDialog and to bring it into the 21st Century by implementing the new
The vast majority of the updates to ooRexx have been pretty much no-brainers,
either because they were obvious bugs with obvious fixes, or they were logical
enhancements that while perhaps not immediately useful to the average ooRexx
programmer, they were reasonable features that were in the spirit of the language.
Those bugs/rfes that were not however, were generally discussed between the
submitter and the developer and usually resolved without input from the larger
community. Those are the very ones that should be open to wider discussion.
So I do feel that there needs to be a little more community involvement in the
RFE and bug processes. That was indeed the "broader point" I was trying to
make. The "LOAD" vs "OPEN" question happened to come up just as I was composing
a note on that topic, so you just got lucky. ;-) It was nothing personal, nor
was that particular question an especially burning one. It was just a handy
I have no doubt that all of the inconsistencies date back to antiquity. Back
then we couldn't agree on where the "close" button went on a dialog frame. But
just because someone in the dim past didn't put enough thought into a
particular keyword doesn't mean that we shouldn't try to correct the error any
time we have the chance. It is the nature of such things to entropically
diverge unless there is a strong force to maintain/regain consistency.
Case in point: RFE1747346 where the new "DescendingCaselessComparator" class had
to be renamed to "CaselessDescendingComparator" to be consistent with the
implicit name construction rules. Then there are the "EntryLine" misnomer and
"getTitle" vs. "getText" anomalies.
And I don't agree that we're "stuck with it". I'm a big fan of deprecation. :-)
Java would have never gotten off the ground if it hadn't been for the liberal
application of deprecation to every release.
The problem, as I see it, is that the two formal mechanisms to request change to
ooRexx (-bugs and -rfes) have no point at which they are exposed to anyone other
than our three primary committors. Only six of us subscribe to -rfes and 11 to
-bugs (I don't know how many read them online, but I suspect the percentage is
comparable) which means very few eyeballs are wading through those forms,
compared to the 46 folks concerned enough to subscribe to -devel. (Then again,
-devel seems to have devolved into what -users was supposed to be, quick access
to expertise, as opposed to a forum for the discussion of implementation details
of the language.) There is no Architecture Review Board before which requests
for changes must be defended and pass muster.
I'm afraid I have no easy solution, given the organic nature of an open-source
project. I am concerned, however.
On 8/12/07 03:11 Mark Miesfeld said:
> On 8/11/07, Chip Davis <chip@...> wrote:
>> This is an example of the problem of having implementation discussions on the
>> -rfes or -bugs list, and not on -devel, imho.
> I'm certainly not trying to hide anything. I'm more than happy to
> discuss things more on the oorexx-devel list.
> I'm going to have to take these points a little out of order to make
> answering them coherently easier.
>> Lee quietly made that huge point in his off-hand comment asking why the term is
>> "LOAD" and not "OPEN". I was all set to chime in "Yeah, why don't you take
>> this opportunity to align this terminology with everything else? It's a trivial
>> change to the code (even if you continue to allow a deprecated "LOAD") and you
>> will be updating the docs anyway.
> The term is "LOAD" because it has always been "LOAD". I didn't change
> it to LOAD. <grin> It's been LOAD since I used OODialog in Object
> Rexx in 1998. It may not be the best choice, but that often happens
> in software. Now, we are stuck with it.
> I saw Lee's point and I was going to reply as I have above, that it
> has always been that way. I assume the original designers thought
> they had a good reason for using it. For all I know, in 1996 LOAD may
> have been the term in favor for file dialogs.
> Lee said this:
>> BTW: Just curious why you chose the word "LOAD" when everything else uses
>> the term "OPEN"?
> I should have spoke up right away to clarify that misconception. I
> did not chose the keyword "LOAD." It was chosen by IBM over 10 years
>> Frankly, many of the features of ooRexx (esp. ooDialog) have gotten so
>> complicated that consistency in nomenclature, keywords, and other terminology
>> should be a very high priority. We've already identified several cases where
>> the name of a dialog component does not match common industry usage
>> (or sense, for that matter) causing confusion for the user. It's one thing to expect
>> the user to know the standard names for dialog components, it's another to
>> expect him to know the peculiar (even within ooDialog) name for it.
> There haven't been any changes to the nomenclature, keywords, and
> other terminology in ooDialog since IBM donated it to RexxLA. The
> inconsistencies in ooDialog are inherited.
> I've added a few features, so far, to start bringing ooDialog up to
> date with the modern Windows GUI. ooDialog, as RexxLA got it, was
> designed to work on 16-bit Windows and was not capable of using any
> new feature added to the Windows GUI in almost the last 10 years.
> In adding those features I have tried very hard to keep the
> nomenclature consistent with the existing nomenclature in ooDialog.
>> But by the time I saw the issue raised, it was moot because the fix had already
>> been committed.
> The fix was committed because there was a bug there. The default for
> the function was documented to be the File Open Dialog. In the code
> it was clear that the *intent* of the developer was that the default
> be the File Open Dialog. However, the code had a logic error in that
> it was expected that either the argument would be omitted, or it would
> be exactly LOAD or exactly SAVE. If the argument was not omitted, and
> it was not exactly LOAD, and it was not SAVE, the the Save File Dialog
> was used rather than using the *documented* default.
> If people would prefer to be able to use as a keyword OPEN, then that
> can be implemented. It has nothing to do with the bug fix. The bug
> fix *doesn't* stop us from adding OPEN as keyword. Adding OPEN as a
> keyword *doesn't* change the bug fix.
>> I'm all in favor of prompt resolution of bugs, but if there is any sort of
>> question about the way to resolve it, I think it needs to be discussed on -devel
>> .. 'Way too many changes have been made to ooRexx simply because
>> two people (submitter and committor) thought it was a good idea.
> I know you are trying to make the broader point here. Nevertheless, I
> have to say that there was no change made to ooDialog here, other than
> an incorrect, and totally unexpected behavior, was corrected.
>> I think it needs to be discussed on -devel first. As do all RFEs.
>> The rest of us find out about it after the fact.
> That's a fair point Chip. Your post here is a good starting point;
> I'm glad you brought this up. (Although, to be honest, I don't think
> you picked the right commit to be upset about. <grin>)
> Maybe more of this needs to be talked over on the RexxLA list.
> Mark Miesfeld
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> Oorexx-devel mailing list