> On 13 Jul 2020, at 06:21, dn via Python-list <python-list@python.org> wrote:
>
> On 12/07/20 10:10 PM, Barry Scott wrote:
>>> On 12 Jul 2020, at 00:15, DL Neil via Python-list <python-list@python.org
>>> <mailto:python-list@python.org>> wrote:
>>>
>>>> That does not necessarily mean that the function needs to know
>>>> the particular representation or form of that data. Let those be
>>>> objects with getter methods for the data you wish, and have the
>>>> function document what methods it will attempt to call. Then
>>>> any class that provides the expected methods would be suitable.
>>>
>>> +1
>>>
>>> Here, the proposal is not to pass an object per-se, but to pass a
>>> function/method ("getter method") which will deliver the requisite
>>> data-items?
>>>
>>> So, might we then find that our mailing-label routine includes something
>>> like (copy-pasting is NOT proper Python!):
>>>
>>> def mail_label( getter ):
>>> ...
>>> ( first name, middle initial, last name, house number, street name,
>>> apartment number, town, state, country, zip code ) = getter()
>>>
>>> In which case, have we not moved the "very long list" from the function def
>>> to a later line within the routine - and how is this in some way 'better'?
>>>
>> This is not the refactor that Roger's excellent rule-of-thumb implies.
>> Clearly moving the 20 positional args into a tuple is basically the same
>> code,
>> and the same maintenance problem.
>
> Agreed!
>
>
>> I'd expect to see something like this:
>> def mail_label( person, address ):
>> first_name = person.first_name
>> # or if you want a function interface
>> first_line_of_address = address.get_first_line()
>
> Does this idea move whole objects across the interface? (see earlier in the
> thread) Taking a person class as subject and a mailing-label as the
> function's object, aren't there two criticisms?
>
> 1 the function needs to know which attributes of the person and address
> objects it wants to use, cf saying 'I need street, number, town, ...'*
That is part of the requirements spec for the function - the function author
will implement against spec so will know what is needed.
>
> 2 "person" likely contains a load of data that is irrelevant to printing a
> mail-label.
The design problem we are solving is that it is easy (more maintainable) to
call the function with a small number of args that provide what is needed.
Having access to more than the minimum information is not a problem usually.
One function might only need the family-name, another function the given-name
(choose terms that match your region and culture here).
>
> Why is this preferable to using a 'getter' method, or some other approach?
The idea of getter methods is to hide the implementation details of an object
that may compute a value.
This is useful when refactoring and debugging, but can be over complex for a
simple app/object.
person.get_name_formal() vs. person.get_name_informal() could use the same
set of data combined in different ways.
>
> * your point (above) being that these need not be (say) a dozen data
> elements, but could be just-enough data, and data-combinations which identify
> the addressee and which represent the components of the address.
The app designer will have to design the API to person and address that makes
sense in the app.
Barry
--
https://mail.python.org/mailman/listinfo/python-list
