From: Adam Prescott <adam@...>
Date: 2011-12-05T10:23:03+09:00
Subject: [ruby-core:41485] Re: [ruby-trunk - Feature #5478] import Set into core, add syntax

--14dae93996c7dbe5af04b34e28f4
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 4, 2011 at 22:34, Joshua Ballanco <jballanc@gmail.com> wrote:

> Actually, the bulk of Set's functionality is already built on top of Hash.
> Personally, since the ability to create Hashes from comma-delimited
> key,value lists has been removed in 1.9, I think reintroducing it to create
> Set literals is not the worst idea in the world.
>
> Additionally, implementing Set functionality directly on top of Hash would
> remove the unfortunate method call overhead that currently exists in the
> Set library (note that the implementation of Set#include? is just a call
> through to Hash#include?):
>

This really does seem to just be an argument via implementation details. I
don't think that's the best approach. The point of implementation details
is that they're just that.

--14dae93996c7dbe5af04b34e28f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sun, Dec 4, 2011 at 22:34, Joshua Ballanco <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:jballanc@gmail.com">jballanc@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>Actually, the bulk of Set&#39;s functionality is already built on top =
of Hash. Personally, since the ability to create Hashes from comma-delimite=
d key,value lists has been removed in 1.9, I think reintroducing it to crea=
te Set literals is not the worst idea in the world.</div>



<div><br></div><div>Additionally, implementing Set functionality directly o=
n top of Hash would remove the unfortunate method call overhead that curren=
tly exists in the Set library (note that the implementation of Set#include?=
 is just a call through to Hash#include?):</div>



<div></div></blockquote></div><br><div>This really does seem to just be an =
argument via implementation details. I don&#39;t think that&#39;s the best =
approach. The point of implementation details is that they&#39;re just that=
.</div>


--14dae93996c7dbe5af04b34e28f4--