I have the following code:
index.php:
class main_class {
public $database = new DAL;
public $html = new HTML;
}
dal.php:
class DAL {
function method() {
# Code
}
}
class HTML {
function method() {
# Code
# HOW TO CALL DAL'S METHOD?
# Code
}
}
As you see, DAL and HTML are inside two variables of two classes, but
how can they interact with each other?
They can't interact, because they'll never be able to see each other.
If you want to accomplish an interaction using your current setup,
you'll have to write methods in the main_class class, which will
delegate information from one object to another.
On Sep 17, 3:13 pm, RageARC
> I have the following code:
>
> index.php:
> class main_class {
>
> public $database = new DAL;
> public $html = new HTML;
>
> }
>
> dal.php:
> class DAL {
>
> function method() {
> # Code
>
> }
> }
>
> class HTML {
>
> function method() {
> # Code
> # HOW TO CALL DAL'S METHOD?
> # Code
>
> }
> }
>
> As you see, DAL and HTML are inside two variables of two classes, but
> how can they interact with each other?
What if I statically call the other class function?
index.php:
include ('dal.php');
include ('html.php');
class main_class {
public $database = new DAL;
public $html = new HTML;
}
dal.php:
class DAL {
function method() {
# Code
}
}
html.php:
class HTML {
function method() {
# Code
DAL::method();
# Code
}
}
Does this code work???
"RageARC"
news:1190039567.080009.174300@o80g2000hse.googlegroups.com.. .
> What if I statically call the other class function?
what if? there was nothing *static* in your example revision. main_class
could be instanciated numerous times, each with its own isolated versions of
DAL and HTML...neither of which are descriptive of what they are/do, btw.
> index.php:
> include ('dal.php');
> include ('html.php');
well, first you'd need to *require* rather than include, and that only
*once*...and each class definition would need to do this rather than just
index.php. finally, what kind of name is main_class? that describes nothing
in a system that does many things. anyway, your class would look something
like:
require_once 'dal.php';
require_once 'html.php';
class main_class
{
public static $db = null;
public static $html = '';
private function __contstruct()
{
self::$db = new DAL();
self::$html = new HTML();
}
public static function initialize(){};
}
?>
> Does this code work???
work? dunno, did you test it? ;^)
this should:
index.php
require_once 'main.vaguely.named.class.php';
main_class::initialze();
print_r(main_class::$db);
print_r(main_class::$html);
?>
Well, Steve, I called it main_class just for an example purpose. The
fact is this is supposed to be a class that holds several class in
only one, so I could call:
$main_class->database->method($args);
$main_class->html->make_form($args);
Understood? I think this is much better than having several variables
for different classes, as it groups the whole functionality of all
classes into only one variable. If you find there is a way to do this
better, please, do tell me.
"RageARC"
news:1190049520.484592.326400@57g2000hsv.googlegroups.com...
> Well, Steve, I called it main_class just for an example purpose. The
> fact is this is supposed to be a class that holds several class in
> only one, so I could call:
>
> $main_class->database->method($args);
> $main_class->html->make_form($args);
if main is static, only the syntaxt would change:
main::db->method
if dal is static as well, then:
main::db::interface();
> Understood? I think this is much better than having several variables
> for different classes, as it groups the whole functionality of all
> classes into only one variable. If you find there is a way to do this
> better, please, do tell me.
true, however if that's the only way you allow access to them, then you
loose the ability to reuse part or all of their functionality. that may be
no big deal in reality, and i can't tell from your example, however that
should always be a consideration when making such choices in design.
i did neglect to see your html code where it consumes dal. you'd want to
require_once 'dal.php'. whether or not you make dal or html statically
interfaced is up to you. nothing says you can't create a dal when html is
constructed. the main class c/would kick all of that off when you
constructed it via the initialize() function. that would allow you to reuse
the dal and html classes independently but still get the result you're
looking for when called via the static main_class object. clear as mud?
make sense?
btw, i was giving you a hard time about the names...no biggie.
Well I wouldn't lose reusability as all the classes are supposed to
work together for main_class, thus providing a set of functions
available in one single variable. It is built to be that way.
I think I am gonna use that code I have posted. Seems to be better.
And I never called my class functions static and I still could call
them statically :S.
By the looks of it, you're looking for the singleton pattern.
final class Singleton{
private static $sql;
private static $dao;
private static $smarty;
public static function getSql(){
if(!isset(self::$sql)){
require CLASS_DIR.'Sql.php';
self::$sql = new Sql;
}
return self::$sql;
}
public static function getDao(){
if(!isset(self::$dao)){
require CLASS_DIR.'Dao.php';
self::$dao = new Dao;
}
return self::$dao;
}
public static function getSmarty(){
if(!isset(self::$smarty)){
require SMARTY_DIR.'Smarty.class.php';
self::$smarty = new Smarty;
//some config stuff
}
return self::$smarty;
}
//prevent construction/cloning
public function __construct(){
trigger_error("Singleton instantiation not allowed", E_USER_ERROR);
}
public function __clone(){
trigger_error("Singleton cloning not allowed", E_USER_ERROR);
}
}
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...
On Sep 17, 9:18 pm, RageARC
> Well I wouldn't lose reusability as all the classes are supposed to
> work together for main_class, thus providing a set of functions
> available in one single variable. It is built to be that way.
>
> I think I am gonna use that code I have posted. Seems to be better.
> And I never called my class functions static and I still could call
> them statically :S.
> 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.
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.
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.
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.
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.
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 :)
On Sep 17, 10:36 pm, "Steve"
> > 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.
> On Sep 17, 10:36 pm, "Steve"
>> > 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"
news:1190059436.589239.53770@22g2000hsm.googlegroups.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
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:
class database {
function something() {
return 'something';
}
}
?>
HTML.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
>
>
> 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:
>
>
> class database {
>
> function something() {
> return 'something';
> }
> }
> ?>
>
> HTML.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"
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
>>
>>
>> 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:
>>
>>
>> class database {
>>
>> function something() {
>> return 'something';
>> }
>> }
>> ?>
>>
>> HTML.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"
news:1190120352.199784.74770@y42g2000hsy.googlegroups.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
==================
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"
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"
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"
> 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"
> 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"
news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle"
>> 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"
> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com...
>> Steve wrote:
>>> "Jerry Stuckle"
>>> 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"
news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle"
>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com...
>>> Steve wrote:
>>>> "Jerry Stuckle"
>>>> 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"
> news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
>> Steve wrote:
>>> "Jerry Stuckle"
>>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com...
>>>> Steve wrote:
>>>>> "Jerry Stuckle"
>>>>> 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"
news:O7adnXCaxIaoOGzbnZ2dnUVZ_uPinZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle"
>> news:Iv-dndOy1f4s-GzbnZ2dnUVZ_g2dnZ2d@comcast.com...
>>> Steve wrote:
>>>> "Jerry Stuckle"
>>>> news:cuadnUz5QPKby23bnZ2dnUVZ_hKdnZ2d@comcast.com...
>>>>> Steve wrote:
>>>>>> "Jerry Stuckle"
>>>>>> 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.