[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reasons for withdrawal

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.





    > From: scgmille@xxxxxxxxxxxxxxxxxx

    > > You have an interface spec that gives two names to one specification.
    > > Hello?!?!  Anybody home?

    > You clearly didn't read *-get-left, *-get-right for the other
    > collection=20 types.  I will ask you again to read the SRFI
    > carefully.


We have in '*-get-{left,right}' a proposed naming convention.

Both meta-names name the same thing, according to the spec.

The spec does not provide any information on either:

	*) why an implementor should choose one name over the
           other

	*) why a system that relies on the naming convention should
           use one name in preference to the other


So, what's the point of them?   Neither users or implementors are
benefited by the distinction.

You're saying: well, look at how they're used for particular
collection types.   

Swell -- summarizing how they are used is the job of the naming
convention spec:  a job left undone in this case.

What is the value of this apparently contentless naming convention
distinction?

Why don't we also have (with the same spec):

	*-get-middle

        *-get-left-of-center

        *-get-favorite

        *-get-niftiest

	*-get-ugliest

        *-get-top

        *-get-bottom

        *-get-sideways

        *-get-easiest-to-get

        *-get-hardest-to-get

        *-get-random


or, in general:

	*-get-<meaningless-adjective>

I don't know if you've noticed but, you know, quite absent any srfi,
people regularly write code that uses naming conventions that "fit"
with intuitive expectations and emulate existing standard interfaces.
What value is there in a srfi that says "*-get-left implies some
intuitive expectations (but we won't try to say what those are).


-t