··············@gmail.com" <·············@gmail.com> writes:
> So I decided to try shadowing push, and implementing it as a generic
> function that defaults to calling cl:push, with other methods
> specialized to do the right thing on functional data types.
Besides technical issues others mentioned, IMHO it's a bad idea
to have different specializations of the same generic functions
do different things. You wouldn't use them interchangeably anyway.
If one function changes the state of an object and the other returns
a new object with the changed state, give them different names.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Besides technical issues others mentioned, IMHO it's a bad idea
> to have different specializations of the same generic functions
> do different things. You wouldn't use them interchangeably anyway.
> If one function changes the state of an object and the other returns
> a new object with the changed state, give them different names.
Ordinarily I would agree with you. However, here I think it is an
issue of the built-in name being misleading - cl:push should be called
ncons (although non-consing cons doesnt make much sense, it does
indicate the destructive nature of the operation), or push!
Perhaps specializing cons actually would make more sense, as the
semantics are similar - return a new data structure, with this object
added to the 'front' or 'top' of the old structure. Is this what
pascal C was trying to say?
On 9282 day of my life ·············@gmail.com wrote:
> However, here I think it is an issue of the built-in name being
> misleading - cl:push should be called ncons...
n-functions /can/ modify /lists/. CL:PUSH /must/ modify /place/.
As for me, difference is big.
--
Ivan Boldyrev
Your bytes are bitten.