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

On 7/24/06, transfire / gmail.com <transfire / gmail.com> wrote:
>
> I promised myself I'd shut-up for awhile, maybe I still should, but I
> just couldn't help myself with this one...


So did I ;)

Today I wrote
>
>     data = data.transform
>
> but I meant to write
>
>     data = transform(data)
>
> While I knew data would be hash, I certainly didn't want to write a new
> Hash method just for this --you reserve extensions for really general
> reusable stuff, right?


I fail to see this point at 100%, I think this is what subclassing is for,
but I am really oppused to ducktyping, one needs to be, I am afraid of
things all agree on.
Well I love ducktyping but I call it protcolling and I want early checking,
and I seem to be alone.
Sorry if I go offtopic.

Besides I wanted to remain open to duck typing
> and hence any hash-like object.


Yeah great, you see that is what troubles me, it is completely cool to talk
about  hash-like object, but what is a hash-like object? Which messages must
a hash-like object respond to? All of Hash, I suppose, thus a subclass, or
only some, then we can talk about protocols again, but the failure to be
able to define the protocol just worries me.
Again very important: The failure to be able, not to have to, I am 100% for
the enabeling approach, but who enables constraints and protocol checking?

That's when it hit me. We haven't yet taken the full duck type plunge.


Good!

We've just strapped a quasi-duck onto an old oop type dog.


Poor animal.

We're still
> defining our methods base on types, not duck types.


This duck risks to get bitten into it's tail, by itself.  I  have the
feeling  that  method delegation (was this the english name (patrimoine de
mñÕhode)?) is all you are doing.
But pleas get me straight if I read you wrong.

  But what would
> defining on duck type mean intead? As it turns out it measn defining on
> method dependencies.
>
> Take #transform. Forget what "class" it belongs to. What does it do?
> For the sake of this dialog lets say it does this:


I am losing you there :(

>   def transform
>     data.to_a
>   end
>
> Simple.


Well if you say so ;)

Now, if I want to call #transform on data, all it needs to do
> is repond_to #to_a. It need not matter at all what class it is. So
> imagine if you will, that instead of "classes" and "methods", we could
> define "ducks" and "quacks".
>
>   duck to_a
>     quack transform
>        self.to_a
>     end
>   end
>
> Now anything that responded to #to_a could use #transform. I'm not sure
> how far this can be taken. Can classes be undone altogegther? But in
> anycase, it seems very cool, and I wonder what kind of overall effect
> it could have on coding?


Is this a protocol you try to define, sorry if I am too stupid to get it,
could you explain to an old dog, as a friendly duck?

T.
>
>
> Cheers
Robert


-- 
Deux choses sont infinies : l'univers et la bóÕise humaine (j'y suis, j'y
reste); en ce qui concerne l'univers, je n'en ai pas acquis la certitude
absolue.

- Albert Einstein

------art_7845_9384511.1153731396042--