On 24/02/12 19:35, Kris Craig wrote:
> Could you elaborate on that a little? I.e. "as an interface for the
> call". I'm not sure what you mean by that. If you could provide a
> quick example, that would be awesome! =)
>
> --Kris
Hi Kris,
You're right it wasn't clearly expresseded. Lets see if I can improve it.
A function call is a connection between two pieces of code. The
prototype is the interface through which they communicate (a contract
between caller and callee if you prefer, although I'm only dealing with
the terms provided by the prototype, not those documented in any other way).

This interface can be quite general, "just pass two variables of any
kind", may contain several rules "the first one shall be an object of
type Cat and the second an iterator", of varying complexity "you can
provide a third parameter, but you don't need to".

Although it's a contract between two pieces, I see them as really
"belonging" to the callee, just like a mortgage, which although
negotiated by two parts, the bank has more power deciding the
conditions, and can reuse the offer to several customers.
Similarly, the prototype is defined with the function code, can be
called from multiple places, etc.
A client need may change the interface, but that ends up as a change in
the callee file.


The contract between the two pieces of code, can be quite complex, and
there are interfaces out there which shouldn't exist^W^W include doing
completetely different things if receiving an array, an object, false or
null.
Most contracts however are much more sane, expecting perhaps a User
object, a number or an array of properties.

Still, there's the possibility that the contract isn't honored, such as
being given a cheque with non-sufficient funds.
There are several approaches to that. The easier one is to assume it is
always followed, and let things break if they were not ("It was clear in
the manual that you needed to provide 50 gallons of fuel to the plane
for traveling there, as you did not, we are now in the air with an empty
tank"), but the consequences of a violation a can be quite bad, and also
hard to determine who first violated the contract.
Thus, functions -specially library code expected to be called by
careless programmers- can check by themselves that their arguments "make
sense" before proceeding on, as a way to ensure -as far as they can
assert- that the contract was followed. The equivalent would be phoning
the bank to verify that the cheque is indeed valid before handing the
three apples to the customer. It can be cumbersome, but unlike the
previous approach, you bear no risks.
Finally, typehints are like using a prepaid card, for which the bank
automatically endorses the transaction. If you were given an object for
that parameter, you know that it is the class the prototype required it
to be, because otherwise the engine (the bank) wouldn't have let it pass.
This greatly reduces verifiying work, while still asserting the
prototype prerequisites, and thus makes many people think that type
hinting is a Good Thing™.

Then there are several schools of think on what should happen when you
hand a debit card with insufficient money. Some people think that you
should be escorted out of the shop (without any items) if there's not
enough money there to pay them. Others favour that if you have enough
money in your bank account, the bank should let you continue the
transaction by drawing your money from there.
There are also those who think that the bank should also be able to
mediate for coins (non-objects).

This is just a banker list, where discussion of what should the bank do
with the very different customers (pieces of code), that pass through
it, if it's more important to let the shopping suceed or it's better to
leave the shop empty and keep hard-earned savings for the holidays :)

And that's the end of the story.
The conflict and wars over hinting will continue as breaking the
contracts is in human and such is the fate of this list, until one of
them finally wins.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to