Re: [gobo-eiffel-develop] Re: [exml] References: url and pipework

[Charles H. <cha...@ea...>]

Andreas Leitner wrote:

> ...
>>All these stuff can be done as augmentation to
>>GOBO project, but my feeling is that it is better
>>suited for the standard Eiffel.
>>
> 
> I`d be happier if NICE can revamp ARRAY and STRING is a reasonable amount
> of time and shortly after all Eiffel compilers adopt the new
> standard. Looking at the past this task is not to be underestimated - It's
> just with the GOBO effort: I'd like to see NICE succeed with a small job
> rather than fail with a big one.
> 
> regards,
> Andreas
> 
> 
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> http://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> 
> 

Yes.  Standards work best when they are a recognition of existing good 
practices.  My favored structure has several levels of standard, ranging 
from "somebody's interesting proposal" through "recommended practices" 
up to "required to pass acceptance tests".  But they don't all need to 
be run by Nice.  I see
Required for acceptance tests :: the compiler vendors/distributors
Recommended practices         :: Nice
Proposed Standard             :: Nice
Shared library                :: Gobo
Work in Progress              :: Gobo beta, other public betas
Interesting proposal          :: Mailing lists, newsgroups

N.B.:  I said public betas.  I mean at minimum Open Source(tm) software, 
and prefer Free Software (FSF).  Proprietary libraries/code is not 
suitable for a public standard.  It can become so at the cost of 
releasing it under an OSF or FSF license.  But code that says "This 
routine may only be used in conjucntion with..." or "You do not have 
permission to modify and redistribute this code" is essentially unuseable.

Now one could easily agrue over the details, and they don't matter much. 
  What matters is that proposals move up during a process of refinement 
and debugging.  So by the time they get to the top they are well tested, 
and reasonably efficient.

One defect of this proposed organization is that it doesn't have any 
place for "large jumps".  But in most cases that is at least as much of 
an advantage as it is a weakness.

Another defect is that it doesn't have much room for the compiler 
vendors to have their custom classes to be considered a part of the 
standard.  And I think that that's also nearly as much of an advantage 
as a defect.  Proposals handed down from on high all too often overlook 
necessary features.  And if they are proprietary, things are even worse. 
  Proprietary libraries are divisive, resist improvement, and can't be 
incorporated into a good standard.  And if there are only a couple of 
good ways to do things, they can cause the public standard to be clumsy 
and inefficient (to avoid legal problems).
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/