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