Avoid abbreviations: add methods error, warning, info and success

[nununo]

In light of the Clean ABAP guidelines that tells us to avoid abbreviations, would it be possible to also have methods error(), warning(), info() and successl()? Maybe as simple wrappers which call the existing ones?

[AlexandreHT]

I agree on the principle but I think we should keep the I, S, W, E, A as aliases because these are messages parameters on their own.
I'd be also in favour of adding X (by principle) and '' which is an undocumentd message type (grey led icon) that I use for recording user inputs (in RF transactions)
which would give us the following proposition:

Message type / Alias	Method name	RFC 5424 equivalent
	debug	7 - Debug
I	info	6 - Informational
S	success	5 - Notice
W	warning	4 - Warning
E	error	3 - Error
A	termination or abend or abnormal_end	2 - Critical
X	Exit	1 - Alert

References :

• https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/4e/c24da36e391014adc9fffe4e204223/frameset.htm
• https://experience.sap.com/files/guidelines/References/mess_types_en.htm
• https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.1

[kjetil-kilhavn]

I agree with the original poster, and would suggest abort as the method name for message type a.
For the sake of readability I think log->exit( ) is better than log->x( ) and even log->warning( ) is worth the extra characters.

Update: Mike undeniably has a good argument about the double meaning - so abend is probably the best and has roots all the way back to mainframes.

[pokrakam]

I'm biased towards abend because it means evening in German so it has a nice double meaning. But it's is also common enough terminology, so that gets my vote.

[kjetil-kilhavn]

Keeping the old aliases around is a hassle that just fills the logger class with more methods that forward calls. I don't think we should do that, at least not long-term.

In my initial v2 implementation I have moved the existing methods i, s, w, e, and a to a new interface zif_logger_deprecated which is included in zif_logger with aliases for the method names so nothing will break initially (since I am working in a shared development system). However, I really don't think it is worth keeping those methods - especially since the only use case I can think of is a dynamic method call that uses the message type as method name. Those should just call the add method instead....

[sandraros]

Is this issue solved now?

[kjetil-kilhavn]

Is this issue solved now?

Yes, there are now new methods 'error', 'warning' and so on.
The old methods 'e', 'w' still exist for compatibility but have been moved to a separate interface for deprecated methods. See the referenced pull request for details.