SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 87
  1. #51
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No it doesn't. Presumably they would be static methods in the class, so they are just as much in the global namespace as a function.
    I disagree.

    Static methods might be in the global scope, but they do not share the global namespace.

    Code:
    class Test{
      function doSomething();
    }
    
    function doSomething();
    No namespace collisions...

    Cheers,
    Alex
    The only constant in software is change itself

  2. #52
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PCSpectra View Post
    I disagree.

    Static methods might be in the global scope, but they do not share the global namespace.

    Code:
    class Test{
      function doSomething();
    }
    
    function doSomething();
    No namespace collisions...

    Cheers,
    Alex
    And how exactly is doSomething() static...
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  3. #53
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arrrms View Post
    The only clear benefit I see to using classes for libraries is the organization they provide. Am I missing something? What are your thoughts on this?
    Well that is THE number one benefit of Sotware Architecture. If you work alone or on a small project it may not matter so much but when working with a corporate team on a big project organization does matter or it will become a mess.

  4. #54
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    It works, and there isn't a problem with using it, but I just prefer reading isempty() - when I'm reading the code back, I know I am checking that something is empty, rather than something being false, or 0, or whatever. Makes it much clearer what the code is doing.
    Except that your function doesn't check that something is empty. empty will return false on an unset variable, your custom isempty will trigger a warning. So really - what your function is doing is to cast the variable to a boolean and then negate it. It is exactly the same as sticking a ! in front of whatever you're checking. I fail to see how wrapping not in a non-standard replacement improves readability.

  5. #55
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I personally dislike the use of if($var) and if(!$var) for variable types other than boolean. I find it's too ambiguous. If you jump into a project and are trying to hunt down a bug, running across a line like if(!$list) probably will mean nothing to you. It could mean if the array $list is empty or if the filename pointing to a list, $list, is an empty string or if the integer length, $list, of the list is 0 or if we should provide a list, as indicated by the boolean $list... and so on.

    I like Stormrider's idea of isempty(), although it obviously is not a valid replacement for empty(). I frequently have sections of code like this:
    PHP Code:
    $var $something->returnSomething(); // argh@empty
    if(!empty($var))
    {
        
    // ... 
    I also use two functions, issetor() and emptyor(), which provide a quicker way to write isset($var) ? $var : $string. These also don't handle unset variables quite right. The variables are passed by reference, which will set the variables to null or an empty string or something if they're not set. (I can't remember how exactly, but they set the unset.) This is documented, though, and I just live with it. Now I'm thinking about adding an isemptyor().

    In response to the original question, I sort of do both, but there's normally a semi-valid reason to create the class (like the Response class that houses redirect(), etc.).

  6. #56
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig View Post
    I personally dislike the use of if($var) and if(!$var) for variable types other than boolean. I find it's too ambiguous. If you jump into a project and are trying to hunt down a bug, running across a line like if(!$list) probably will mean nothing to you. It could mean if the array $list is empty or if the filename pointing to a list, $list, is an empty string or if the integer length, $list, of the list is 0 or if we should provide a list, as indicated by the boolean $list... and so on.

    I like Stormrider's idea of isempty(), although it obviously is not a valid replacement for empty(). I frequently have sections of code like this:
    PHP Code:
    $var $something->returnSomething(); // argh@empty
    if(!empty($var))
    {
        
    // ... 
    I also use two functions, issetor() and emptyor(), which provide a quicker way to write isset($var) ? $var : $string. These also don't handle unset variables quite right. The variables are passed by reference, which will set the variables to null or an empty string or something if they're not set. (I can't remember how exactly, but they set the unset.) This is documented, though, and I just live with it. Now I'm thinking about adding an isemptyor().

    In response to the original question, I sort of do both, but there's normally a semi-valid reason to create the class (like the Response class that houses redirect(), etc.).
    If if(!$var) doesn't mean anything to you, I would suggest revisiting the documentation because its meaning should have no ambiguity.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  7. #57
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    If if(!$var) doesn't mean anything to you, I would suggest revisiting the documentation because its meaning should have no ambiguity.
    Right. If you read the documentation, you'll know that if the method or function returns either the integer 0, an empty string '', or the boolean false, a ! negate this into the boolean value true.

    You're right: ! $var and ! functioncall should mean something to every php developer. The only problem with using ! is that it can mean that the function returned on of the things noted above. For example: preg_match may return false when complication of your regular expression has failed, for example because you forgot to preg_quote a value.

    It may also return 0, as in "no matches". Using only the !, you will not know which of the situations have occured. In short, using the "!" to typejuggle to a boolean and negating it isn't something you shouldn't use, but if you do use it, you'll have to be aware of the possible return values from the method you've called or the content of the variable.

    Or, that's what I think

  8. #58
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webaddictz View Post
    The only problem with using ! is that it can mean that the function returned on of the things noted above.
    So don't create functions that can return mixed types. Its a bad design, if your function can both return an empty string and a boolean. Notwithstanding that the core php api contains plenty of examples of this. In those cases, I would explicitly check on the type (strict comparison).

    Quote Originally Posted by webaddictz View Post
    For example: preg_match may return false when complication of your regular expression has failed, for example because you forgot to preg_quote a value.
    Bad example. preg_match will raise a warning in that case.

  9. #59
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    So don't create functions that can return mixed types. Its a bad design, if your function can both return an empty string and a boolean.
    Well, I surely wouldn't create a function that behaves that way, nor do I see the need to create a function with that behaviour.

    Quote Originally Posted by kyberfabrikken View Post
    Notwithstanding that the core php api contains plenty of examples of this. In those cases, I would explicitly check on the type (strict comparison).
    My point exactly: it's not my functions I'm worried about, it's those that are written by others (in some cases, functions from the php core). It's just that I disagree with the comment by imaginethis, because using a ! to negate can result in things you might not expect.

    That brings me to my conclusion: usage of negating a boolean on a non-boolean is not a bad thing, per se, but you should be aware the functions' possible return values before using it blindly as it may result in some hard to trace bugs.

    Quote Originally Posted by kyberfabrikken View Post
    Bad example. preg_match will raise a warning in that case.
    I knew I would get comments on that. It's the first function that came up in my mind without checking the manual Surely there are more functions that have some weird return values in the php core, but I can't think of one at the top of my head.

  10. #60
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webaddictz View Post
    That brings me to my conclusion: usage of negating a boolean on a non-boolean is not a bad thing, per se, but you should be aware the functions' possible return values before using it blindly as it may result in some hard to trace bugs.
    Surely. But inventing nonstandard functions such as isempty, is a really bad idea. It's bound to cause confusion for any php developer that reads it. On the other hand, you should safely be able to assume that a php developer knows the difference between == and ===, since that's part of the language.

    Quote Originally Posted by webaddictz View Post
    I knew I would get comments on that. It's the first function that came up in my mind without checking the manual Surely there are more functions that have some weird return values in the php core, but I can't think of one at the top of my head.
    strpos is a classic. You can deal with this by using strict comparison. No need to reinvent basic language features for that.

    I think you can reduce all this to: If you're interested in the value of a function, check for the value - If you're interested in the type of the value, check on that. Most of the time, the latter doesn't matter, since this is a loosely typed language, but if you need it, that's exactly why strict comparison is there.

  11. #61
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Surely. But inventing nonstandard functions such as isempty, is a really bad idea. It's bound to cause confusion for any php developer that reads it.
    Obviously. Introducing a function which introduces confusion, but no added benefit would go under "really bad idea" in my book

    Quote Originally Posted by kyberfabrikken View Post
    On the other hand, you should safely be able to assume that a php developer knows the difference between == and ===, since that's part of the language.
    We're on the same page here. The only reason I replied was that I simply wanted to point out that using the "!" on a function which may return multiple different types might cause bugs.

    Quote Originally Posted by kyberfabrikken View Post
    strpos is a classic. You can deal with this by using strict comparison. No need to reinvent basic language features for that.
    Ah, that's a much better example.

  12. #62
    SitePoint Addict reboltutorial's Avatar
    Join Date
    Jan 2009
    Posts
    309
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    I still prefer using functions. I hate it when I see a class with loads of static functions in it, and nothing else - just seems like an abuse of OOP to me.
    I agree with you on this point. In some language like Java, purety of Object paragdim has become so extreme that everything has to be boxed into a class whereas there maybe no need to do so.

    Quote Originally Posted by Stormrider View Post
    An object/class is supposed to represent an entity, and all related properties and methods, it's not just simply a way of grouping all your functions together. It's not hardship to include a functions file in an init/bootstrap file either really, and all this stuff about 'polluting the global namespace' is complete rubbish, a class with static methods is just as much in the global namespace as a function.
    Well on this point, I may not totally agree: pollution is a problem when you cope with a group of people you may not even know. The access to the Global Name Space should be protected that is accessible only when you explicitely declare it to be so or even more harshly controlled by some adminitrative rights. In Rebol there is some feature like that. I would like PHP to be able to do so also and not become completely objectized like in Java.

  13. #63
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PCSpectra View Post
    Static methods might be in the global scope, but they do not share the global namespace.
    Eh? The symbol has global scope. There is a different scope for floating functions and for classes, but they are both global.

    Quote Originally Posted by PCSpectra View Post
    No namespace collisions...
    No, because they are in different scopes.

    PHP Code:
    $foo 42;
    function 
    foo() {
    }
    defined('foo'42);
    class 
    Foo {} 
    No collision there either, but that's besides the point.

    The problem of nameclash is that developer A might choose the same symbol as developer B, but to mean different things. If there is just one global scope to declare symbols in, the only way to prevent it, is by picking a unique name. With static methods, the full name consists of the classname + the method name, while for floating functions the full name is just the name of the function. So let's calculate the uniqueness of your example:

    Code:
    class Test{
      function doSomething();
    }
    strlen("Test") + strlen("doSomething") => 15
    For a floating function, you could get the same level of uniqueness, using a name with the same number of characters:
    Code:
    function Test_doSomething() {}
    (OK, the underscore means we're off by one, but that's a bit irrelevant to the point).

    Namespaces are something different from adding uniqueness to names. It's a mechanism that allows code to use local scope for static symbols, without the risk of colliding with other code that may use the same names. The thing that makes namespaces practical, is that you can import the namespace into your current scope. So instead of having to write the full name, you can use the local name. Classes don't give you this; To address your function above, you must use the full name Test::doSomething(). In that sense, it doesn't add anything over using Test_doSomething().

  14. #64
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Eh? The symbol has global scope. There is a different scope for floating functions and for classes, but they are both global.
    I think we have a different understanding of what is meant by 'namespace'.

    While a static method is globally accessible, you must provide the class context, like so:

    Code:
    MyClass:doSomething();
    From the wiki:

    In general, a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces).
    Class provides 'context' and while literally (as of PHP 5.3???) they are not 'namespaces' technically they both (namespace and class) provide a context to whatever methods and/or members they encapsulate.

    No, because they are in different scopes.
    Scope is the level of visibility to which an variable/function is made available. So like I said, a static method might be globally available but you MUST prefix it with the context/namespace of the class which encapsulates it so it does not collide with global namespace.

    I realize there is a difference between a class and a namespace but the term 'namespace' does not nessecarily mean 'namespace' as PHP understands it.

    Cheers,
    Alex
    The only constant in software is change itself

  15. #65
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    If if(!$var) doesn't mean anything to you, I would suggest revisiting the documentation because its meaning should have no ambiguity.
    I know perfectly fine what if(!$var) does. The problem is that it can be evaluated as true under several sets of circumstances. In what way is that not ambiguous?

    Granted, empty() returns true under a variety of circumstances too, but who uses empty() to test if a known boolean is true or false? I find that using if(!$var) for booleans and if(empty($var)) for other data types reduces confusion substantially.

  16. #66
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by PCSpectra View Post
    While a static method is globally accessible, you must provide the class context, like so:

    Code:
    MyClass:doSomething();
    Yes, but what's the difference between foo_bar() and Foo::bar() in terms of uniqueness? The chance of two developers picking the same classname or the same function prefix, is the same.

    Quote Originally Posted by PCSpectra View Post
    Scope is the level of visibility to which an variable/function is made available. So like I said, a static method might be globally available but you MUST prefix it with the context/namespace of the class which encapsulates it so it does not collide with global namespace.
    Yes it does. Foo::bar() doesn't collide with bar(), but that's comparing apples to oranges. Foo::bar() is still global - If you make a class Foo and I make a class Foo, we would have a collision.

  17. #67
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig View Post
    I know perfectly fine what if(!$var) does. The problem is that it can be evaluated as true under several sets of circumstances. In what way is that not ambiguous?
    I personally agree with you. For me, ! is strictly for converting booleans. Don't know why, that's just the way I am.

    That's why I'd prefer to use:
    PHP Code:
    if(count($Array) < 1){ 
    Over
    PHP Code:
    if(!$Array){ 
    But
    PHP Code:
    if(!$Bool){ 
    Makes perfect sense.


    I think the reason is that I also use alot of Java and C#, which is strict when it comes to typing; I like to keep consistent throughout all of my programming.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  18. #68
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Yes, but what's the difference between foo_bar() and Foo::bar() in terms of uniqueness? The chance of two developers picking the same classname or the same function prefix, is the same.



    Yes it does. Foo::bar() doesn't collide with bar(), but that's comparing apples to oranges. Foo::bar() is still global - If you make a class Foo and I make a class Foo, we would have a collision.
    You would have a collision either way regardless of any method in either class being declared static. PHP would tell you that you cannot re-declare the class "foo" would it not? It would stop at the class declaration and wouldn't try to determine if the body of the two classes were different. Hence official namespaces, which can also experience naming collisions if not named uniquely enough.
    Visit my blog
    PHP && Life
    for technology articles and musings.

  19. #69
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    I personally agree with you. For me, ! is strictly for converting booleans. Don't know why, that's just the way I am.

    That's why I'd prefer to use:
    PHP Code:
    if(count($Array) < 1){ 
    Over
    PHP Code:
    if(!$Array){ 
    But
    PHP Code:
    if(!$Bool){ 
    Makes perfect sense.


    I think the reason is that I also use alot of Java and C#, which is strict when it comes to typing; I like to keep consistent throughout all of my programming.
    That's fine if you are dealing with known values, but as I pointed out, web applications are loaded with un-known values from user input, URL's and automated sources outside of your control. Most of those values, regardless of their content, present themselves as type string.

    Most of the time it can be more efficient to determine if input is what it is supposed to be, rather than the multitude of things that it should not be. Other times, the list of what that input should be, is longer or harder to determine than what it shouldn't be.

    If for instance you are receiving a database record id from a URL to enable the script in question to update a database, there are four things that it cannot be. Zero, an empty string, null or not set at all. If you use a MySQL auto-increment id, then it has to be an integer, but if you aren't, then there is little else you can do without an extra query, to determine if it's a valid record id.
    Visit my blog
    PHP && Life
    for technology articles and musings.

  20. #70
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Young Twig View Post
    I know perfectly fine what if(!$var) does. The problem is that it can be evaluated as true under several sets of circumstances. In what way is that not ambiguous?
    I wasn't implying that you didn't, I meant it in general.

    Quote Originally Posted by Young Twig View Post
    Granted, empty() returns true under a variety of circumstances too, but who uses empty() to test if a known boolean is true or false? I find that using if(!$var) for booleans and if(empty($var)) for other data types reduces confusion substantially.
    Its a small set of circumstances and inference can be made based on context. So ambiguity shouldn't be an issue. But this is one of those preferential issues related to a programmers individual styles.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  21. #71
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    As others have said, it's all personal preference. I like to use empty(), and I prefer to read that than comparing something to false, because I find it easier to work out why I was doing something when looking at the code later on. I never use it on an unset variable anyway (usually checking with (isset() && isempty()) if I wanted to do that anyway), so the fact that it doesn't replicate empty()'s behaviour in that respect isn't an issue to me. Anyone else looking at my code could easily find the function and see what it does themselves, so I hardly think it's a problem for other people reading my code either. The benefits outweigh the cons for me.

  22. #72
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    I personally agree with you. For me, ! is strictly for converting booleans. Don't know why, that's just the way I am.
    I think it's just the way it reads. "Not true" and "not false" make sense, where "not 'asdf'" and "not array(5)..." don't as much.

    I agree with the way !$var works in PHP. After all, PHP is not the language that's going to bark at you for throwing it invalid types. I just prefer to use empty() for non-booleans as it reads better and is less ambiguous. (All my preference, of course.)

  23. #73
    SitePoint Addict
    Join Date
    Aug 2005
    Posts
    207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think people who don't use strict type setting are missing the complete point of logical developing. Think of it, if your application expects variables A, B, C and A should be of type BOOLEAN and B should be type UNSIGNED and C should be type STRING. Then one should at application initialization CAST them to the type that they should be, and if a variable is not set, set it to its predefined TYPE. That way you don't have to do silly things that have nothing to do with the ultimate objective of your application. Yes the variable VALUE is very important, but variable TYPE should never determine an applications logical control, as that should be handled before the applications logical control is even initiated.

  24. #74
    One website at a time mmj's Avatar
    Join Date
    Feb 2001
    Location
    Melbourne Australia
    Posts
    6,282
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    If using classes as glorified namespaces is a crime, then I am afraid I am guilty of the occasional crime.

    I don't, however, think it's a crime. In the absense of other methods to achieve the same separation of naming spaces, it's a convenient and relatively clean way of grouping functions together and not worrying about each individual function name's effect on the global namespace (just the class name, unfortunately). Even though it does not achieve what namespaces does, it doesn't hurt either. mylibrary::myfunction() is no worse than mylibrary_myfunction() - IMO they are different approaches and it is ok to favour the former.
    [mmj] My magic jigsaw
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The Bit Depth Blog Twitter Contact me
    Neon Javascript Framework Jokes Android stuff

  25. #75
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mmj View Post
    If using classes as glorified namespaces is a crime, then I am afraid I am guilty of the occasional crime.

    I don't, however, think it's a crime. In the absense of other methods to achieve the same separation of naming spaces, which is a reality we're living in, it's a convenient and relatively clean way of grouping functions together and not worrying about each individual function name's effect on the global namespace (just the class name, unfortunately).
    Well you are always going to have some sort of name in the global namespace, even if PHP supported packages.

    I appreciate those here who try to enforce best practices on things that have direct impact on important issues such as code readability, maintainability and runtime efficiency, but realistically, I don't think that using the occasional static class for this purpose is really going to destroy a project, or cause anyone any undue work understanding the code.
    Visit my blog
    PHP && Life
    for technology articles and musings.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •