This page is part of the web mail archives of SRFI 106 from before July 7th, 2015. The new archives for SRFI 106 contain all messages, not just those from before July 7th, 2015.
Yes, I understand you, but I was not proposing a silver bullet. I just suggested there would be one less obstacle. There may be other obstacles, of course. (I started feeling bikeshedding, so let's end this unless there's other strong discussion...) From: Takashi Kato <ktakashi@xxxxxxxxx> Subject: Re: Sockets Layer Counter Proposal Date: Sat, 13 Oct 2012 11:42:05 +0200 >>> as or consistent names with well known names since R6RS has rename >>> import and export and R7RS will have the same mechanism. >> >> I don't get why rename import/export is related to my point. >> You're concerning that reading someone's code that renames >> identifiers defined in srfi? Well, that happens anyway, but >> in reality most people don't bother to rename them. > If I understood your point correctly, the purpose to keep the name was > prevent double looking up. If it's not, sorry ignore the below. > > Say if somebody creates a new abstract layer but just export some > variables with renamed names from the lower layer, because of the > author's preference or other APIs consistency. Then when the users > need to know what those variables mean, first they need to look up the > document for the abstract layer, if it just indicates the lower layers > document then they, again, need to look it up. > > My point of view for this problem, there is no silver bullet for it, > even if we keep the name. In reality, people try to avoid this but not > 100%, it's because in some context it might not be the same name but > the same behaviour, then proper solution could be rename it. > > With this SRFI, this might not be applied since socket APIs are > de-facto standard. > > > -- > _/_/ > Takashi Kato > E-mail: ktakashi@xxxxxxxxx