|
|
Posted by Steve on 09/19/07 18:53
"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. ;^)
Navigation:
[Reply to this message]
|