Pre proposal for "Class extension functions"

7 years ago by Andrew Gromov — view source — reply

unread

I’m thinking a lot about potential problems. Some of them you voiced, but not
all. My message was a question of whether the topic was interesting and whether
it should be formatted as RFC.

Bring a little Javascript into PHP?

In fact, I looked at Kotlin :)

(https://kotlinlang.org/docs/reference/extensions.html)

Consider requiring that a class opt in to allowing these methods.

I don't think so.

The main point of proposal are to give developers possibility to encapsulate
util-functions into classes for calling them more clean.

Also I see some others benefits and interesting future capabilities. But I'm not
yet ready to talk about it - need to think more.

If a mixin can suddently access private properties in a foreign class

Yes, it is one of potential problems. Currently I can’t see simply way to avoid
private access.

But… On the other hand, we have a Reflection.

Need to weigh all pros and contras.

I would make the syntax use the :: delimiter rather than ->

e.g. function DateTime::localTime() { ... } But that's

'->' - object function, '::' - static function.

No need to select only one of them ;)

The patch doesn't seem to handle inheritance conflicts, though.

This is a very primitive prototype patch for demonstrating how it can work

For reference: monkey patching methods onto built-in classes is what gives

you shenanigans like the discussion about [].smoosh in Javascript.

One will say "Garbage", and the second "Treasure».

When I can do something like this in PHP:

function string.explode($a):array {

return explode($a, $this);

}

$a = "Hello world".explode(' ');

I'll get drunk with joy :)

This just opens up a ridiculously wide scope for “we can’t add

method X because of a BC break in userland code”.

Yes. This is a main argument against.

But I have something to counterpose. Extension functions used in many languages.
Kotlin, for example, announce them as killer feature (and it is). And there is
very little languages with more quivering attitude to a backward compatibility.

New functions to internal classes introduce very rare and all that you need - is
more accurate migration. Anyway if you try to declare already declared function,
then you receive compile time error.

7 years ago by Rasmus Schultz — view source — reply

unread

Bring a little Javascript into PHP?

In fact, I looked at Kotlin :)

Kotlin does not modify classes.

This sort of thing is sound in compiled languages like Kotlin and C#, where
this is really syntactic sugar for calling user-defined functions with
object-like
syntax - it's possible (and sound) only because these languages can resolve
such calls at compile-time.

In dynamic languages like JavaScript, you're literally writing to a
map of methods,
which means execution order is critical, and overwrites are possible - just two
reasons why this feature isn't sound in languages like JavaScript, and wouldn't
be in PHP either.

What's wrong with just calling a function and passing the object as argument?

In my opinion, this is the kind of pointless feature that brings nothing new and
invites inconsistent code and bikeshedding over pointless details.

7 years ago by Andrey O Gromov — view source — reply

unread

I think that it is good idea to write page on RFC wiki with detailed
descriptions, examples and motivations. I see that it can't be accepted in
nearest future, but let it be for history. :)

There is many open questions. I will try to resolve that I can.

Bring a little Javascript into PHP?
In fact, I looked at Kotlin :)
Kotlin does not modify classes.
This sort of thing is sound in compiled languages like Kotlin and C#,
where
this is really syntactic sugar for calling user-defined functions with
object-like syntax - it's possible (and sound) only because these
languages can resolve such calls at compile-time.
Yes, I understand it. At the beginning I'm trying to find way for Kotlin
style realization - function with receiver. But, unfortunately, it seems
almost impossible if keep it simple.

where this is really syntactic sugar
Exactly. I'm positioning this as syntactic sugar. And very useful sugar I
hope.

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.

What's wrong with just calling a function and passing the object as
argument?
Nothing but aesthetic sense.

For example, PDO.

Classic way:

$stmt = $db->prepare($sql);
$stmt->execute();
$oneValue = $stmt->fetch(PDO::FETCH_NUMERIC)[0]??$default;

Standart function way

function takeOne($db, $sql, $default){
//see "classic way"
return $value;
}

$oneValue = takeOne($db, $sql, $default);

This is looks not good for me.

3 arguments
no intuitive connection to $db
"takeOne" placed in global functions scope for simple utility logic.

Proxy class method. Let me do not write monstrous wrapper over PDO?

Extension function style

function PDO->takeOne($sql, $default){
//see "classic way"
return $value;
}

$oneValue = $db->takeOne($sql, $default);

Intuitive connection to $db.
"takeOne" encapsulated inside PDO class

7 years ago by Rowan Collins — view source — reply

unread

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]