SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 41 of 41
  1. #26
    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)
    I realise that a colon isn't an underscore. That's not my point. My point is, that they amount to the same result.

  2. #27
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No they don't. You cannot name a function with double colons, you can use an underscore. PHP does not treat an underscore as an operator in any way.

    Why would they design a language where a character that is an operator could also be a valid character in variable and function names. There is no way the parser would know your intention, just like you can't use a period or equal sign in a function name.

    I provided a link to the PHP manual that outlined the proper use of ::. Show me where in the manual it says that an underscore can be used as an operator or that :: can be used in a function or variable name. They most certainly can not.

    --> and :: are used exclusively to address members and methods. One is instance the other static.

    methods inside classes cannot be addressed directly from global scope, regardless if an instance of the class has been made or not. Which is called "encapsulation" and is a fundimental programming concept.

    You have to tell the parser which class and which method you want to call with either class::method() for static or $instance->method() for instance. You have to guide it through the scope chain. The only scope that is universally accessible is the main global scope.

    This is basic stuff here man. The documentation is there for everyone to see. It even works that way in Javascipt which is prototype based, just not using the same operators.

  3. #28
    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)
    Wow. Either you're immensely thick, trying to pick a fight, or I'm bad at explaining myself. I assume it's the last.

    When you refer a static method from somewhere, you make a coupling to a global symbol. The static method is a symbol, and it has the same meaning in every context. Thus global. This is analogous to a global variable. In this respect, there is no difference between using a static method and a floating function. Once referred to from some code, you can't change that reference. The implications of this are also the same as with global variables; If you want to change the binding, you have to re-define the global symbol. This could break other code, which also relies on it. There are other problems with globals of course, but that's the most imminent.

  4. #29
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No I am not trying to pick a fight.

    So what you are saying, is that a method of a class is in the scope of the class unless you call it statically, at which time it becomes part of the global scope. So, if there are any global functions named the same as the class method, there would be a collision.

    PHP Code:
    // my class and method
    class foo
    {
       function 
    bar()
       {
          echo(
    'bar inside foo');
       }
    }
    // someone else's function
    function bar()
    {
       echo(
    'bar in global scope');
    }
    //bar inside of foo is not in global scope
    foo::bar();
    echo(
    '<br />');
    // now it is
    // so when I call bar() I get the wrong echos because of a conflict right?
    bar();
    echo(
    '<br />');
    foo::bar(); 
    When I run this code I get

    bar inside foo
    bar in global scope
    bar inside foo

    i don't mean to be difficult, but you're telling me that this will cause a conflict between the two and it clearly does not. Each still echos what it should and operates independently of the other.

    Okay. Lets get rid of the floating function and see what happens
    PHP Code:
    // my class and method
    class foo
    {
       function 
    bar()
       {
          echo(
    'bar inside foo');
       }
    }
    // someone else's function
    /* No function bar now
    function bar()
    {
       echo('bar in global scope');
    }*/
    //bar inside of foo is not in global scope
    foo::bar();
    // now it is
    echo('<br />');
    bar();
    echo(
    '<br />');
    foo::bar(); 
    Now I get the following

    bar inside foo

    Fatal error: Call to undefined function bar() in C:\wamp\www\Dev\foobar.php on line 19

    But wait I thought the method bar() was now in the global scope. Let's try this

    PHP Code:
    // my class and method
    class foo
    {
       function 
    bar()
       {
          echo(
    'bar inside foo');
       }
    }
    foo::bar();
    echo(
    '<br />');
    foo_bar();
    // should give me something if an _ is the same as a :: 
    uh oh!

    bar inside foo

    Fatal error: Call to undefined function foo_bar() in C:\wamp\www\Dev\foobar.php on line 12

    The scope just isn't working the way you say, or we are talking about two different things and don't know it.

    If I have a class full of general utility functions (which I do), what this code demonstrates to me, is that if I include somone else's code that has floating functions of the same name as a method or methods in my utility class, there will be no conflicts with it.

    Obviously if they have a class named the same, there will be a problem, but there is less chance of that as there would be with method names, especially with careful naming guidlines (like those for PEAR or Zend)

    If you can post code that demonstrates what you are talking about fine, but I have been using this technique in my framework for over a year now with a lot of third party stuff, some of it had functions with the same name as the methods inside utility and i have had no problems with it.

  5. #30
    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)
    The chance of a name-collision is directly dependent on the chance of using the same name to refer to two different entities, within the same scope. In other words, the chance of collision is equal to how unique a name is (Within that scope).

    To call a static method, you can't just refer to the method. The fully qualified name - the symbol - is the classname, two colons and the method name. The symbol for a floating function, is simply the functions name.

    The uniqueness of a static method amounts to the uniqueness of classname + the uniqueness of the methodname. Thus the uniqueness of foo::bar is calculated as:
    Code:
    uniqueness("foo") + uniqueness("bar")
    Conversely, the uniqueness of a floating function amounts to the uniqueness of the functionname. So the uniqueness of foo_bar is:
    Code:
    uniqueness("foo_bar")
    By convention, the underscore is used to separate the module name from the function, so the uniqueness of foo_bar is more appropriately described as:
    Code:
    uniqueness("foo_bar") - uniqueness("_")
    Assuming that the uniqueness is calculated as the number of characters used in a given name, we can reduce the above to:
    Code:
    uniqueness("foo") + uniqueness("_") + uniqueness("bar") - uniqueness("_")
    Which is the same as:
    Code:
    uniqueness("foo") + uniqueness("bar")
    So, in conclusion, the uniqueness of foo::bar is equal to the uniqueness of foo_bar.

    This does not mean, that foo::bar refers to foo_bar, but it means that the chance of colliding with an arbitrary third party is the same in both cases.

    The reason why we have talked by each other for half a thread now, is that you compare foo to foo::bar, while I compare foo_bar to foo::bar.

    Quote Originally Posted by Hammer65 View Post
    No I am not trying to pick a fight.
    In that case, my apologies for suggesting otherwise.

  6. #31
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, but what I was trying to point out is that if you try to name a floating function like this..

    PHP Code:
    function foo::bar()
    {
       echo(
    'boo!');

    You get..

    Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting '(' in C:\wamp\www\Dev\foobar.php on line 2

    Which means there is no way a collision would ever occur because nobody could name a function "foo::bar". PHP won't let you use something that is an operator in a name.

    I had no idea it was called a "PAAMAYIM_NEKUDOTAYIM". How is that pronounced?

    Anyway, that's why I was making the comparison that I was. It didn't make sense when you can't use that operator as part of a name anyway. I know PEAR uses it in it's documentation but it won't work in the code as far as I can see.

  7. #32
    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 Hammer65 View Post
    Which means there is no way a collision would ever occur because nobody could name a function "foo::bar". PHP won't let you use something that is an operator in a name.
    You overlook, that there is a way that a naming collision could happen; Namely, if someone declared a different class, with the name foo.

    The purpose of using a static method, is to reduce the chance of naming collision between functions. What I'm saying is, that you can solve this problem by prefixing the floating function with a namespace. The end result is the same.


    PAAMAYIM_NEKUDOTAYIM is Hebrew. If I remember correctly, it simply means double colon. It's an inside joke, since some of the core developers are from Israel.

  8. #33
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The purpose of using a static method, is to reduce the chance of naming collision between functions.
    Yes and that is all I am concerned about. Since there is no package level in PHP, that's the best anybody can hope for.

    Then again if there was, you could still have conflicts, and I'm sure that occurs occasionally with c#, Java, ECMA4, c++ etc.. Probably not as often however.

    The thing is OOP is new enough to PHP that though some have settled in to it just fine, most of the stuff from others that I have to deal with, still uses a lot of proceedural code. I protect my framework code from that code by using encapsulation.

    It doesn't bother me to step outside the OOP religion (which is how some purists treat it), if what I'm doing helps me get work done quickly and makes my code easy to maintain and re-use.

    For instance I do a lot of small things in a row sometimes a contact form here an admin section there, a cart there. I'm not an indy I work for a web development company.

    So my framework isn't an MVC (I'll use something else for that), it's more akin to a large toolbox full of stuff that is designed to work together as a whole or separately. It's highly re-usable, flexible and maintainable. It doesn't follow one of the religion approved patterns and I don't care.

    I'm only a little off the reservation and I'm fine with that.

  9. #34
    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 Hammer65 View Post
    Yes and that is all I am concerned about. Since there is no package level in PHP, that's the best anybody can hope for.
    But there is an alternative; You can use objects instead of procedural code.

    The whole problem of namespace collision is only an issue because you use the global scope to address your functions (static methods or floating functions). If instead, you used local variables (objects), you would only need the symbol to be unique within the local scope. There can be hundreds of classes with the method bar() defined, but there can only be one with the name foo::bar()

    Quote Originally Posted by Hammer65 View Post
    Then again if there was, you could still have conflicts, and I'm sure that occurs occasionally with c#, Java, ECMA4, c++ etc.. Probably not as often however.
    Yes, each time you use a global symbol, there is a risk.

  10. #35
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but there can only be one with the name foo::bar()
    sigh..

    There can't be any with the name foo::bar(), I already showed you that. PHP doesn't allow it. It's a like specific address Reno::Nevada, and anyway, the OP was talking about using it in the scope of an object.

  11. #36
    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)
    Yes there can. foo::bar is a global symbol, just like foo_bar is a global symbol. They a different symbols, but they are both global symbols, and they have the same risk of a nameclash. I don't know how to be any clearer than this.

  12. #37
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You were plenty clear, as was I when I demonstrated that PHP would not allow it. You even explained to me what the error message said. Run it yourself if you think I"m lying. If you want to cement the argument, produce some code to show everyone that you are correct. Only a few lines should do it.

  13. #38
    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 Hammer65 View Post
    If you want to cement the argument, produce some code to show everyone that you are correct. Only a few lines should do it.
    OK.

    PHP Code:
    class foo
    {
      static function 
    bar() {
        echo 
    "foo::bar called";
      }
    }
    function 
    foo_bar() {
      echo 
    "foo_bar called";

    You now have two symbols available in the global scope, namely foo::bar and foo_bar. You can test this with the following addition:
    PHP Code:
    foo::bar(); // output: foo::bar called
    foo_bar(); // output: foo_bar called 

  14. #39
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes and both are functioning correctly. I don't know about anyone else but I wouldn't, even in several hundred lines of code on a page get the two confused. I'm beginning to see the problem here.

    It doesn't throw an error message, and it doesn't cause un-expected behavior such as lost data or incorrect calculations. A true conflict would cause one or both, or cause a crash. That is what I was speaking about. The kind of thing that would happen if you flat out had two classes named the same and PHP says "Cannot re-declare class foo".

    If you are talking about it being confusing to someone who didn't write the code or someone coming back to it after an extended time, there is a potential, but I believe that I make more of an effort to comment code than that. Especially when I am aware of a potential problem.

    I can't control the conventions that others use for naming, but if I use their code, I can certainly note any potential issues, in the very rare case it occurs. Hardly a reason to re-write several thousands of lines of code, that I use every day without issue.

  15. #40
    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 Hammer65 View Post
    Yes and both are functioning correctly. I don't know about anyone else but I wouldn't, even in several hundred lines of code on a page get the two confused. I'm beginning to see the problem here.

    (...)

    If you are talking about it being confusing to someone who didn't write the code or someone coming back to it after an extended time, there is a potential, but I believe that I make more of an effort to comment code than that. Especially when I am aware of a potential problem.
    No, that wasn't what I meant either. I'm saying that whether you put your code in a static method or in a floating function makes no difference. The only thing setting them apart is, that to invoke the code you use a double colon between namespace and function name in the first case, and an underscore in the second. It's purely syntactical - foo::bar are not identical, but they have the same properties in every practical aspect.

  16. #41
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the code works as expected without error, I don't find that a problem. A function call isn't going to call the wrong function, you still end up addressing the correct code for the call you make just as you would if the names were not similar. A call to foo::bar will always address the class method and a call to foo_bar will always address the floating function. My only concern are errors and buggy behavior. If there isn't any due to this, it's fine with me.

    Whether or not it's bad practice we will just have to agree to disagree.


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
  •