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