__autoloading and functions

18 years ago by tslettebo@broadpark.no — view source

unread

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

18 years ago by Hannes Magnusson — view source

unread

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

18 years ago by Hannes Magnusson — view source

unread

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

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

18 years ago by Pierre — view source

unread

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

18 years ago by tslettebo@broadpark.no — view source

unread

Hi Pierre.

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..).

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

18 years ago by Derick Rethans — view source

unread

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..).

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

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).

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

18 years ago by dAniel hAhler — view source

unread

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".

18 years ago by Richard Quadling — view source

unread

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".

--

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&r=213474731
"Standing on the shoulders of some very clever giants!"

18 years ago by Michael Walter — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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

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.

18 years ago by tslettebo@broadpark.no — view source

unread

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

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by tslettebo@broadpark.no — view source

unread

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.

Yes.

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.

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.

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 :)

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by tslettebo@broadpark.no — view source

unread

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?

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

18 years ago by Michael Walter — view source

unread

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