Accessing Class Method

> On Sep 17, 10:36 pm, "Steve" <no....@example.com> wrote:
>> > Btw. Try to write an OO application in a manner that would not require
>> > the require_once statement, but rather a plain require. In part,
>> > because it's faster, but mainly because it will force you to write
>> > your applications in a much straightforward manner. Maybe
>> > straightforward isn't the word here, but I'm tired as hell...
>>
>> if both main_class and html require dal.php and could be used in the same
>> script, require_once is better and produces less parsing in php...and is
>> therefore faster than php having to check if it loaded a file already or
>> not. THAT is straightforward...probably not the word you're looking for.
>


"NoDude" <nodude@gmail.com> wrote in message
news:1190059436.589239.53770@22g2000hsm.googlegrou ps.com...
>I think you're confusing require_once with require. require_once has
> to check if a file has been loaded or not, require does a
> straightforward require - hence the speed boost.


no, i'm thinking of the correct thing. and it entirely depends on what your
errors are set to before you'll get that error. i'm not a noob and i know
when and why to use either. there is NO significant speed boost using
either, but a world of problems in an oop context by not using one.

> About writing straightforward scripts. Using require instead of
> require_once will cause php to throw an error the second you try to
> redefine a class you already have (which will happen if you require a
> file with the same class declaration twice). By all all means, use
> require_once, it's a language statement, it's useful when you need to
> use it, BUT a thought out OOP should _not_ need the *_once statements.

'thought' out? that's bullshit. if you are producing truly loosely coupled
objects, you will inevitably be loading class files (requiring) where you'd
likely produce the errors because of an object's reuse! require_once is a
FORMAL means that averts those errors. if you are THINKING about oop and
thinking CLEARLY, you'd notice the pattern lends itself more to *_once than
include/require alone!

you produce a time-tested (as in speed differencial) benefit between require
and require_once that show a significant load difference, and i'll be very
suprised. either way, show me your mechanism that allows loose coupling,
loads any required resource without one class knowing whether or not another
resource is consumed by another caller/object, and is as easily implemented
as *_once, and then we'll have something to talk about.

> The flow of an OOP using a robust design paradigm (like MVC for
> instance), should allow for full knowledge of which class gets
> included where, if not you're looking at a need for a singleton, if
> that doesn't help - delegate to the method required.


sorry, php is far from a robust design paradigm when it comes to oop
(comparatively), so for now, require_once is a one-line, quick means to load
a resource without having to allow for 'full knowledge' - which is ANTI-OOP
anyway.

> Like I said, I'm not imposing the sole usage of require over require
> once (although I prefer it), I'm also not saying you should rewrite
> existing code to gain the 0.xx ms advantage of require_once over
> require.

design v. time where time == 1 nano-second. hmmm...design wins.

> What I _am_ saying is that using plain require over require once has
> solid benefits. And heck, if you can whine about his naming
> conventions, why can't I about your coding style :)

you have no idea what my coding style is. when dealing with class files that
are to be used within other class files, it is ALWAYS the best option to
require_once.

why can't you? well, first, because you don't know it. second, your
reasoning is not sound. that's why i wouldn't...but you go right ahead.

btw, why are you top-posting?

..oO(NoDude)

>By all all means, use
>require_once, it's a language statement, it's useful when you need to
>use it, BUT a thought out OOP should _not_ need the *_once statements.
>The flow of an OOP using a robust design paradigm (like MVC for
>instance), should allow for full knowledge of which class gets
>included where

Consider two entirely independent classes A and B, both relying or
inheriting from another class C. Since both A and B should be usable
without each other, both have to take care of their own dependencies and
hence have to include class C (unless you use __autoload()).

No problem with require_once, but if you just use require and want to
use both classes in the same project, you'll run into trouble.

Micha

