Friday Finking: Limiting parameters
dn
PythonList at DancesWithMice.info
Thu Jul 23 01:20:48 EDT 2020
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
More information about the Python-list
mailing list