This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: A proposal for a Cygnus naming convention


>>-----Original Message-----
>>From: Robert Collins [mailto:robert.collins@itdomain.com.au]
>>Sent: Wednesday, May 08, 2002 9:56 AM
>>To: Mellman Thomas; cygwin@cygwin.com
>>Subject: RE: A proposal for a Cygnus naming convention
>>
>>
>>
>>> -----Original Message-----
>>> From: Mellman Thomas [mailto:Thomas.Mellman@icn.siemens.de] 
>>> Sent: Wednesday, May 08, 2002 4:39 PM
>>
>>> I didn't mean to say that anything needs to be changed.  It was
>>> only a suggestion for the future.  But to suggest that the registry
>>> is a black box is simply gates-ian.  That's a big advantage of unix:
>>> it doesn't try to hide things from the users.  Hopefully, cygwin
>>> developers aren't so close that they're seduced by the dark side.
>>
>>Look at it this way: The code is there, you can change it to 
>>be whatever
>>you want. So no, we're not gatesian.


You introduce another important definition of gatesian which I accept.  However, you did not recognize mine, which is to have the hubris to assume that users have no business knowing about (i.e. accessing) what they're not supposed to know about.  It's the general gatesian premise that one doesn't build on what's already there - instead, if you don't like what's offered, you go out and buy from the competition.


>>OTOH, we reserve the right to change that key name an dlocation at any
>>point, with no warning. We will keep the published API 
>>(mount.exe) up to
>>date with any changes, but you will have to syncronise 
>>yourself with any
>>changes if you access those registry values directly. And no, we won't
>>be notifying the general end user base of changes to the registry -
>>because it's not a published API.


Okay, I accept that as a practical limitation based on resources.  But
my rejection of Black Boxes above still holds.

Note that I'm *not* trying to turn the clock back on modularization and structured programming.  I also think it's okay to sometimes hack some ugly code to solve an immediate problem, as long as the interfaces are clean.

I simply recommended that we try not to drift away from easy textual processing just because Bill doesn't see any need for easy textual processing, and then as a consequence to your point, I further recommended that we not shy users away from "privileged" areas.


>>In the linux world the same applies: developers have 
>>published API's and
>>implementation API's. implementation API's are subject to 
>>change and are
>>not designed for end users to access. Whilst you can (for 
>>instance) call
>>a whole bunch of readline function calls that are designated
>>internal-only, don't be surprised if they change, and don't 
>>be surprised
>>if the developer tells you 'no thanks' to suggestions for 
>>change - after
>>those calls SHOULD NOT BE USED.


Yeah, I had no problem with your point until the capital letters.

Certainly, the developers of WINE hear you loud and clear. :)

If the Undocumented Entry Point you refer to uses concepts that are antithetical to unix and open programming, then I see no reason why users shouldn't get their two cents in as early as possible.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]