incomplete implementation warning functions


(Will Stanton) #1

Hello,

I would like to propose functions that warn about incomplete implementations without calling NSUnimplemented/fatalError. They could provide a standard interface for reminding/warning about incomplete implementations while things are being built.

I was thinking of two utility functions:
1) NSWarnIncompleteImplementation: Prints a warning message once. Can make potential issues clear (without flooding the console), particularly for classes where most of the implementation is there, but something could fail for certain parameters/configurations.
2) NSWarnUnimplemented: prints a warning on each call, ex. in a setter that doesn’t do anything

Something like:
https://github.com/e78l/swift-corelibs-foundation/commit/f69f174ef0cfcdd32fb43912c2c88179fce07ce3

Are there are any recommendations/thoughts about incorporating these functions?

Regards,
Will Stanton


(Tony Parker) #2

Hi Will,

The reason we chose fatalError() was that we felt that the safest course of action when reaching unimplemented code was to immediately crash. If we continue instead, aren’t we putting the app into an unknown state?

- Tony

···

On Jan 21, 2016, at 2:55 AM, Will Stanton via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hello,

I would like to propose functions that warn about incomplete implementations without calling NSUnimplemented/fatalError. They could provide a standard interface for reminding/warning about incomplete implementations while things are being built.

I was thinking of two utility functions:
1) NSWarnIncompleteImplementation: Prints a warning message once. Can make potential issues clear (without flooding the console), particularly for classes where most of the implementation is there, but something could fail for certain parameters/configurations.
2) NSWarnUnimplemented: prints a warning on each call, ex. in a setter that doesn’t do anything

Something like:
https://github.com/e78l/swift-corelibs-foundation/commit/f69f174ef0cfcdd32fb43912c2c88179fce07ce3

Are there are any recommendations/thoughts about incorporating these functions?

Regards,
Will Stanton

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Will Stanton) #3

Hello Tony,

In my view, crashing immediately isn’t best when ‘most’ of the implementation is present. A function could work most of the time but still need some work – no need to always crash.
Is it possible to conditionally call NSUnimplemented, in the cases where something doesn’t work? Maybe, but it might not be worth the time to write the potentially numerous checks.

Also, I would rather see messages in the console about something which might not work over nothing (i.e. a partial implementation).
I like the current rate of review and merges, but ex. NSDateFormatter doesn’t fully implement its time/date style properties, and this appears to have led to confusion: The submitter of SR-208 https://bugs.swift.org/browse/SR-208 spent time writing up cases and investigating the Swift toolchain, when there’s a telling line in NSDateFormatter.swift saying // TODO: Set up attributes here
A function like NSWarnIncompleteImplementation(“Date formatter attributes not set”) could have saved some time (presuming the console message was understood)!

Regards,
Will Stanton

···

On Jan 21, 2016, at 1:04 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi Will,

The reason we chose fatalError() was that we felt that the safest course of action when reaching unimplemented code was to immediately crash. If we continue instead, aren’t we putting the app into an unknown state?

- Tony

On Jan 21, 2016, at 2:55 AM, Will Stanton via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hello,

I would like to propose functions that warn about incomplete implementations without calling NSUnimplemented/fatalError. They could provide a standard interface for reminding/warning about incomplete implementations while things are being built.

I was thinking of two utility functions:
1) NSWarnIncompleteImplementation: Prints a warning message once. Can make potential issues clear (without flooding the console), particularly for classes where most of the implementation is there, but something could fail for certain parameters/configurations.
2) NSWarnUnimplemented: prints a warning on each call, ex. in a setter that doesn’t do anything

Something like:
https://github.com/e78l/swift-corelibs-foundation/commit/f69f174ef0cfcdd32fb43912c2c88179fce07ce3

Are there are any recommendations/thoughts about incorporating these functions?

Regards,
Will Stanton


(Tony Parker) #4

Hi Will,

Hello Tony,

In my view, crashing immediately isn’t best when ‘most’ of the implementation is present. A function could work most of the time but still need some work – no need to always crash.
Is it possible to conditionally call NSUnimplemented, in the cases where something doesn’t work? Maybe, but it might not be worth the time to write the potentially numerous checks.

