On 2/18/18 8:16 PM, Ben Finney wrote:
Dennis Lee Bieber <wlfr...@ix.netcom.com> writes:
On Mon, 19 Feb 2018 00:09:40 +0000 (UTC), Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> declaimed the following:
Or more realistically, suppose you want your type system to ensure
that you don't lay off the wrong workers:
"employee records where the length of employment is greater than six
months but less than five years, AND the salary is greater than
$100,000 or less than $40,000, AND the average number of paid sick
days taken per year over the last three years is less than five, AND
the number of reprimands is zero in the last year and less than two
in the last five years, AND the position in the last two stack
rankings was in the top fifty percent"
That's not a data type -- that's an SQL query...
If that isn't part of the definition of the data type, then *the type
checker is not going to help* to determine whether the code lays off the
wrong workers.
Doesn't sound like the sort of thing that you should expect a Type
Checker to find.
Now, perhaps you could define a type of something like
'Layoffable_Employee' with an invariant based on the above, then the
layoff module could insist that it will only that an
Layoffable_Employee, and the type uses pre-/post- conditions to confirm
the needed conditions.
Now, somewhere in the code you probably started with an Employee, and
then to pass it to the module you will need to convert the type of the
object (it seems unlikely that such a type is inherent in most of the
rest of the code). This is why it doesn't make sense for it to be a
'Type', but more likely an attribute/predicate of the object, that the
Layoff module can confirm as a pre-condition.
The data type is still "employee"
I think you're agreeing with Steven. Static data types are not relevant
for finding most of the bugs a program can have.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
