------art_115251_10183984.1147870292530
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

My opinion only, but when I see bang at the end of a method name, it makes
me think that it will result in some possibly dangerous change to the object
itself, rather than urgency.

Earlier I proposed Socket#nbconnect and TCPServer#nbaccept and
Socket#nbrecvfrom (I think these are ones that are most needed, the rest can
be done with sysread and syswrite. Not sure yet about datagram sends.) This
proposal has the advantage that it makes sense in English (read "nbaccept"
as "nonblocking accept") but the potential disadvantage that the methods
will bunch up together in alphabetical lists. Another possibility would be
to add "nb" as a suffix: acceptnb, connectnb, etc.

On 5/17/06, Vlad GALU <vladgalu / gmail.com> wrote:
>
> On 5/15/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> > How about Socket#nbconnect and Socket#nbaccept?
>
>    I don't know the usual meaning of the exclamation mark, but I think
> it would be nice to use it in order to separate blocking routines from
> their non-blocking counterparts. Since usually the exclamation mark
> suggests impatience, I thought that socket.connect! would be quite
> appropriate to express the idea "connect now or else!", where "else"
> may as well mean return with an error. The same thing would be nice
> for other I/O routines too.
>
>   My $0.02. Comments ?
>
>
> >
> > On 5/15/06, Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> > > Hi,
> > >
> > > In message "Re: Nonblocking socket-connect"
> > >     on Tue, 16 May 2006 00:42:39 +0900, "Francis Cianfrocca" <
> garbagecat10 / gmail.com> writes:
> > >
> > > |Well, it's ok then. I'm comfortable adding in the nonblocking
> > > |functions as an extension in my asynchronous-IO framework. If you
> > > |decide it's best to leave nonblocking i/o out of the core, then
> people
> > > |will be able to get it if necessary through my "eventmachine"
> library.
> > >
> > > Note that I'm not against for non-blocking connect.  I just oppose to
> > > general purpose non-blocking attribute for IO.  Hint: name, name.
> > >
> > >                                                         matz.
> > >
> > >
> >
> >
>
>
> --
> If it's there, and you can see it, it's real.
> If it's not there, and you can see it, it's virtual.
> If it's there, and you can't see it, it's transparent.
> If it's not there, and you can't see it, you erased it.
>
>

------art_115251_10183984.1147870292530--