|
|
Posted by Jerry Stuckle on 09/19/07 22:37
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
==================
Navigation:
[Reply to this message]
|