Accessing Class Method

Michael Fesser wrote:
> .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.
>

In a properly designed framework, you can predict not only what classes
will be required, but what methods in those classes.

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

Very true. Each class is responsible for itself, and calls other
classes for other required resources.

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

Exactly.

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

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:Y9qdnVGULc4ua3LbnZ2dnUVZ_uvinZ2d@comcast.com. ..
> 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

no, it means first that you change include to require...and then you tac on
'_once' to 'require'...that's only 5 character's difference...and on the
same line as the original.

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
> Michael Fesser wrote:
>> .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.
>>
>
> In a properly designed framework, you can predict not only what classes
> will be required, but what methods in those classes.

not necessarily. what about a c++ framework for creating an STL. the
framework is usually *complete* abstraction where little is known, yes?

Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:Y9qdnVGULc4ua3LbnZ2dnUVZ_uvinZ2d@comcast.com. ..
>> 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
>
> no, it means first that you change include to require...and then you tac on
> '_once' to 'require'...that's only 5 character's difference...and on the
> same line as the original.
>
>

Not if you're depending on autoload. No include statement to change.

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

Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>> Michael Fesser wrote:
>>> .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.
>>>
>> In a properly designed framework, you can predict not only what classes
>> will be required, but what methods in those classes.
>
> not necessarily. what about a c++ framework for creating an STL. the
> framework is usually *complete* abstraction where little is known, yes?
>
>

Yep, still can. Properly designed, you will know exactly which STL
classes are required.

The key is in the design - not writing code until it works.

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

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com. ..
> Steve wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>>> Michael Fesser wrote:
>>>> .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.
>>>>
>>> In a properly designed framework, you can predict not only what classes
>>> will be required, but what methods in those classes.
>>
>> not necessarily. what about a c++ framework for creating an STL. the
>> framework is usually *complete* abstraction where little is known, yes?
>>
>>
>
> Yep, still can. Properly designed, you will know exactly which STL
> classes are required.
>
> The key is in the design - not writing code until it works.

who said anything about writing code until it works? i may have class A, B,
and C. C requires B, and A extends C...further A, and B were designed as
stand-alone, independent objects. there must be a clean way to determine
that when A, B, and C are called as resources in a single script, they
should only be defined once. also, each must specify what resources they'll
consume independently.

because of the design, which there is nothing wrong with it (say B is a base
object of a specific db implementation, C is a db consumer, and A is a
specific implementation of C), this delima is natural. it is by design, is
not faulty, and works. i'm not getting your point?

Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com. ..
>> Steve wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>>>> Michael Fesser wrote:
>>>>> .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.
>>>>>
>>>> In a properly designed framework, you can predict not only what classes
>>>> will be required, but what methods in those classes.
>>> not necessarily. what about a c++ framework for creating an STL. the
>>> framework is usually *complete* abstraction where little is known, yes?
>>>
>>>
>> Yep, still can. Properly designed, you will know exactly which STL
>> classes are required.
>>
>> The key is in the design - not writing code until it works.
>
> who said anything about writing code until it works? i may have class A, B,
> and C. C requires B, and A extends C...further A, and B were designed as
> stand-alone, independent objects. there must be a clean way to determine
> that when A, B, and C are called as resources in a single script, they
> should only be defined once. also, each must specify what resources they'll
> consume independently.
>
> because of the design, which there is nothing wrong with it (say B is a base
> object of a specific db implementation, C is a db consumer, and A is a
> specific implementation of C), this delima is natural. it is by design, is
> not faulty, and works. i'm not getting your point?
>
>

Sure. In PHP you use require_once(). In C/C++, you use #define/#ifndef
to prevent headers from being included more than once (actually they are
included the second time but the code between the #ifndef/#endif is
deleted by the preprocessor).

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

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com. ..
>>> Steve wrote:
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>>>>> Michael Fesser wrote:
>>>>>> .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.
>>>>>>
>>>>> In a properly designed framework, you can predict not only what
>>>>> classes will be required, but what methods in those classes.
>>>> not necessarily. what about a c++ framework for creating an STL. the
>>>> framework is usually *complete* abstraction where little is known, yes?
>>>>
>>>>
>>> Yep, still can. Properly designed, you will know exactly which STL
>>> classes are required.
>>>
>>> The key is in the design - not writing code until it works.
>>
>> who said anything about writing code until it works? i may have class A,
>> B, and C. C requires B, and A extends C...further A, and B were designed
>> as stand-alone, independent objects. there must be a clean way to
>> determine that when A, B, and C are called as resources in a single
>> script, they should only be defined once. also, each must specify what
>> resources they'll consume independently.
>>
>> because of the design, which there is nothing wrong with it (say B is a
>> base object of a specific db implementation, C is a db consumer, and A is
>> a specific implementation of C), this delima is natural. it is by design,
>> is not faulty, and works. i'm not getting your point?
>
> Sure. In PHP you use require_once(). In C/C++, you use #define/#ifndef
> to prevent headers from being included more than once (actually they are
> included the second time but the code between the #ifndef/#endif is
> deleted by the preprocessor).

