Re: [PHP-DEV] Re: __autoloading and functions
On 10/09/06, dAniel hAhler [EMAIL PROTECTED] wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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=ZEND002498amp;r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
On 9/11/06, Richard Quadling [EMAIL PROTECTED] wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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 [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
On 9/11/06, Terje Slettebø [EMAIL PROTECTED] wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
On 9/11/06, Terje Slettebø [EMAIL PROTECTED] wrote: 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 ;) Right. Well, to me, having to wrap everything in a class, just because you don't have free functions, seems like more of a workaround than anything else, and the static import a kludge to make that less inconvenient (conceptually, it doesn't make a lot of sense to me to import some class's static members into a context...). Besides, it forces you to define everything in _one_ file (unless _that_ has been changed, as well). I'm reminded of that, after having learned Java at college, and taking up C++ again, after it, I had to deprogram myself of Javaisms: I tended to use a class for everything, even if it made my design more complex and tighter coupled than necessary. For example, if I needed some functions that didn't naturally belong in a class (such as various utility functions), I'd wrap them as static members in a class called Utility. When reading up on C++, again, I realised that this was absolutely not necessary: You could simply define them as free functions in a namespace called utility... That way, they may be called unqualified (if imported with using), and may span several files. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
Hello Terje,
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. The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.
bes regards
marcus
Sunday, September 10, 2006, 5:30:54 PM, you wrote:
Hi Hannes.
Ok, so I was wrong about the cause of the symptom, good - so this is
instead another problem: No autoloading of functions... I tried a similar
example, where you switch the order of new foo() and bar() around, and
it fails, as it doesn't find the definition of bar(), since class.php hasn't
been included at this point...
Ok, new question: Autoloading of functions... Has it been considered? Any
fundamental problems with it? (Again, except for others requesting the same,
I've not found anything else about it, so pointers to any previous
discussion of this would be appreciated)
Remember that in my example, I called a factory function to get an
instance of the class, and as you show, it's possible to get that - _after_
you've instantiated the class some other way (or have it call __autoload()
in some way), but in the first call to that function, you typically haven't
instantiated the class, before...
Regards,
Terje
- Original Message -
From: Hannes Magnusson [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Sunday, September 10, 2006 4:44 PM
Subject: Re: __autoloading and functions
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
On 9/10/06, Terje Slettebø [EMAIL PROTECTED] wrote:
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...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
Hi Marcus.
Thanks for the replies, both of you. I've solved this particular problem by
having all these little functions in a file that gets included for all files
that need it.
The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.
Could I ask why not?
I can give my own thoughts to the opposite: I (and much of the programming
community, it seems) have come to that it's a perfectly reasonable way to
program, where you use the best abstractions for the task (ironically, PHP
is better than Java in this respect, as Java doesn't support free
functions). This goes under the name of multi-paradigm design
(http://www.artima.com/weblogs/viewpost.jsp?thread=167119), and aims at
avoiding the myopic view people tend to get when only one paradigm is
available to them (or familiar to them).
In fact, combining paradigms is what gives MPD much of its power, as it
enables you to do things that no single paradigm, by itself, can do.
Trying to shoehorn everything into _one_ paradigm (whether it's procedural
programming, OO, functional programming, or whether) may lead to some very
contorted designs... To paraphrase a well-known phrase: If all you know is
OO, everything will look like an object (whether or not it makes any sense).
However, I guess this discussion may not belong on internals... However, to
use this concrete example, could you tell me why e.g.:
$value=Something::something(something else); // A related issue: Is this
even OO? We're not operating on an object...
would be better than:
$value=something(something else);
The latter is less to type, which is much of the reason for it in the first
place, as well as it looking like a C++-style cast, which is how it behaves.
The first version really isn't a better alternative to new
Something(something else).
Regards,
Terje
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?
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: Hannes Magnusson [EMAIL PROTECTED];
internals@lists.php.net
Sent: Sunday, September 10, 2006 5:35 PM
Subject: Re: [PHP-DEV] Re: __autoloading and functions
Hello Terje,
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. The speed reasoning put aside we also found that procedural techniques
should not mix too much with the object oriented features.
bes regards
marcus
Sunday, September 10, 2006, 5:30:54 PM, you wrote:
Hi Hannes.
Ok, so I was wrong about the cause of the symptom, good - so this is
instead another problem: No autoloading of functions... I tried a
similar
example, where you switch the order of new foo() and bar() around,
and
it fails, as it doesn't find the definition of bar(), since class.php
hasn't
been included at this point...
Ok, new question: Autoloading of functions... Has it been considered?
Any
fundamental problems with it? (Again, except for others requesting the
same,
I've not found anything else about it, so pointers to any previous
discussion of this would be appreciated)
Remember that in my example, I called a factory function to get an
instance of the class, and as you show, it's possible to get that -
_after_
you've instantiated the class some other way (or have it call
__autoload()
in some way), but in the first call to that function, you typically
haven't
instantiated the class, before...
Regards,
Terje
- Original Message -
From: Hannes Magnusson [EMAIL PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Sunday, September 10, 2006 4:44 PM
Subject: Re: __autoloading and functions
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
On 9/10/06, Terje Slettebø [EMAIL PROTECTED] wrote:
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
Re: [PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multi-paradigm design (was: Re: [PHP-DEV] Re: __autoloading and functions)
On Sun, 10 Sep 2006, Terje Slettebø wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: __autoloading and functions
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
