[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sockets Layer Counter Proposal
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