right...so i don't think we're debating anything here. ;^)

Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
>> Steve wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com. ..
>>>> Steve wrote:
>>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>>>>>> Michael Fesser wrote:
>>>>>>> .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.
>>>>>>>
>>>>>> In a properly designed framework, you can predict not only what
>>>>>> classes will be required, but what methods in those classes.
>>>>> not necessarily. what about a c++ framework for creating an STL. the
>>>>> framework is usually *complete* abstraction where little is known, yes?
>>>>>
>>>>>
>>>> Yep, still can. Properly designed, you will know exactly which STL
>>>> classes are required.
>>>>
>>>> The key is in the design - not writing code until it works.
>>> who said anything about writing code until it works? i may have class A,
>>> B, and C. C requires B, and A extends C...further A, and B were designed
>>> as stand-alone, independent objects. there must be a clean way to
>>> determine that when A, B, and C are called as resources in a single
>>> script, they should only be defined once. also, each must specify what
>>> resources they'll consume independently.
>>>
>>> because of the design, which there is nothing wrong with it (say B is a
>>> base object of a specific db implementation, C is a db consumer, and A is
>>> a specific implementation of C), this delima is natural. it is by design,
>>> is not faulty, and works. i'm not getting your point?
>> Sure. In PHP you use require_once(). In C/C++, you use #define/#ifndef
>> to prevent headers from being included more than once (actually they are
>> included the second time but the code between the #ifndef/#endif is
>> deleted by the preprocessor).
>
> right...so i don't think we're debating anything here. ;^)
>
>

Oh no - you mean we agree on something?

STOP THE WORLD - I WANT TO GET OFF! :-)

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

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:O7adnXCaxIaoOGzbnZ2dnUVZ_uPinZ2d@comcast.com. ..
> Steve wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
>>> Steve wrote:
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com. ..
>>>>> Steve wrote:
>>>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>>>>> news:EM-dnb1p44ldZ3LbnZ2dnUVZ_rHinZ2d@comcast.com...
>>>>>>> Michael Fesser wrote:
>>>>>>>> .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.
>>>>>>>>
>>>>>>> In a properly designed framework, you can predict not only what
>>>>>>> classes will be required, but what methods in those classes.
>>>>>> not necessarily. what about a c++ framework for creating an STL. the
>>>>>> framework is usually *complete* abstraction where little is known,
>>>>>> yes?
>>>>>>
>>>>>>
>>>>> Yep, still can. Properly designed, you will know exactly which STL
>>>>> classes are required.
>>>>>
>>>>> The key is in the design - not writing code until it works.
>>>> who said anything about writing code until it works? i may have class
>>>> A, B, and C. C requires B, and A extends C...further A, and B were
>>>> designed as stand-alone, independent objects. there must be a clean way
>>>> to determine that when A, B, and C are called as resources in a single
>>>> script, they should only be defined once. also, each must specify what
>>>> resources they'll consume independently.
>>>>
>>>> because of the design, which there is nothing wrong with it (say B is a
>>>> base object of a specific db implementation, C is a db consumer, and A
>>>> is a specific implementation of C), this delima is natural. it is by
>>>> design, is not faulty, and works. i'm not getting your point?
>>> Sure. In PHP you use require_once(). In C/C++, you use #define/#ifndef
>>> to prevent headers from being included more than once (actually they are
>>> included the second time but the code between the #ifndef/#endif is
>>> deleted by the preprocessor).
>>
>> right...so i don't think we're debating anything here. ;^)
>
> Oh no - you mean we agree on something?
>
> STOP THE WORLD - I WANT TO GET OFF! :-)

lol.

hey, jerry...don't take me too seriously on all that stuff. i really don't
care about all that stuff. yes, i really do read way too much philosophy and
theology even though i am an atheist. and yes, i do hurl quite a few curse
words around when i get excited about making a point or when someone doesn't
seem to get it...its all a bunch of fluff really. i'm just a big
cocker-spaniel sometimes on topics that interest me...ready to wee
everywhere cuz something new is around. ;^)

i admire your steadfast defense of what you believe is right - not just with
regard to religion. i sometimes don't get your logic, of course...but that
is not to say you don't make good points. at least we've now covered the
topics you're not supposed to discuss when company is over...religion and
politics. now we can get back to the things completely within our control.

cheers.