In Opal I would keep it because this is about error and warning and
you are not all the time manipulating them
while for Bloc as soon as you use text you will have to.
On Wed, Nov 22, 2017 at 9:37 PM, Nicolas Cellier
<
[hidden email]> wrote:
> 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 <
[hidden email]>:
>>
>> +1
>>
>>
>> On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba <
[hidden email]> wrote:
>> > I think it’s not a bad idea.
>> >
>> > Doru
>> >
>> >> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris <
[hidden email]>
>> >> 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."
>> >
>> >
>> >
>> >
>> >
>>
>
Locked