@Steve - The term "coding style" was a very poor choice of words, what
I was referring to was require over require_once. My initial reasoning
(for myself_ to use require over requireonce came from an early
release of APC which had big issues with require_once. Maybe I'm
justifying my usage of require, claiming it to be better, but that's
how I see things. I didn't mean to criticize an y of your work (which
I've never seen anyway).

@Michael - I currently use __autoload, which is a neat shortcut,
albeit it has the same speed impact as *_once (in my case, even
greater, because of directory traversing). I did however use an AS3-
like import mechanism while I was writing php4 code. I also had
preconfigured dependencies for most of the models and pageControllers
in my applications (the total preconfigurations were not that
numerous).

How I (or Steve for that matter) include our files is not (and never
was) my point however. I was just saying and still am - Using require
over require_once makes you think of what dependencies you'll have in
any given request (every single request is unaware of the dependencies
in the previous request and has its own dependencies). It's true that
this kind of approach makes you think in terms of configuration rather
than automation (not sure if that's the word), but having to make a
delegator in every single controller (for example), makes you think
hard about what you're doing wrong (in some cases it just pisses you
off).

Let me also state that I'm a fan of automation (I would much rather
have cakePHP over symfony for example), I even use lazy loading in my
aplications. I would be nuts if I had a require 'something.php' all
over the place (which I once had, years ago).

However, I do think that making someone structure his own dependencies
(or using some method to overcome having to define them) will make him
_think_ in terms of an application, instead of a collection of
objects. Telling him, he can have a dozen files, each one having a
bunch of require_onces for all of his dependent files won't get him
much farther than continuing with the procedural style thinking, only
with objects as capsules for functions. I've seen this kind of
thinking in at least half a dozen colleagues, also in myself when I
was starting out with OOP using php (which was not very OO at the
time).

P.S. I was top-posting, because I was under the impression this is the
preferred method in this group.

Wow Usenet Groups rule this is better than a forum :D

---

I tried to test some code and here's the result:

INDEX.PHP

<?php
function __autoload($class_name) {
require_once $class_name . '.php';
}

class container {

public $database;
public $html;

function __construct() {
$this->database = new database;
$this->html = new html;
}

}

$cont = new container();
$cont->html->access_db();
?>

DATABASE.PHP:

<?php
class database {

function something() {
return 'something';
}
}
?>

HTML.PHP:

<?php
class html {

function access_db() {
print database::something();
}
}
?>

It works, 100% tested ;). As you see, HTML is statically using a
method from DATABASE without any static keywords or anything. Just
code. I had already used this method before, and I didn't remember it.
I only remembered now xD.

RageARC wrote:
> Wow Usenet Groups rule this is better than a forum :D
>
> ---
>
> I tried to test some code and here's the result:
>
> INDEX.PHP
>
> <?php
> function __autoload($class_name) {
> require_once $class_name . '.php';
> }
>
> class container {
>
> public $database;
> public $html;
>
> function __construct() {
> $this->database = new database;
> $this->html = new html;
> }
>
> }
>
> $cont = new container();
> $cont->html->access_db();
> ?>
>
> DATABASE.PHP:
>
> <?php
> class database {
>
> function something() {
> return 'something';
> }
> }
> ?>
>
> HTML.PHP:
>
> <?php
> class html {
>
> function access_db() {
> print database::something();
> }
> }
> ?>
>
> It works, 100% tested ;). As you see, HTML is statically using a
> method from DATABASE without any static keywords or anything. Just
> code. I had already used this method before, and I didn't remember it.
> I only remembered now xD.
>

Yes, it works now. But that doesn't mean this hole won't be fixed in
future releases.

If you're calling a method statically, it needs to be defined as a
static method. Otherwise you have a bug waiting to happen.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Ahem... I have a feeling I'll get shot, stabbed and hung for this,
buuuuuut... There's really no need for require_once in __autoload,
because if you've reached the __autoload function, the class is
obviously not present (no sense making php check for it a second
time). Also, if you're including from the same directory, use './'.
$class_name.'.php', that way php won't look in the includes paths.

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:sZudnZmNhrB4W3LbnZ2dnUVZ_oninZ2d@comcast.com. ..
> RageARC wrote:
>> Wow Usenet Groups rule this is better than a forum :D
>>
>> ---
>>
>> I tried to test some code and here's the result:
>>
>> INDEX.PHP
>>
>> <?php
>> function __autoload($class_name) {
>> require_once $class_name . '.php';
>> }
>>
>> class container {
>>
>> public $database;
>> public $html;
>>
>> function __construct() {
>> $this->database = new database;
>> $this->html = new html;
>> }
>>
>> }
>>
>> $cont = new container();
>> $cont->html->access_db();
>> ?>
>>
>> DATABASE.PHP:
>>
>> <?php
>> class database {
>>
>> function something() {
>> return 'something';
>> }
>> }
>> ?>
>>
>> HTML.PHP:
>>
>> <?php
>> class html {
>>
>> function access_db() {
>> print database::something();
>> }
>> }
>> ?>
>>
>> It works, 100% tested ;). As you see, HTML is statically using a
>> method from DATABASE without any static keywords or anything. Just
>> code. I had already used this method before, and I didn't remember it.
>> I only remembered now xD.
>>
>
> Yes, it works now. But that doesn't mean this hole won't be fixed in
> future releases.
>
> If you're calling a method statically, it needs to be defined as a static
> method. Otherwise you have a bug waiting to happen.

