The JADE 2022 release meets tomorrow’s business demands.
Guest
|
HistoricalComments
John Beaufoy 23/11/2017 3:22:12 PM
@Ty ? I?d be suggesting custom primitives/structures instead? ??. I don?t think default return types are too bad so would prefer a warning, but either way we?d ideally have consistent behaviour where a primitive is used that hasn?t been set beforehand. Adding a date property doesn?t see it defaulting to today, so why is it treated different as a local var?? Even if we agreed it was better to null these instead, this would be a breaking change too so maybe at best we could have another compiler warning when var date/time types are used in a method without being set first (+ default return). Ty Baen-Price 23/11/2017 10:37:04 AM Just to forestall further individual compiler warning suggestions, we believe the full gamut of compiler warnings is in order. However, we cannot practically generate compiler warnings (ie. more than one result) with the current implementation of the compiler. We have a project in place to enable this. @John, you might consider putting a JEDI in for nullable types... Paul Daigneault 23/11/2017 1:55:37 AM Ideally I'd like an error, but suspect a warning may be required in order to be backward compatible. John Beaufoy 20/11/2017 5:33:55 PM Paul - Are you proposing a warning or error? (title suggests warning, which may be more appropriate for backwards compatibility, ideally received as immediate feedback at compilation time along with leaks and anything else) John Beaufoy 20/11/2017 5:30:37 PM I've only been bitten with Date/Time return types, but that was certainly annoying! For those not aware jade returns the 'current' date/time where arguably it should return a null equivalent. |
It doesn't happen often but today I was bitten by not returning true at the end of a method because I had returned false earlier. The standard return true if successful method.
Attachments Open full size