# __autoloading and functions

- Thread: https://externals.io/message/25584
- Original archive: https://news-web.php.net/php.internals/25584
- Started by tslettebo@broadpark.no on 2006-09-10T12:33:59+00:00
- Messages: 16
- 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

---

## #25584 — tslettebo@broadpark.no — 2006-09-10T12:33:59+00:00

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

Hi all.

I don't know if this has been discussed before (I've not found it from doing
a search), but if it has, please provide me with a link to the discussion.

__autoload() is very convenient, but it has one problem: While classes
defined in the __autoload() function (via an include) are accessible
globally, any functions being included are not accessible outside the
__autoload() function, making them completely inaccessible to the rest of
the system. This means that if you have a file containing a class, as well
as one or more associated functions, you won't be able to use the functions,
if the file containing the class and functions is loaded using
autoloading...

I've not found a workaround for this (except reintroducing
include_once/require_once, which defeats the whole purpose of
autoloading...), are others also experiencing problems with this, and if
not, do you a) not use any functions, or b) manage some other way?

Has there been considerations for solving this in some way?

Example:

--- email_address.php ---

class EmailAddress
{
  public function __construct($address) { ... } // Check if string contains
a valid email address
....
  private $address;
}

function email_address($address)
{
  return new EmailAddress($address);
}

---------------------------------

You may then use this like:

$address=email_address(<some string expression>);

to make the conversion to EmailAddress less "obtrusive" (simulating implicit
conversion to user-defined type).

However, this doesn't work with autoloading, so you have to either manually
include the above file, or use "new" directly:

$address=new EmailAddress(<some string expression>);

In other words, this function is not a candidate for making it a method.

The problem in this particular example would go away if there was a way to
implicitly convert from fundamental types to user-defined types, but that's
another discussion...

Regards,

Terje

---

## #25585 — Hannes Magnusson — 2006-09-10T14:44:20+00:00

URL: https://externals.io/message/25584#25585 · In reply to: #25584

Hello Terje

What are you talking about?
--class.php--
<?php
class foo {
}

function bar() {
    print "Hello World\n";
}

--foo.php--
<?php
function __autoload($class) {
    include "class.php";
}

new foo();
bar();

print "hello world";...

-Hannes


> Hi all.
>
> I don't know if this has been discussed before (I've not found it from doing
> a search), but if it has, please provide me with a link to the discussion.
>
> __autoload() is very convenient, but it has one problem: While classes
> defined in the __autoload() function (via an include) are accessible
> globally, any functions being included are not accessible outside the
> __autoload() function, making them completely inaccessible to the rest of
> the system. This means that if you have a file containing a class, as well
> as one or more associated functions, you won't be able to use the functions,
> if the file containing the class and functions is loaded using
> autoloading...
>
> I've not found a workaround for this (except reintroducing
> include_once/require_once, which defeats the whole purpose of
> autoloading...), are others also experiencing problems with this, and if
> not, do you a) not use any functions, or b) manage some other way?
>
> Has there been considerations for solving this in some way?
>
> Example:
>
> --- email_address.php ---
>
> class EmailAddress
> {
>   public function __construct($address) { ... } // Check if string contains
> a valid email address
> ....
>   private $address;
> }
>
> function email_address($address)
> {
>   return new EmailAddress($address);
> }
>
> ---------------------------------
>
> You may then use this like:
>
> $address=email_address(<some string expression>);
>
> to make the conversion to EmailAddress less "obtrusive" (simulating implicit
> conversion to user-defined type).
>
> However, this doesn't work with autoloading, so you have to either manually
> include the above file, or use "new" directly:
>
> $address=new EmailAddress(<some string expression>);
>
> In other words, this function is not a candidate for making it a method.
>
> The problem in this particular example would go away if there was a way to
> implicitly convert from fundamental types to user-defined types, but that's
> another discussion...
>
> Regards,
>
> Terje

---

## #25586 — Hannes Magnusson — 2006-09-10T14:48:26+00:00

URL: https://externals.io/message/25584#25586 · In reply to: #25585

