SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 56
  1. #26
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Is this something you made up, or do you know of any languages which would allow that ?
    Quote Originally Posted by stereofrog
    Code:
    function save($s | $s->implements('write'))
    There's Haskell, E and Q.
    Quote Originally Posted by stereofrog
    Code:
    save to something that has 'write' function
    As far as I know, AppleScript comes closest

  2. #27
    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 michel
    Sure. I guess I trust the PHP devs blindly for not changing such fundamental behaviour
    Well ... You never can be sure when it's php, can you.

  3. #28
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Well ... You never can be sure when it's php, can you.
    Yep, I just finished updating a couple hundred method returns in my codebase, hence the . But if someone decides to change the return value(s) of fundamental stuff like func_get_args() I'll consider switching to Python or Ruby .

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    would be nice, won't it?
    Not really... What I mean is that you can do that with Interfaces anyways, and with Interfaces, it's still a lot more flexible, and cleaner

    Why confuse and add more complexity to what is by definition of software development, something that is already complex?

  5. #30
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Why confuse and add more complexity to what is by definition of software development, something that is already complex?
    I agree. So don't use Interfaces.

  6. #31
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sure, don't use Interfaces if you don't want to; No one is pointing a gun to your head, but please do consider just for one moment... If Interfaces add more complexity to software design and development, then why on this Earth, does a multitude of programming languages and technologies support Interfaces huh?

    Why? If they add so much complexity to software development? I think not...

  7. #32
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Dr Livingston: I'm not sure what you mean under "Interfaces", probably the Java incarnation. The primary purpose of interfaces in java is to get your program compiled. If you don't compile, why do you need them?

    @michel: I'm sure my example has nothing to do with AppleScript. As you correctly pointed out, pipe syntax comes from haskell. There are some experiments with guards in "conventional" languages, for example http://llimllib.f2o.org/blog/serve/entry/pygenerics

  8. #33
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    I'm sure my example has nothing to do with AppleScript.
    It's just my weird sense of humour

  9. #34
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    If Interfaces add more complexity to software design and development, then why on this Earth, does a multitude of programming languages and technologies support Interfaces huh?
    Because those languages are statically typed; Interfaces (which are called protocols in other languages) exist only in those languages that combine static typing and single inheritence, and one could argue that they're simply workarounds for the limitations of static typing, and as such have no place in dynamically typed languages. Personally, I agree that they add complexity, in the same vein that static typing adds complexity. I find ruby's mixins to be a much better solution to the types of problems protocols are used to solve.

  10. #35
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Because those languages are statically typed; Interfaces (which are called protocols in other languages) exist only in those languages that combine static typing and single inheritence, and one could argue that they're simply workarounds for the limitations of static typing, and as such have no place in dynamically typed languages.
    Yes... Well, I could proberly agree with that thought without losing too much sleep, but just because PHP isn't statically typed, it doens't mean that the use of Interfaces cannot prove to be useful?

    Regardless of being either statically, or dynamically typed, Interfaces in a modern programming/scripting language have their place.

    Personally, I cannot see why the use of Interfaces adds (even) more complexity, if anything for me, it makes things a lot more clearer; More intuitive, if you will

    Moving from working with Java for a (brief) period, to PHP5 I can say that Java is a more difficult language to develop with, but in my view, not because it's syntax and object model, more because of the actual platform it's self.

    One thing I took away was the requirement to learn how to design and apply the use of class abstractions and Interfaces, properly; It made the transistion of moving to PHP5 a lot more easier for me...

    Don't knock a good thing

  11. #36
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Personally, I cannot see why the use of Interfaces adds (even) more complexity, if anything for me, it makes things a lot more clearer; More intuitive, if you will
    Well, Interfaces per se don't, and they could be useful by explicitly documenting the, well, interfaces you use. Also, they move possible errors from within a method to a method boundary (parameters) which can also be useful.

    However, for the latter they require use of type hinting, which go agains the very dynamic nature of PHP, and IMO make things so inflexible that in most cases it's simply not worth it.

    If you approach design as if you were working in Java, then they are fine, but never forget that PINJ. and it has its own, more suited ways.

  12. #37
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Yes... Well, I could proberly agree with that thought without losing too much sleep, but just because PHP isn't statically typed, it doens't mean that the use of Interfaces cannot prove to be useful?
    Personally, I haven't used them enough to decide wether or not they are really usefull, although I can see how they could be. However, by adding them to the language (along with type hinting), I feel PHP has taken a couple of steps towards being less dynamic, which is the opposite direction from where my tastes in languages is going.

    Quote Originally Posted by Dr Livingston
    Regardless of being either statically, or dynamically typed, Interfaces in a modern programming/scripting language have their place.
    There are many things that are considered "best practices" that have come about due to the limitations of static typing; Java's Interfaces are there because the language would be seriously crippled without them, and I'm not certain they'd exist if Java had been dynamically typed from the start.

    Quote Originally Posted by Dr Livingston
    Personally, I cannot see why the use of Interfaces adds (even) more complexity, if anything for me, it makes things a lot more clearer; More intuitive, if you will
    My main objection to using interfaces is that it make your code less agile; once you've commited to one, you can't easily change it or the code that uses it. So you either have to plan your api carefully upfront, or you have to refactor it out of your code. There definitely is a cost to using them.


    Quote Originally Posted by Dr Livingston
    Moving from working with Java for a (brief) period, to PHP5 I can say that Java is a more difficult language to develop with, but in my view, not because it's syntax and object model, more because of the actual platform it's self.
    It's a difficult language in big part because you have to be very verbose to get what you want done. Part of the problem is the platform, the class library being so fine-grained makes it very flexible but a little tedious to use; but another part of the problem is constantly repeating types everywhere and having to cast things back and forth. Ugh.

  13. #38
    SitePoint Enthusiast
    Join Date
    Dec 2005
    Posts
    29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Who is to say that the library function I use won't change in the future? Proberly not I know, but there is that possibility (it happens) so I don't want my scripts to break if there is anything, other than an array, if that makes sense?
    Not picking on you , but since I noticed the above array thing also, I dont get it, becuase even if the returned type did change, the code would not execute and no errors/warnings generated and your scripts would be broken regardless (because there currently is no alternative scripting implementation for when it is not an array etc), thats more hassle than letting the script generate the error (as it should, imo) if in case you didnt update all your scripts accordingly.

    Its a bit like the one of the original example methods in the thread:

    PHP Code:
    function ifset(&$myvar,$def='') {
      if (isset(
    $myvar) && is_null($myvar)) {
                return 
    $def;
      } elseif (isset(
    $myvar)) {
                return 
    $myvar;
      } else {
                return 
    $def;
      }

    however


    PHP Code:
      if (isset($myvar) && is_null($myvar)) {
                return 
    $def;
      } 
    Can never be true, as according to php.net

    isset() will return FALSE if testing a variable that has been set to NULL.
    Added:


    PHP Code:
          if( array_key_exists$parameter array_shift$parameters ), $this -> parameters ) && !empty( $this -> parameters[$parameter] ) ) {
            return 
    true;
          } 
    is no different than simply

    PHP Code:
          if( !empty( $this -> parameters[array_shift$parameters )] ) ) {
            return 
    true;
          } 
    Due to the given nature of the native php empty function, i.e. regardless of whether the key exists, because of && !empty, the presidence is then only on the actual value, because empty will return false even if the key does exist and if its value is zero.

    Sorry had to add this:
    PHP Code:
    if( is_array$parameters ) === true ) {
     
    // ...

    Last edited by devosc; Feb 1, 2006 at 04:01.

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The lack of functionality isn't a problem, as testing would pick up on it anyways; No need to modify the existing class(es), you develop a replacement that still complies with the Interface

    As for errors, I'd feel uncomfortable with those. Imagine the bad reflection a client would have on you, if they got those errors? Better the application breaks, silently due to an oversight on your part, rather than give the client the thought that your a sloppy developer.

    Anyways, I'm happy enough with the reasoning I have, it's proberly mad, but that's me

  15. #40
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by michel
    Off Topic:


    Pah, whats this E imposter. There can only be one E.

    http://wouter.fov120.com/e/index.html by Wouter van Oortmerssen, who experimented quite alot with languages. http://wouter.fov120.com/index.html


  16. #41
    SitePoint Enthusiast
    Join Date
    Dec 2005
    Posts
    29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But there is no test case, it always returns an array. Anyway, you're entitled to your reasoning, given the quality of the rest of the code etc. For me personally I just like to see things used as neccesary, a classic example is if (empty($var) === true), people new to php then spend months terrorizing their code to follow suit until such time they mature and realize it will always be either true or false and thus no need to explicitly test its return type etc.

  17. #42
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    given the quality of the rest of the code etc.
    Meaning what exactly... ??

  18. #43
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by Ren
    Pah, whats this E imposter. There can only be one E.
    Oops, I wasn't programming yet when I owned an Amiga

  19. #44
    SitePoint Enthusiast
    Join Date
    Dec 2005
    Posts
    29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Meaning what exactly... ??
    Nothing, other than that the rest is nice ???

  20. #45
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah... Yer, I have my moments, now and again, it's like someone has just switched a light on? You get good times and some not so good times; Refactoring helps a lot, particularly when you've noted a few points or concerned with previous work, in that you had reservations at the time

  21. #46
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but another part of the problem is constantly repeating types everywhere and having to cast things back and forth.
    Surprisingly that is one part that I didn't actually mind about; In fact it helped me to keep focus to a certain degree, and in fact is one feature that I was looking forward to seeing in PHP5; Unfortunately it wasn't to be, but who knows... PHP6?

  22. #47
    SitePoint Guru OfficeOfTheLaw's Avatar
    Join Date
    Apr 2004
    Location
    Quincy
    Posts
    636
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm a little worried about people confusing interfaces as something complex that should be avoided whenever possible, and the claim that they are only useful for statically typed languages. That is absurd. Anyone with any amount of real experience developing large OO applications with multiple people know how beneficial an interface is. All an interface is is a contract that says "Classes that implement this interface must provide certain methods with these arguements".

    Take, for example, a CommandDispatcher. With a command dispatcher, one can add multiple Commands with some kind of key or state that indicates when the command should be executed, and when the command dispatcher is ran with that state or key, it finds the appropriate Command and calls it. Now, with an interface that says all Command objects must implement an execute method that accepts certain arguements, you can easily ensure that anyone who write a command for that particular command dispatcher can just glance at the interface and know to implement the method. You don't have to worry about them programming by coincidence, and if they don't implement the interface in their command object, you can reject adding the command object to the dispatcher.

    I find it AMAZING that something taught in a first year computer science course is deemed "too complex'.

    James Carr, Software Engineer


    assertEquals(newXPJob, you.ask(officeOfTheLaw));

  23. #48
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nobody -- OK, I at least -- ever said that interfaces are too complex. If anything, they're limiting.

    And in any case, don't confuse interfaces with Intefaces; the latter are unnecessary, but the former are a fact of life.

  24. #49
    SitePoint Guru OfficeOfTheLaw's Avatar
    Join Date
    Apr 2004
    Location
    Quincy
    Posts
    636
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    If anything, they're limiting.
    Which is the point... to make the class conform. They'd be usesless if they didn't!

    James Carr, Software Engineer


    assertEquals(newXPJob, you.ask(officeOfTheLaw));

  25. #50
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by OfficeOfTheLaw
    Which is the point... to make the class conform. They'd be usesless if they didn't!
    Er... Making the class to conform is useless.

    Or, to make it a bit more precise: making the variable to conform is useless, or rather pointless. A class should do whatever is it's responsibility.


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
  •