Friday Finking: Limiting parameters

[dn]

On 22/07/2020 05:37, Peter J. Holzer wrote:
> On 2020-07-13 17:21:40 +1200, dn via Python-list wrote:
>> On 12/07/20 10:10 PM, Barry Scott wrote:
>>> 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)
> 
> Assigning an object in Python only copies a pointer (and may adjust some
> house-keeping info, like a reference count). So it doesn't matter
> whether the object  has 5 fields or 50. The function will only access
> those it knows about and ignore the rest.

Yes, poor choice of words in "move". Perhaps (he says rather weakly), 
think in terms of move-ing control - from the object to the function. Is 
this the best idea?

The point being that the function needs to 'know things' about the 
object, ie 'I want to make the identification line of the address so I 
must retrieve title, first-initial, family-name, ... all names which 
exist inside the object. In our example, the example-object has been 
person, so it's not big deal. What happens if in-future we develop a 
mailing-list for companies? The mail-label function now appears to be 
requiring that the company object use exactly the same attribute-names 
as person!

The obvious alternative might be to pass all three data-values (in the 
example). Now the function only needs to know what it intends to call 
the three parameters - nothing more. However, our argument-count 
increases again...

Another alternative would be to pass a method which will retrieve those 
fields from the object, delivering them in the form[at] expected by the 
function. In this case, the object provides the interface and the 
mail-label routine can get-on with what it knows best, without needing 
to know the who/what/where/how of data held by 'whatever is out-there'. 
(also, counts as only one argument!)


> One might argue that mail_label should be a method of the person object
> because it depends on the person (e.g., depending on the ethnicity of
> the person the name might be written "first_name last_name" or
> "last_name firstname"). OTOH a person may have many addresses (and an
> address shared by many people), so a function which combines a person
> and address (which therefore can't be a method of either person or
> address) may be better.
> 
> Maybe that should be treated as a model-view relationship: You have two
> models (person and address) and a view (which combines some aspects of
> both while ignoring others).

So, would this be merely "has-a" composition, or is it where other 
languages would use "interfaces"? (and if-so, what is the pythonic 
solution?)
-- 
Regards =dn