> Hello Terje
>
> What are you talking about?
> --class.php--
> <?php
> class foo {
> }
>
> function bar() {
>     print "Hello World\n";
> }
>
> --foo.php--
> <?php
> function __autoload($class) {
>     include "class.php";
> }
>
> new foo();
> bar();
>
> print "hello world";...
Gah. I meant to say "Prints out 'hello world'"


>
> -Hannes
>
> 
> > […]
> doing
> > […]
> discussion.
> > […]
> well
> > […]
> functions,
> > […]
> contains
> > […]
> implicit
> > […]
> manually
> > […]
> to
> > […]
> that's
> > […]

---

## #25590 — Pierre — 2006-09-10T16:40:47+00:00

URL: https://externals.io/message/25584#25590

Hello,


> P.S: As an aside: Why is everybody (?) replying to both the list _and_ the
> poster? If you post, isn't it safe to assume you're actually on the list, or
> am I missing something?

It is a common usage here. Some uses nntp, other mails (and filters, etc..).

It is also nice to do not start a new thread for no obvious reason but
having another topic, it makes a mess out of the archives and is
harder to follow.

--Pierre

---

## #25593 — tslettebo@broadpark.no — 2006-09-10T16:58:58+00:00

URL: https://externals.io/message/25584#25593 · In reply to: #25590

Hi Pierre.


> > […]
the
> > […]
list, or
> > […]
>
> It is a common usage here. Some uses nntp, other mails (and filters,
etc..).

Ok. It's just that it's very unusual for mailing lists (at least the ones I
have experience with), but whatever.

> It is also nice to do not start a new thread for no obvious reason but
> having another topic, it makes a mess out of the archives and is
> harder to follow.

I'm afraid I didn't understand your point. When you say "start a thread", do
you mean changing the subject line (as I did)? It's my understanding that
people in general prefer that you change the subject line, if the topic
changes, as it otherwise makes it much harder to follow the discussion...
(and you may have to wade through a lot of postings having nothing to do
with the subject line, or miss an interesting discussion, for the same
reason).

But then again, maybe also these things work differently "here", than other
places... :)

Regards,

Terje

---

## #25594 — Derick Rethans — 2006-09-10T17:18:30+00:00

URL: https://externals.io/message/25584#25594 · In reply to: #25593

> > […]
> etc..).
> 
> Ok. It's just that it's very unusual for mailing lists (at least the 
> ones I have experience with), but whatever.

The following URL explains why it is a bad idea to mangle the reply-to 
header (like some other lists do):
http://www.unicom.com/pw/reply-to-harmful.html

> > […]
> 
> I'm afraid I didn't understand your point. When you say "start a thread", do
> you mean changing the subject line (as I did)? It's my understanding that
> people in general prefer that you change the subject line, if the topic
> changes, as it otherwise makes it much harder to follow the discussion...
> (and you may have to wade through a lot of postings having nothing to do
> with the subject line, or miss an interesting discussion, for the same
> reason).

Yup, but you should use "New Mail" and not "Reply-To" in that case as 
now the new mail appears in the same thread as the old subject.

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #25595 — dAniel hAhler — 2006-09-10T18:32:10+00:00

URL: https://externals.io/message/25584#25595

Marcus Boerger wrote:

>   it hasbeendiscussed and the conclusion is that it isfar too much of a
> slowdown for every function call and thus we are not going to implement
> it.

Maybe a dump question, but wouldn't it get considered only, AFTER PHP has
found that the function does not exist?

So, it shouldn't be a slowdown at all.

On the other hand I don't know the internals of PHP very much.


> The speed reasoning put aside we also found that procedural techniques
> should not mix too much with the object oriented features.

This may be a reason, but I for one would not think that this is "dirty".

---

## #25600 — Richard Quadling — 2006-09-11T08:06:11+00:00

URL: https://externals.io/message/25584#25600 · In reply to: #25595

> Marcus Boerger wrote:
>
> > […]
>
> Maybe a dump question, but wouldn't it get considered only, AFTER PHP has
> found that the function does not exist?
>
> So, it shouldn't be a slowdown at all.
>
> On the other hand I don't know the internals of PHP very much.
>
>
> > […]
>
> This may be a reason, but I for one would not think that this is "dirty".
>
> --
> 
> 
>
>

