-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[iOS] Fix the mess we had with the logs. #208
Conversation
The initial implementation of the logs, yet usefull, it was wrong. It made it very easy to pass Logs that do have certain missing properties and methods to other classes that used those methods, resulting in runtime issues. We move to have different interfaces that will allow to say which is the minimun amonunt of methods to be implemented (ILog) or the maximun one (IFileBackedLog) so that the compiler will help us to not pass a MemoryLog or a ConsoleLog to those methods that will like to use, for example, the FullPath of the log. This might look like a breaking change for xamarin-macios, but whatever it breaks was a hidden bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great this has been taken care of, it was a runtime bomb waiting to happen
/// </summary> | ||
public interface IReadable | ||
{ | ||
StreamReader GetReader(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have this IReadable
? Why not put GetReader()
straight to IReadableLog
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seemed to be a good idea at the time, but know that you mention it, I'll remove that, lets see what happens, no the compiler helps :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are classes that just care about this interface. Gives us freedom.
@@ -8,22 +8,22 @@ | |||
|
|||
namespace Microsoft.DotNet.XHarness.iOS.Shared.Logging | |||
{ | |||
public interface ILogs : IList<ILog>, IDisposable | |||
public interface ILogs : IList<IFileBackedLog>, IDisposable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess these are then IFileBackedLogs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also wondering - why not just IFileLog
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried, less freedom :/
src/Microsoft.DotNet.XHarness.iOS.Shared/Logging/ReadableLog.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.DotNet.XHarness.iOS.Shared/Logging/ReadableLog.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Přemek Vysoký <[email protected]>
The initial implementation of the logs, yet useful, it was wrong. It
made it very easy to pass Logs that do have certain missing properties
and methods to other classes that used those methods, resulting in
runtime issues.
We move to have different interfaces that will allow to say which is the
min amount of methods to be implemented (ILog) or the max one
(IFileBackedLog) so that the compiler will help us to not pass a
MemoryLog or a ConsoleLog to those methods that will like to use, for
example, the FullPath of the log.
This might look like a breaking change for xamarin-macios, but whatever
it breaks was a hidden bug.