amen.

"NoDude" <nodude@gmail.com> wrote in message
news:1190120352.199784.74770@y42g2000hsy.googlegro ups.com...
> Ahem... I have a feeling I'll get shot, stabbed and hung for this,
> buuuuuut... There's really no need for require_once in __autoload,
> because if you've reached the __autoload function, the class is
> obviously not present (no sense making php check for it a second
> time). Also, if you're including from the same directory, use './'.
> $class_name.'.php', that way php won't look in the includes paths.

not shot. ;^)

it is best not to assume *anything* in programming, but be explicit all the
time. i use a config file that gets included in *every* script i write.
guess what? each script gets required once...anyway, i digress. that config
file objectifies my site's properties including path information
(site::includeDirectory)...that avoids many problems like not having to keep
the same directory structure when released to a different server and having
to reprogram for the new env. it also eliminates the problem you mention
with traversing include paths. other benefits too, but the main one being
one location to manage paths without being tied to relativism.

that's just my 0.02 usd.

..oO(NoDude)

>@Michael - I currently use __autoload, which is a neat shortcut,
>albeit it has the same speed impact as *_once (in my case, even
>greater, because of directory traversing).

I also traverse a lot of class directories, but only if the requested
class could not be found in the class cache, where the locations of all
classes are stored. In such case the cache has to be refreshed.

>How I (or Steve for that matter) include our files is not (and never
>was) my point however. I was just saying and still am - Using require
>over require_once makes you think of what dependencies you'll have in
>any given request (every single request is unaware of the dependencies
>in the previous request and has its own dependencies).

Knowing beforehand which classes will be required to handle a particular
request is pretty much impossible in my framework. The request handlers
themselves decide which of them will be responsible for answering the
request and which other objects might be necessary for doing that. It's
even possible that a handler instantiates some objects and then forwards
the request to a sub handler, which in turn might need the informations
provided by the parent handler.

>It's true that
>this kind of approach makes you think in terms of configuration rather
>than automation (not sure if that's the word), but having to make a
>delegator in every single controller (for example), makes you think
>hard about what you're doing wrong (in some cases it just pisses you
>off).

I think more about modularization and code separation. Each component is
an independent thing and takes care of its own dependencies.

>However, I do think that making someone structure his own dependencies
>(or using some method to overcome having to define them) will make him
>_think_ in terms of an application, instead of a collection of
>objects. Telling him, he can have a dozen files, each one having a
>bunch of require_onces for all of his dependent files won't get him
>much farther than continuing with the procedural style thinking, only
>with objects as capsules for functions.

Ever written Java programs? A typical Java class often starts with a
whole bunch of 'import' statements. Of course a 'require_once' is not
the same, but quite similar (IMHO).

Micha

NoDude wrote:
> Ahem... I have a feeling I'll get shot, stabbed and hung for this,
> buuuuuut... There's really no need for require_once in __autoload,
> because if you've reached the __autoload function, the class is
> obviously not present (no sense making php check for it a second
> time). Also, if you're including from the same directory, use './'.
> $class_name.'.php', that way php won't look in the includes paths.
>

No, you're correct, there's no reason to use require_once if you use
autoload.

OTOH, while require_once means you need to add another statement to your
code, the execution is faster. And it will work on any system - i.e. a
shared host with autoload disabled.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================