[llvm] r200688 - Introduce SmallPtrSetImpl<T *> which allows insert, erase, count, and

[Duncan P. N. Exon Smith]

On 2014 Feb 4, at 17:00, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

> On Feb 4, 2014, at 4:06 PM, Justin Bogner <mail at justinbogner.com> wrote:
> 
>> Chandler Carruth <chandlerc at gmail.com> writes:
>>> On Tue, Feb 4, 2014 at 3:33 PM, Justin Bogner <mail at justinbogner.com> wrote:
>>> 
>>>   Chandler Carruth <chandlerc at gmail.com> writes:
>>>> Introduce SmallPtrSetImpl<T *> which allows insert, erase, count, and
>>>> iteration. This alows the majority of operations to be performed without
>>>> encoding a specific small size. It follows the model of
>>>> SmallVectorImpl<T>.
>>> 
>>>   There's a lot to be said for following the existing practice, so feel
>>>   free to ignore this, but SmallVectorImpl isn't really a very indicative
>>>   name for how it's used in the first place. It's just ubiquitous enough
>>>   that it isn't worth changing. Maybe a better name from the get-go for
>>>   SmallPtrSetImpl would be worthwhile?
>>> 
>>>   On the other hand, it probably isn't worth bikeshedding about a perfect
>>>   name for this.
>>> 
>>> I actually think a better name would be great, but I'd *much* rather
>>> consistency here given how thoroughly the current naming pattern has
>>> penetrated the codebases. For a sufficiently better name pattern I'd even be
>>> willing to broach the subject of switching the existing names over so that we
>>> can have the best of both worlds.
>>> 
>>> The annoying thing is picking a substantially more clear name. Any ideas? I
>>> don't really have many.
> 
> As a new LLVM developer, the current misleading naming scheme has bothered me.
> It would be great to be more clear here.
> 
>> If I had any good ideas I'd probably have mentioned them instead of just
>> complaining from the peanut gallery! One idea that amused me is
>> SmallishFoo, to indicate that it's less specific. Puns like that in
>> names are usually a bad sign though :)
>> 
>> I guess we'd want to go for something like UnspecifiedSmallFoo, but
>> that's getting to be a pretty long name.
>> 
>>> We could be clever and have SmallFoo<T, N> inherit from SmallFoo<T> -- if you
>>> pass the N you get the concrete derived type, if you don't, you get the basic
>>> functionality without a specific size. That is sadly the best (and worst!)
>>> idea I have....
>> 
>> This might not be terrible, though it does make it a lot harder to talk
>> about the two different things.
> 
> The name overload of SmallFoo<T, N> and SmallFoo<T> is awesome.  But terrible.
> 
> I’m not convinced these are any better, but they’re less misleading than
> SmallFooImpl<T>:
> 
> - SmallFooUnsized<T>
> - SmallFooGen<T> (or SmallFooGeneric<T> or GenericSmallFoo<T>)
> - SmallFooCommon<T>
> - BasicSmallFoo<T>

Or, SmallFooSuper<T>.