Bloc Naming Suggestion
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
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."
+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."
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."
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 <nicolas.cellier.aka.nice@gmail.com> 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 <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."
participants (4)
-
Nicolas Cellier -
Sean P. DeNigris -
Stephane Ducasse -
Tudor Girba