On Thu, 27 Sep 2018 at 16:15, Andrey O Gromov <agro...@alfabank.ru> wrote:
> > In dynamic languages like JavaScript, you're literally writing to a
> > map of methods, which means execution order is critical, and overwrites
> are possible
> Need some advice. Why execution order is critical?
> Inserting into `ce->functions_list` maked at compile time, and overwtites
> will be checked at this time too.
>
I think the execution order being referenced here is if two libraries both
declare the same extension function. Since PHP has no separate build
process, it's perfectly possible to do this:
// Library A defines extension function in a.php
function PDO->magic(){
return 'magic';
}
// Library B defines extension function in b.php
function PDO->magic(){
return 'more magic!';
}
// Code uses function in c.php
$pdo = new PDO(...);
echo $pdo->magic();
Depending on which order the files are processed, this can do one of
several things:
- c.php loaded first -> error for undefined function (fair enough)
- a.php loaded first, then c.php -> 'magic'
- b.php loaded first, then c.php -> 'more magic!'
- a.php, then b.php, then c.php -> Error when loading b.php? 'magic'
because a.php defined first? 'more magic!' because b.php overwrote the
definition?
> Extension function style
>
> function PDO->takeOne($sql, $default){
> //see "classic way"
> return $value;
> }
>
> $oneValue = $db->takeOne($sql, $default);
>
This seems like a poor example, as this would work fine with inheritance:
class Extended_PDO {
function takeOne($sql, $default){
//see "classic way"
return $value;
}
}
The only difference is that code has to opt in to use the Extended_PDO
class, but that's probably a good thing, because it makes it explicit when
you can call the new method, and gives you namespacing, autoloading,
typehinting, etc
There may be cases where this kind of "monkey patching" makes sense, but I
think a clearer use case is needed to justify the many downsides of
building it into the language.
Regards,
--
Rowan Collins
[IMSoP]
