# Make require*/include* behave like a function for returning values, and more

- Thread: https://externals.io/message/60096
- Original archive: https://news-web.php.net/php.internals/60096
- Started by Ivan Enderlin @ Hoa on 2012-04-17T19:18:41+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #60096 — Ivan Enderlin @ Hoa — 2012-04-17T19:18:41+00:00

URL: https://externals.io/message/60096#60096

Hi everyone,

I have noticed that it is not possible to do something like that:

// foo.php
<?php
return ['foo' => 'bar'];

// bar.php
<?php
var_dump((require 'foo.php')['foo']);

Array access on a require does not work: we have a parse error. Is it 
just a parser issue? Because a file can return an array without any problem.
For now, one possible solution is to write a function that requires a 
file and returns the result, such as:

// bar.php
<?php
function my_require ( $file ) { return require $file; }
var_dump(my_require('foo'.php')['foo']);

It would be nice if require (and require_once, include and include_once) 
instructions would behave like functions when returning values.
Thoughts?

In the same way, it is not possible for now to do something like that:
function f ( ) {
return function ( $msg ) {

return $msg . '!';
}
}
f()('foo');
We have a parse error again. Is it a parser issue?
It could be interesting to have this feature in PHP because file can 
return closure! It would be great to extend this syntax on require and 
others instructions, such as:

<?php
(require 'baz.php')('a message'); // chaining methods calls

Finally, what about exporting only some symbols? It could be a middle 
step between declaring classes as private, protected and public and all 
public. We can imagine somethings like:

// foo.php
<?php
class IAmPrivate { }
class IAmPublic { }

export [IAmPublic]; // or export [IAmPublic::class], please see current 
discussion about Classname::class proposition.

Here, the “export” keyword will act like “return” but it will specify 
that all declaring symbols inside the file will not be exposed outside 
the file except specified ones. It could add a “module aspect” to PHP, 
and it does not break the compatibility.

Thoughts?

Best regards.

-- 
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

---

## #60100 — Paul Dragoonis — 2012-04-17T19:31:06+00:00

URL: https://externals.io/message/60096#60100 · In reply to: #60096

I don't see any fundamental benefit to having this in PHP.
It doesn't work around any current restrictions in the language.
It just looks like extra fluffy magic that we could do without.

- Paul.

On Tue, Apr 17, 2012 at 8:18 PM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:

> Hi everyone,
>
> I have noticed that it is not possible to do something like that:
>
> // foo.php
> <?php
> return ['foo' => 'bar'];
>
> // bar.php
> <?php
> var_dump((require 'foo.php')['foo']);
>
> Array access on a require does not work: we have a parse error. Is it just
> a parser issue? Because a file can return an array without any problem.
> For now, one possible solution is to write a function that requires a file
> and returns the result, such as:
>
> // bar.php
> <?php
> function my_require ( $file ) { return require $file; }
> var_dump(my_require('foo'.php'**)['foo']);
>
> It would be nice if require (and require_once, include and include_once)
> instructions would behave like functions when returning values.
> Thoughts?
>
> In the same way, it is not possible for now to do something like that:
> function f ( ) {
> return function ( $msg ) {
>
> return $msg . '!';
> }
> }
> f()('foo');
> We have a parse error again. Is it a parser issue?
> It could be interesting to have this feature in PHP because file can
> return closure! It would be great to extend this syntax on require and
> others instructions, such as:
>
> <?php
> (require 'baz.php')('a message'); // chaining methods calls
>
> Finally, what about exporting only some symbols? It could be a middle step
> between declaring classes as private, protected and public and all public.
> We can imagine somethings like:
>
> // foo.php
> <?php
> class IAmPrivate { }
> class IAmPublic { }
>
> export [IAmPublic]; // or export [IAmPublic::class], please see current
> discussion about Classname::class proposition.
>
> Here, the “export” keyword will act like “return” but it will specify that
> all declaring symbols inside the file will not be exposed outside the file
> except specified ones. It could add a “module aspect” to PHP, and it does
> not break the compatibility.
>
> Thoughts?
>
> Best regards.
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/

---

## #60102 — Ivan Enderlin @ Hoa — 2012-04-17T19:36:57+00:00

URL: https://externals.io/message/60096#60102 · In reply to: #60100

Hi Paul,


> I don't see any fundamental benefit to having this in PHP.
Unexposed symbols can be interesting when instrumended code (for my 
concerns) or simply for security and safety reasons. So, benefits exist.

> It doesn't work around any current restrictions in the language.
What do you mean?

> It just looks like extra fluffy magic that we could do without.
No extra magic stuffs, just new interesting features. Allowing (require 
'file.php')['foo'] or (require 'file.php')('foo') is consistent with the 
fact that a file can return an array or a function. And yes, it's kind 
of syntax sugar from a certain point of view but it could improve PHP 
experience without adding any magic stuff. It's just more consistent.

No?

Cheers.

-- 
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://lifc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/