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
--
https://mail.python.org/mailman/listinfo/python-list
