Email list hosting service & mailing list manager


Re: Sockets Layer Counter Proposal Shiro Kawai 13 Oct 2012 10:22 UTC

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 <xxxxxx@ymail.com>
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: xxxxxx@ymail.com