I think this is probably the right approach.

Also, I would rather see messages in the console about something which might not work over nothing (i.e. a partial implementation).
I like the current rate of review and merges, but ex. NSDateFormatter doesn’t fully implement its time/date style properties, and this appears to have led to confusion: The submitter of SR-208 https://bugs.swift.org/browse/SR-208 spent time writing up cases and investigating the Swift toolchain, when there’s a telling line in NSDateFormatter.swift saying // TODO: Set up attributes here
A function like NSWarnIncompleteImplementation(“Date formatter attributes not set”) could have saved some time (presuming the console message was understood)!

Regards,
Will Stanton

We’re in a somewhat tricky situation here where we want to enable incremental progress (and testability, so that prevents crashing), and yet I think it’s really important for users to understand when they’ve run across some code we haven’t implemented yet. I think in this case we should prioritize fixing the TODO and in future merges we should make sure it’s functional enough to work when merged, or crashes if you’re doing something that we haven’t yet implemented yet.

I find log messages tough to swallow in the end - I feel like there are so many that they become easy to ignore and therefore not as useful as we wanted in the first place…

- Tony

···

On Jan 21, 2016, at 2:27 PM, Will Stanton <willstanton1@yahoo.com> wrote:

On Jan 21, 2016, at 1:04 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi Will,

The reason we chose fatalError() was that we felt that the safest course of action when reaching unimplemented code was to immediately crash. If we continue instead, aren’t we putting the app into an unknown state?

- Tony

On Jan 21, 2016, at 2:55 AM, Will Stanton via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hello,

I would like to propose functions that warn about incomplete implementations without calling NSUnimplemented/fatalError. They could provide a standard interface for reminding/warning about incomplete implementations while things are being built.

I was thinking of two utility functions:
1) NSWarnIncompleteImplementation: Prints a warning message once. Can make potential issues clear (without flooding the console), particularly for classes where most of the implementation is there, but something could fail for certain parameters/configurations.
2) NSWarnUnimplemented: prints a warning on each call, ex. in a setter that doesn’t do anything

Something like:
https://github.com/e78l/swift-corelibs-foundation/commit/f69f174ef0cfcdd32fb43912c2c88179fce07ce3

Are there are any recommendations/thoughts about incorporating these functions?

Regards,
Will Stanton


(Will Stanton) #5

Hello Tony,

Thanks for your reply and sorry for my late one – I thought I could fix the whole file but then saw how long it was, and snow came. Oops!

I think the approach to future merges is very reasonable.
Still, I am skeptical log messages would be unbearable, especially once/run for debug.

Finally, some implementations seem hard to write without knowing how Apple Foundation does it, but I’ll save that for another day!

Regards,
Will Stanton

···

On Jan 21, 2016, at 6:38 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

We’re in a somewhat tricky situation here where we want to enable incremental progress (and testability, so that prevents crashing), and yet I think it’s really important for users to understand when they’ve run across some code we haven’t implemented yet. I think in this case we should prioritize fixing the TODO and in future merges we should make sure it’s functional enough to work when merged, or crashes if you’re doing something that we haven’t yet implemented yet.


(Tony Parker) #6

Hello Tony,

Thanks for your reply and sorry for my late one – I thought I could fix the whole file but then saw how long it was, and snow came. Oops!

I think the approach to future merges is very reasonable.
Still, I am skeptical log messages would be unbearable, especially once/run for debug.

Finally, some implementations seem hard to write without knowing how Apple Foundation does it, but I’ll save that for another day!

Sure thing. We’re happy to provide feedback on this part of course. =)

- Tony

···

On Jan 25, 2016, at 6:28 PM, Will Stanton <willstanton1@yahoo.com> wrote:

Regards,
Will Stanton

On Jan 21, 2016, at 6:38 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

We’re in a somewhat tricky situation here where we want to enable incremental progress (and testability, so that prevents crashing), and yet I think it’s really important for users to understand when they’ve run across some code we haven’t implemented yet. I think in this case we should prioritize fixing the TODO and in future merges we should make sure it’s functional enough to work when merged, or crashes if you’re doing something that we haven’t yet implemented yet.