I see same kind of names in Opal exceptions
Maybe the intention was to clearly distinguish Error from Warning (proceedable), but the hierarchy tells already.

OCSemanticError
OCStoreIntoReadOnlyVariableError could be just OCStoreIntoReadOnlyVariable
OCStoreIntoSpecialVariableError -> OCStoreIntoSpecialVariable

OCSemanticWarning
OCShadowVariableWarning
OCUndeclaredVariableWarning

Note that removing the Warning suffix might lead to ambiguous names...

OCUndeclaredVariable might be confused as being a Variable.

So maybe OCVariableUndeclared or OCVariableIsUndeclared

2017-11-22 21:25 GMT+01:00 Stephane Ducasse <stepharo.self@gmail.com>:

+1

On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
> I think it��s not a bad idea.
>
> Doru
>
>> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
>>
>> What do you think about removing the #Attribute suffix from all the
>> BrTextAttribute subclasses? The names seem pretty long (e.g.
>> BrFontGenericFamilyAttribute, the longest) and IMHO `BrTextAttribute
>> subclass: #BrFontWeight` is adequately intention revealing. Thoughts?
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem understanding."
>
>
>
>
>