One way in useerland to solve this is to use an error handler to
identify non existant function calls and then use an appropriate
mechanism to find them.

The only slowdown would be when an error occurred (but acceptable).

If the functions where kept in files of their own name, then this
would be the end of function libraries and a LOT of additional files.
This could promote refactoring to take groups of related functions and
convert them to a class to allow for autoloading to work.




-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

---

## #25603 — Michael Walter — 2006-09-11T09:33:35+00:00

URL: https://externals.io/message/25584#25603 · In reply to: #25600

> One way in useerland to solve this is to use an error handler to
> identify non existant function calls and then use an appropriate
> mechanism to find them.

You can't catch fatal errors.

Regards,
Michael

---

## #25613 — Stanislav Malyshev — 2006-09-11T16:42:13+00:00

URL: https://externals.io/message/25584#25613 · In reply to: #25600

> > […]

Technically, this can be done - i.e. engine can be patched so that 
instead of throwing an error or refusing the call it would call 
appropriate function which would allow for autoloading.

However, I think autoloading functions if conceptually wrong. One rarely 
keeps functions individually separated in different files (while this is 
routinely happening - and is recommended - for classes). So, if you want 
to autoload functions you would either have to build complex tables of 
where each function lives or organize them in some well-defined modules. 
Such modules are called "classes" in OO-speak, so if you have a group of 
functions that are united by purpose and you want to autoload - why not 
to make a class out of them? And if there's just an assortment of 
unrelated functions - it would probably promote very ugly code if we 
allow to autoload them individually.

---

## #25615 — tslettebo@broadpark.no — 2006-09-11T17:40:29+00:00

URL: https://externals.io/message/25584#25615 · In reply to: #25613

> > […]
has
> > […]
>
> Technically, this can be done - i.e. engine can be patched so that
> instead of throwing an error or refusing the call it would call
> appropriate function which would allow for autoloading.
>
> However, I think autoloading functions if conceptually wrong. One rarely
> keeps functions individually separated in different files (while this is
> routinely happening - and is recommended - for classes). So, if you want
> to autoload functions you would either have to build complex tables of
> where each function lives or organize them in some well-defined modules.
> Such modules are called "classes" in OO-speak

Or "namespaces"... Or just plain "modules". Classes is not the only way to
group things, and may not be the best (namespaces can typically be
re-opened, so functions and classes belonging to a namespace can span
several files, instead of everything having to be in _one_ file).

>, so if you have a group of
> functions that are united by purpose and you want to autoload - why not
> to make a class out of them?

Why? Besides the above, because you may want to be able to call a function
like:

f();

and not:

SomeClassToWrapItAll::f();

...

Please, people: The availability of free (non-member) functions in PHP (as
in C/C++) is one advantage it has over Java, where everything _has_ to be a
class. So in Java, instead of being able to write "sqrt(<number>)", you have
to write "Math::sqrt(<number>)". Always.

And one small plea: If namespaces are added to PHP, please don't add
something like C++'s "argument-dependent lookup": It has caused no end of
problems in that camp. :)

Regards,

Terje

---

## #25616 — Stanislav Malyshev — 2006-09-11T18:04:57+00:00

URL: https://externals.io/message/25584#25616 · In reply to: #25615

> Or "namespaces"... Or just plain "modules". Classes is not the only way to
> group things, and may not be the best (namespaces can typically be
>   
Oh, of course it's not the only way. It's the only way native to PHP though.
> re-opened, so functions and classes belonging to a namespace can span
> several files, instead of everything having to be in _one_ file).
>   
Thus, how do you suppose autoloading function would know which file to
load? We are back to the "complex ugly logic" argument.
> Why? Besides the above, because you may want to be able to call a function
> like:
>
> f();
>
> and not:
>
> SomeClassToWrapItAll::f();
>   
You may call the class x if you like one-letter names :) Besides that,
saving keystrokes was never a top priority for PHP (see how elaborate
function names standard modules have). Keystrokes are cheap, clarity of
the code isn't.
> class. So in Java, instead of being able to write "sqrt(<number>)", you have
> to write "Math::sqrt(<number>)". Always.
>   
Frankly, I don't really see it as advantage or disadvantage, it's just
another way to say the same. Java, for good and for bad, is much more
organized and bureaucratic language than PHP. In PHP nobody makes you to
use classes if you don't like them, I am just saying trying to make
functions behave like they belong to class or module without either
saying "class" or "module" (i.e. include) may not be the best idea to
support.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

