NICE-ESG-Libs Digest Thu, 15 Feb 96 Volume 2 : Issue 1
Today's Topics:
Two comments
NICE Eiffel Standards Group -- Library Committee Mailing List
To post to list:
NICE-ESG-Libs@atlanta.twr.com
To send mail to the Chairman of the committee:
NICE-ESG-Libs-chair@atlanta.twr.com
Administrative matters (sign up, unsubscribe, mail problems, etc):
NICE-ESG-Libs-request@atlanta.twr.com
Date: Thu, 15 Feb 96 15:23:15 PST
From: bertrand@eiffel.com (Bertrand Meyer)
Subject: Two comments
To: nice.lib@eiffel.com
Copy to:
From: Bertrand Meyer
Mailer: BOOM
Two comments, one apparently specific and the other general, on the
library committee.
1. Proposal RB-1
----------------
I had some trouble understanding proposal RB-1, intended (I think)
to be about HASHABLE.
First, the initial message from Roger Browne
bearing that indication in the subject header was about something
totally different (exceptions), and contained no proposal
(vol.1, no. 307, 25 Nov 95). I assume this is just a typo.
The next message (25 Nov 95) does contain a proposal,
``Remove note from HASHABLE''. However it does not correspond
to anything that I can find in the version of HASHABLE that
is on the FTP server, whose text begins
indexing
description : "Values that may be hashed into an integer index, for use as
keys in hash tables."
deferred class interface
HASHABLE
feature -- Access
hash_code: INTEGER
-- Hash code value
deferred
ensure
good_hash_value : Result >= 0
end
Can anyone find fault with this?
There may have been earlier versions with restrictions on hashing
the default value etc., but certainly not in the current version.
All the previous versions, and diffs etc. are present on the FTP
server, so I can try to dig them up, but what's the point unless
there is a disagreement of substance?
2. General mode of working
--------------------------
I took a look at various proposals floated over the past couple of months.
It turns out I disagree with all the proposals I have seen (make_from_array,
whose text an invariant clause from ARRAY etc.), but that's not the main point.
We can play mini-parliament by submitting lots of little proposals all over.
Those who have the most patience (and a good eye for deadlines) win.
Others lose. In some cases the losers will be furious, especially if
they are implementers and are being forced to do something that either:
(1) they fundamentally disagree with (2) their users hate (3) they
cannot implement anyway.
I think this approach is deeply flawed. It can only foster controversy
and bad feelings. If we want to find flames on the NICE lines every
morning, that's the way to go.
This approach is bad not just politically but also technically,
because a good design is unlikely to arise from all these little
contributions. We may have the beads, but if the threads are missing
there won't be a necklace.
For the libraries the task is relatively easy to split up because the
class (or in some cases a group of related classes) is the natural unit.
We should as much as possible vote on classes, not on individual
invariant clauses, argument types, comments or even features.
Also we should also vote as a last resort; paradoxically perhaps,
I think that there are only two cases for a vote:
1- When we know in advance that all votes will be YES.
2- When there are irreconcilable differences and we must go to
battle.
Clearly, I hope never to see a case of 2 but in a political body
we should be prepared for it.
The important strategy is 1: consensus. Combining this idea with the
preceding observation, I think the library committee should work as
follows. For each class (or small group of classes) that is thought to
need changes or at least discussion, appoint a committee member -
let's call him the advocate - whose task is to devise a proposal that
will meet consensus. The advocate will go back and forth talking to
people involved - sometimes through the official mailing list,
but also through informal channels if he thinks that is more effective -
until he feels that he has brought his proposal to a state in which
everyone can vote for it. Then he submits the class as a whole for
the committee to vote on. (Or he submits a sad report that he was unable
to build such a consensus.)
At that stage, someone may still find a flaw; so the advocate may
again have to revise his proposal and resubmit it.
This is not a new model. The above almost exactly describes what
Jim McKim has been doing with ARRAY. He took the initiative himself
but has almost succeeded.
(This is also what I have been trying to do with the language committee.
For example I would hope that on the `Precursor' proposal when and if
the matter comes to a vote it will be unanimous.
This is typical of an issue in which it was essential NOT to call votes
early. We would have had competing proposals, none of which perhaps
as good as the final one. Why were we able to get to something that
we all seem to find decent? Simply because there was no deadline
pending, no vote, so that we could all simply try to exert
the best of our thinking to find a solution.)
To continue in the direction set by Jim I would suggest that the chair
appoint various people to be in charge of various classes or areas,
with a clear mandate to seek consensus. Then the chair may exercise
the position's most important privilege: when to call and not to call
votes. (By the way I think Christine was right not to call votes
on some of the recent submissions, precisely because they are too
controversial.)
I don't want to paint too rosy a picture. On some aspects true conflicts
will emerge, and we will in the end have to call a vote on which each
side will count its votes. But we should avoid those conflicts which
are not necessary. On most issues, with the time to discuss arguments,
and with the participation of an advocate for each topic - an advocate who
should have only one issue on his hands at any time, and so will have
the stamina and patience to push it through, going back to the drawing board
a hundred times if need be - I think we can reach consensus.
In some cases this will take a little more time. We should accept it
and not be bullied by the Strelioffs of the outside world into
making rushed decisions. In ETL I wrote about the moment when the
right design dawns on you with the self-evidence of morning mist,
or something to that effect. When there is a really good design we
all recognize it. Until then, we shouldn't vote.
A successful process is not measured by the number of times we vote.
For every controversial vote there is a winner and a bitter loser.
A successful process is measured by how much we produce that pleases
EVERYONE involved, and solves the problem.
I would very much be interested to know if the library committee members
agree with this view. If so I would ask Christine, in respectful disagreement
with Roger Browne, not to call votes on the latest proposals that have
surfaced, but instead to confirm Jim's self-appointment as
Amiable Array Advocate, and to issue a call for other volunteer
advocates.
With best regards,
-- BM
P.S. The second part grew bigger than what I intended; since it addresses
general issues I will repost an abbreviated version on NICE-all.
 |