---

## #25617 — tslettebo@broadpark.no — 2006-09-11T18:38:32+00:00

URL: https://externals.io/message/25584#25617 · In reply to: #25616

> > […]
to
> > […]
> Oh, of course it's not the only way. It's the only way native to PHP
though.

Yes.

> > […]
> Thus, how do you suppose autoloading function would know which file to
> load? We are back to the "complex ugly logic" argument.

That's not something I've thought through: I just wanted to point out that
classes are not the only way to group things. I've quite recently started to
read the postings, here, but I intend to read up on the relevant discussions
in previous postings to the list, to know what has been discussed, and what
has come from it.

> > […]
function
> > […]
> You may call the class x if you like one-letter names :)

No thanks, I prefer readability. :)

> Besides that, saving keystrokes was never a top priority for PHP

Uah...

> (see how elaborate function names standard modules have).

Yes... "Wonderful", isn't it? :) Sorry, like I said, I'll read up on
previous discussion of things like namespaces, before jumping into a
discussion about them.

Still, just one observation...: Verbosity rarely lead to clarity, it's
rather the other way around.

> Keystrokes are cheap, clarity of the code isn't.

Clarity is very important, but always spelling things out in full may lead
to less clear code. However, I'd think this is a discussion that is more
appropriate at php-general...

> I am just saying trying to make
> functions behave like they belong to class or module without either
> saying "class" or "module" (i.e. include) may not be the best idea to
> support.

I'm not sure I follow you... In for example Java, you have packages
(modules), and you may either use the full name of a class all of the time,
such as "java.lang.Math::sqrt(...)" or "Math::sqrt(...)" (or even
"sqrt(...)", in a language supporting free functions). You seem to argue for
the first one, for "clarity"...

In either of the above cases, you specify where a function belongs, both
where it's defined, and where it's used (either through full qualification,
or a shorter one, using "import"). I'm not arguing for a function to
"magically" become a part of a class/module/whatever, if you thought so
(there's way too much "magic" in PHP as it is, and the separation between
what "implementors" can do, and what "userland" is allowed to, is not a
separation I like, either, but that's another discussion).

Regards,

Terje

---

## #25619 — Stanislav Malyshev — 2006-09-11T20:42:20+00:00

URL: https://externals.io/message/25584#25619 · In reply to: #25617

> In either of the above cases, you specify where a function belongs, both
> where it's defined, and where it's used (either through full qualification,
> or a shorter one, using "import"). I'm not arguing for a function to
> "magically" become a part of a class/module/whatever, if you thought so
>   
Then the question is how do you think this function would be used?
Because it seems to me it might promote writing very strange code with
too much
magic in it.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

---

## #25624 — Michael Walter — 2006-09-11T21:35:31+00:00

URL: https://externals.io/message/25584#25624 · In reply to: #25615

> Please, people: The availability of free (non-member) functions in PHP (as
> in C/C++) is one advantage it has over Java, where everything _has_ to be a
> class. So in Java, instead of being able to write "sqrt(<number>)", you have
> to write "Math::sqrt(<number>)". Always.

Actually, Java recently added static import to deal with that very
annoyance.... ;)

Regards,
Michael

---

## #25629 — tslettebo@broadpark.no — 2006-09-12T05:12:29+00:00

URL: https://externals.io/message/25584#25629 · In reply to: #25619

> > […]
qualification,
> > […]
> Then the question is how do you think this function would be used?

That's a very good question... One "simple" answer would be to have one file
per function, and have it work like typical class autoloaders. However, that
could be too much overhead (on many levels), having a lot of small files,
that conceptually belong together.

Maybe function autoloading isn't such an obvious feature, after all (which
was one reason for bringing it up - getting the pros and cons of it. By the
way, I've now also read in on the archive of this and the other issues
having been mentioned in this thread, such as namespaces).

Regards,

Terje