SitePoint Sponsor

User Tag List

View Poll Results: Static Typing:

Voters
45. You may not vote on this poll
  • Yes

    11 24.44%
  • Maybe

    2 4.44%
  • No

    30 66.67%
  • Don't Care

    2 4.44%
Page 1 of 4 1234 LastLast
Results 1 to 25 of 85

Hybrid View

  1. #1
    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)

    Do You Think That PHP Would Benefit from Static Typing?

    PHP is currently dynamically-typed. You can set a variable as one thing and it can be changed to something else and go through operations suited for other variable types (i.e. adding 5 to "3" = 8).

    So, do you think PHP would be better with static typing? This is where you declare variables first.

    I'm talking of something like:
    PHP Code:
    <?php
    String $var 
    "hello";
    Int $num Integer.parseInt($_GET['number']);
    Var 
    $something//can equal anything.
    ?>
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  2. #2
    SitePoint Evangelist croatiankid's Avatar
    Join Date
    Mar 2007
    Location
    Zagreb, Croatia
    Posts
    409
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is there any benefit to dynamic typing other than that it could help you spot errors early on?
    Hrvoje Markovic
    Croatiankid designs

  3. #3
    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)
    Sure: Security, stability, speed.

    For PHP to process a variable I beleive it's all stored in string format, until a specialised need arrises (math, for example). This means that 5 and "5" are the same with ==, because the number is converted to a string (not the other way round). This requires processing - meaning it is slower than it needs to be.

    On top of this, I would like to state what I want in a function, i.e:
    PHP Code:
    <?php
    function output(String $var//....
    Or, even better, type the function too:
    PHP Code:
    <?php
    void output
    (String $var//...
    String escape(String $unescape//...
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  4. #4
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There are already statically typed languages available, why not choose that rather than modify a dynamically typed one?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #5
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    PHP Code:
    <?php
    String $var 
    "hello";
    Int $num Integer.parseInt($_GET['number']);
    Var 
    $something//can equal anything.
    ?>
    That looks way too much like Java. PHP is dynamically typed for a reason, and I've come to appreciate certain aspects of it's dynamically-typed nature. If anything, PHP should go more towards a full OO language by automatically creating the necessary objects by declared value type implicitly, like Ruby and Python do - something like this:

    PHP Code:
    <?php
    $var 
    "hello"// automatic string object
    $num 1234// automatic integer object
    $regex "/(.*)/i"// automatic regex object
    ?>
    And then all the PHP functions would have to be modified to accept the new base object type as well, like:

    PHP Code:
    <?php
    $sub 
    substr($var02); // equals "he"

    // Also new syntax is provided for the new object types
    $sub $var->substr(02); // equals "he"
    ?>
    So at least to me, that would be the perfect way to take PHP to the OO-level for those who want it, and keep it looking like flat dynamic variables for those who don't.

  6. #6
    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)
    ^ I agree

    Yeah, it is very Java - a language I've grown to like alot however it isn't as suitable for the web as PHP.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  7. #7
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only thing I'd like that's related to static typing is the ability to declare what a method should return in an interface. At the moment we can enforce what is passed to a method but if we could enforce what it should return it would make interfaces much more usable and strict. I don't know about syntax and I think there was talk about this on internals at some point but something like the following would be good:
    PHP Code:
    interface Foo {
        public 
    ReturnObject function bar(PassedObject $obj);
        public 
    DifferentReturnObject function baz();


  8. #8
    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)
    Bolting a static type-system on top of a dynamically typed language seems like a bad idea to me. If anything, I think that PHP has already venture too much in that direction. Statically declared interfaces just seems a bit alien to the rest of the PHP language. Something like this proposal would have been more natural.

  9. #9
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Bolting a static type-system on top of a dynamically typed language seems like a bad idea to me. If anything, I think that PHP has already venture too much in that direction. Statically declared interfaces just seems a bit alien to the rest of the PHP language. Something like this proposal would have been more natural.
    Interfaces in general could be seen as quite alien compared to the rest of the PHP language. I'm definitely not for the proposal put forward by arkinstall, if you want Java, use Java. It seems a natural progression to enforcing classes in a parameter and as interfaces are meant to enforce a particular way of working and I just think this would help.

    I really don't like that proposal tbh, it's not very obvious what is happening but I do prefer the syntax. For PHP something like the following would perhaps be better then.
    PHP Code:
    interface Foo {
        public function 
    bar($baz): ReturnObject;

    It's all just an opinion obviously but it's something I'd like. I don't think it makes it too Java-y as long as it stays in interfaces and we can't start declaring what a class method should return. Like I said it feels like a natural progression in interfaces.

  10. #10
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stardustwd View Post
    I really don't like that proposal tbh, it's not very obvious what is happening but I do prefer the syntax. For PHP something like the following would perhaps be better then.
    PHP Code:
    interface Foo {
        public function 
    bar($baz): ReturnObject;

    Wow... When I read your first post I immediately pictured the exact same syntax you just wrote above for PHP instead, where the expected return object comes after the function declaration (or prototype) instead of before it like other languages. Hey, you know what they say about great minds...

    Also, I don't really agree with the linked proposal either. The syntax just doesn't look right for PHP - there's something about it, I'm not sure.

  11. #11
    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 Czaries View Post
    Also, I don't really agree with the linked proposal either. The syntax just doesn't look right for PHP - there's something about it, I'm not sure.
    It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

    PHP Code:
    interface Fooable {
      function 
    foo($number);
    }

    class 
    MyClassWhichExpectsAFooable {
      function 
    doStuff(Fooable $fooable) {
        
    $fooable->foo(42);
      }
    }

    class 
    SomeFoo {
      function 
    foo($number) {
        echo 
    "foo: " $number;
      }

    Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.

  12. #12
    SitePoint Guru
    Join Date
    Feb 2002
    Posts
    625
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

    PHP Code:
    interface Fooable {
      function 
    foo($number);
    }
     
    class 
    MyClassWhichExpectsAFooable {
      function 
    doStuff(Fooable $fooable) {
        
    $fooable->foo(42);
      }
    }
     
    class 
    SomeFoo {
      function 
    foo($number) {
        echo 
    "foo: " $number;
      }

    Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.
    Hmm... I wonder then how the interpreter should handle the following:
    PHP Code:
    interface Fooable {
      function 
    foo($number);
    }
    interface 
    Barable {
      function 
    foo($number);
    }
     
    class 
    MyClassWhichExpectsAFooable {
      function 
    doStuff(Fooable $fooable) {
        
    $fooable->foo(42);
      }
    }
    class 
    MyClassWhichExpectsABarable {
      function 
    doStuff(Barable $barable) {
        
    $barable->foo(42);
      }
    }
     
    class 
    SomeFoo {
      function 
    foo($number) {
        echo 
    "foo: " $number;
      }

    See what I mean?

  13. #13
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    It think you missed my point - both of you (Which then suggests that I wasn't being clear enough). I weren't suggesting to use that particular syntax. It's the idea that you don't explicitly declare a class to implement an interface, but rather let the interpreter compare the signature in runtime. So, in a PHP-ish syntax, it might look like this:

    PHP Code:
    interface Fooable {
      function 
    foo($number);
    }

    class 
    MyClassWhichExpectsAFooable {
      function 
    doStuff(Fooable $fooable) {
        
    $fooable->foo(42);
      }
    }

    class 
    SomeFoo {
      function 
    foo($number) {
        echo 
    "foo: " $number;
      }

    Note that even though SomeFoo doesn't explicitly implement Fooable, it satisfies the signature, and thus would pass into doStuff.
    It's an interesting idea definitely, wonder how much load this would put on the interpreter though. I don't see how that affects whether the static-typing on return values in interfaces is a good idea, perhaps I'm missing something? Sorry if I'm being dumb

  14. #14
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah first of all TypeHinting does exist in PHP and it doesn't let you get anything else than what you ask for in the function decleration.

    What I would like the most about PHP is not only automatic object creation like
    PHP Code:
    $str "asdasd" // Automatically creates string object 
    But I would also like to overload those automatic creations. For instance, I'd like to decide what kind of object is created when a string is typed.
    This will give much more power to PHP as a framework-potential language. You could actually make PHP to be what ever you want.

    Also I would like to get rid of the annoying -> operator in objects. Why the hell type two letters to get into and object, when one of them mostly requires the use of shift.

    And I never like "this" either. I really liked what Ruby offers. Simply @var to access vars inside the current object, and we could have $ for local vars.

    Why not "." like in most languages (they do it for a reason!). So what if it's compiled in C (or C++), if you have the power to create a new dynamic language, why not make it better than old languages instead of sticking to weird roots.

    Why not replace the .= operator with simply += (since we'll be having automatic string object creation it's gonna be obvious that we want to add something to a string, like - a string!)

    And also it could be a nice idea to add properties instead of creating a damn method for simply retrieving one member variable after a simple calculation.

    And also it could be a good idea to remove the "function" keyword from class methods. Who needs it there? We can do just fine without it.

    My offer:

    PHP Code:
    class Employee
    {
    protected 
    $name 'John Smith';
    protected 
    $monthlySalary 5000;
    public 
    yearlyWage
    {
    get { return @monthlySalary 12}
    set { @monthlySalary $value 12 }
    }

    public 
    sayName()
    {
    echo @
    name;
    }
    }

    $emp = new Employee;

    echo 
    $emp.yearlyWage;

    $emp.sayName(); 
    And oh-my-god. I just despise the :: operator. It's not like in C++ anyway where variables don't have the $ prefix. When we reach for a static class name and not an object there's no way we'll be accessing something else except THAT class. There's no mistaking it for an object, because an object has to have a $ prefix.

    So why, oh why, have double colons to access static members. Not to mention the new namespaces feature in PHP 5.3 that doesn't even support something such as "using" to shorten the call for certain classes.

    So I really can't see myself going like this in a framework I'd build:

    $var = new Framework::Category::SubCategory::Class();

    everytime I want to create an instance of Class.

    Oh an another thing I would really enjoy is the option to create different extension files for PHP files that don't contain HTML or such.

    So that I wouldn't have to start every class file with <?php like some script kiddie.

    PHP is going the wrong way instead of the right one.

    I do not expect to make any use of the namespacing feature in PHP 5.3. It's ridiculous.

    And PHP has so much potential.

  15. #15
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I meant kyberfabrikken signatures idea. Every time it checked it would have to check whether the class conformed to that signature.

    And oh-my-god. I just despise the :: operator. It's not like in C++ anyway where variables don't have the $ prefix. When we reach for a static class name and not an object there's no way we'll be accessing something else except THAT class. There's no mistaking it for an object, because an object has to have a $ prefix.
    Not true. You could theoretically have a constant as an object, e.g.
    PHP Code:
    define('MyObject', new MyObject);
    MyObject->method(); 
    At the moment it would call the method dynamically. But if say we had it so that static method calls used '->', it could refer to either the static call or the call against the constant. You see? Also having ::, for me, makes it more obvious when something is called statically.

    Why not "." like in most languages (they do it for a reason!)
    Because it's used for string concatenation. So $class.method(), that would concatenate the class variable and whatever the function called 'method' returned, there would be no way to tell.

    Why not replace the .= operator with simply += (since we'll be having automatic string object creation it's gonna be obvious that we want to add something to a string, like - a string!)
    That's the whole point of a dynamically-typed language. Say you had two strings, '3' and '5'. Now they're strings because you got them from a form and haven't type casted them yet, you want to add them together to get 8 so you use +=, but if we had it your way then it would create 35, which would be wrong. += allows you to dynamically cast the strings to integers because that is what it is expecting. Even if it would be a good idea, which I don't think it is, it would be such a fundamental change to the language that it would break existing sites.

  16. #16
    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 stardustwd View Post
    I don't see how that affects whether the static-typing on return values in interfaces is a good idea, perhaps I'm missing something? Sorry if I'm being dumb
    Not at all. I didn't bring it up as a comment on return types. It was merely meant as a comment on the current state of PHP's class system.

    Whether return types are a good idea? I'm not sure, to be frank. I believe that typehints on input parameter may be fundamentally different than typehints on return values. Input types can be used to ensure that input is sane, which is a common and useful practise. Return types don't add any extra safety as far as I can see. They are purely documentation; Unless you also add strong typing, and that would be a major change to the language.

    Quote Originally Posted by datune View Post
    Hmm... I wonder then how the interpreter should handle the following:
    ...
    See what I mean?
    No conflict there. An instance of SomeFoo is both a Fooable and a Barable.

    Quote Originally Posted by stardustwd View Post
    I meant kyberfabrikken signatures idea. Every time it checked it would have to check whether the class conformed to that signature.
    I don't think performance would be a problem. The interpreter could cache the lookup per class/interface. Since they are statically defined, they won't change during runtime.

  17. #17
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice but you're ignoring what I'm offering.

    I'm offering that any object can always be put into a $variable.

    so if we did for example

    $string = "1";

    $stringTwo = "2";

    and wanted to add them we would do

    $result = $string.int() + stringTwo.int() // $result would get an Integer object.

    And taht would automatically obviously allow the use of "." for accessing members.

    the "." operator sucks anyway because it's so bad performance wise.

    Did you know that when you do this

    PHP Code:
    $string "str";
    $string .= "str";
    $string .= "str";
    $string .= "str"
    You're actually filling --4-- new 16byte memory cells. That's 48 bytes - purely - wasted.
    Yes. Garbage collection doesn't happen immediately and when using the "." operator you're basically shitting yourself, because you're unreferencing and creating new strings every time.

    And by the way. You can not make a constant an object. That goes against the concept of a constant.

    Don't take my word for it, though. Try it.

  18. #18
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And by the way. You can not make a constant an object. That goes against the concept of a constant.
    My mistake, could have swore I saw someone doing that once.

    the "." operator sucks anyway because it's so bad performance wise.
    It may suck, but by changing to += I don't see how it helps performance.

    That's 48 bytes - purely - wasted.
    48 whole bytes! I'm all for optimization but I doubt that will matter too much and they're ways around that.

    What you are basically describing, again, is Java, with type-casting etc. PHP is a dynamic language and if you want Java, then use Java.
    $result = $string.int() + stringTwo.int() // $result would get an Integer object.
    Why? When the following works fine?
    PHP Code:
    $result $string $stringTwo
    Anyway this is going completely off topic and the syntax is so drastic it would never happen as it would break every PHP script on the net.

  19. #19
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stardustwd View Post
    My mistake, could have swore I saw someone doing that once.

    It may suck, but by changing to += I don't see how it helps performance.

    48 whole bytes! I'm all for optimization but I doubt that will matter too much and they're ways around that.

    What you are basically describing, again, is Java, with type-casting etc. PHP is a dynamic language and if you want Java, then use Java.Why? When the following works fine?
    PHP Code:
    $result $string $stringTwo
    Anyway this is going completely off topic and the syntax is so drastic it would never happen as it would break every PHP script on the net.
    But at least it would give us access to use "." for accessing members, right?

    And we're not describing Java. Come on. Incorporating some concepts that Java (for good reasons) incorporated into its language might be a good idea. It does not mean we're gonna start using Swing controls or strongly typed variables.

    All I'm asking for is an improvement. The actual changes I'm asking for are simply because there's no good reason not to have them.

  20. #20
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CoderMaya View Post
    All I'm asking for is an improvement. The actual changes I'm asking for are simply because there's no good reason not to have them.
    Actually, the changes you're asking for are very drastic and would affect every single script ever made with PHP since they would change the core syntax to something else. Your changes are way too drastic, and will never happen. That's the single BEST reason to not have them (and the only one needed).

    The guys on the internal mailing lists have a strong mindset for what is and what is not the "php way". Any suggestion they feel is not the "php way" will get promptly rejected, and changing the core syntax would most definitely fall in that category, as would any Java-like syntax like "$result = $string.int() + stringTwo.int()" when a simple "$result = $string + $stringTwo" will do the same thing and works great already.

    There are always going to be things you personally like and dislike about any language. There is a point where you have to realize what is feasible and at least somewhat likely to be considered, and what is just flat out asking PHP to be more like some other language you happen to like better. Please keep it realistic!

  21. #21
    Coding and Breathing CoderMaya's Avatar
    Join Date
    Feb 2008
    Location
    Atlit, Israel
    Posts
    470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    Actually, the changes you're asking for are very drastic and would affect every single script ever made with PHP since they would change the core syntax to something else. Your changes are way too drastic, and will never happen. That's the single BEST reason to not have them (and the only one needed).

    The guys on the internal mailing lists have a strong mindset for what is and what is not the "php way". Any suggestion they feel is not the "php way" will get promptly rejected, and changing the core syntax would most definitely fall in that category, as would any Java-like syntax like "$result = $string.int() + stringTwo.int()" when a simple "$result = $string + $stringTwo" will do the same thing and works great already.

    There are always going to be things you personally like and dislike about any language. There is a point where you have to realize what is feasible and at least somewhat likely to be considered, and what is just flat out asking PHP to be more like some other language you happen to like better. Please keep it realistic!
    Yes, well, that's a really good point.

    I think ultimately what I was talking about is a fabulous modification of PHP into another language. Since obviously PHP is meant as a simple web-designer language, with extra stuff for professional developers.

    What bothers me, though, is that PHP has so much potential next to other languages, and it can be so much better for actually much simpler use (considering we have a thousand people willing to create revolutionary frameworks with its great flexibility - which I'm offering to expand even further).

    As a guy who likes to develop neat frameworks and deal with objects pretty much in 99.9% of my code, I hate the -> operator. I always accidently type _> or -. and it.. irritates me.
    Maybe it's an idea to map some key to type "->" hehe.
    Also, dealing with objects all the time, I can't ignore all the possibilities that would make this fantastic dynamically-typed language even more suitable for object oriented designs.

    So what I would like to see is an offical mod for PHP for extra demanding developers.

    Of course that would never happen.

    But dreaming is fun, ain't it?

  22. #22
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CoderMaya View Post
    I think ultimately what I was talking about is a fabulous modification of PHP into another language.
    Well honestly, PHP actually has made a few baby steps in the direction you want. If you look at the new php5 syntax for merging to arrays together, it looks like this:
    PHP Code:
    $newArray = array('foo''bar') + array('baz''xyz'); 
    Which I found quite odd considering the concatenation character for PHP is the dot (.), making the syntax different for concatenating array variable types different than others. So, PHP might have the capability to do something like this in the future after all, where you could use either the dot (.) or the plus(+) sign for concatenation. It's at least something to look forward to .

    Quote Originally Posted by CoderMaya View Post
    As a guy who likes to develop neat frameworks and deal with objects pretty much in 99.9% of my code, I hate the -> operator. I always accidently type _> or -. and it.. irritates me.
    Same here... I have never liked it, and myself would much prefer the dot (.) operator for working with classes as well, but it's something I've learned to live with about PHP.

    Quote Originally Posted by CoderMaya View Post
    Also, dealing with objects all the time, I can't ignore all the possibilities that would make this fantastic dynamically-typed language even more suitable for object oriented designs.
    Definitely don't ignore the possibilities of what PHP could be - that's not what I'm saying at all. I'm just saying that when do you suggest the new features or functionality, suggest it in such a way that it could be more seriously considered in future releases (not breaking backwards compatibility, not changing the syntax too much, etc). I think you get the point .

  23. #23
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CoderMaya View Post
    I think ultimately what I was talking about is a fabulous modification of PHP into another language.
    I came across a "blitz interview" in which Bruce Tate is asked

    Imagine, that you have the right to add five Ruby language elements to the next version of Java. What would they be? Can you include quick code samples as well?
    http://java.sys-con.com/node/251986

    This might apply equally to PHP.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #24
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But at least it would give us access to use "." for accessing members, right?
    Sure. Personally I don't mind -> and from an aesthetic point of view I think $class->method(), looks better than $class.method(); but that's a completely personal preference. I can't remember what language it is (perl?) but -> is not unique to just PHP.

    The actual changes I'm asking for are simply because there's no good reason not to have them.
    I'd argue simplicity and keeping the low barrier to entry that makes PHP so popular (whether for good or bad) are reasons and just because there's no good reason not to have them, it doesn't mean there is any good reason too have them.

    And we're not describing Java
    True, but it's going down that route and personally I believe PHP is close to going down that route too much as it is. Sure, PHP can learn some things from Java, every language can, but from my point of view it's close to taking PHP from a dynamic language to a static language.

  25. #25
    SitePoint Addict chestertondevelopment's Avatar
    Join Date
    Dec 2005
    Location
    Essex, UK
    Posts
    241
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I don't think performance would be a problem. The interpreter could cache the lookup per class/interface. Since they are statically defined, they won't change during runtime.
    Yeah I thought that after I said it, it could just cache whether it satisfies the interface after the first time. It could even help performance as it would not have to parse the interface/signature until it is needed whereas currently it would have to parse the interface initially to check the class conforms. Especially in frameworks such as ZF where interfaces are usually a separate file.

    Quote Originally Posted by kyberfabrikken
    Not at all. I didn't bring it up as a comment on return types. It was merely meant as a comment on the current state of PHP's class system.
    Ah.. sorry about that, I was being dumb then

    Quote Originally Posted by kyberfabrikken
    Whether return types are a good idea? I'm not sure, to be frank. I believe that typehints on input parameter may be fundamentally different than typehints on return values. Input types can be used to ensure that input is sane, which is a common and useful practise. Return types don't add any extra safety as far as I can see. They are purely documentation; Unless you also add strong typing, and that would be a major change to the language.
    I suppose it's the difference between:
    PHP Code:
    $foo $bar->baz();
    if (
    $foo instanceof MyClass) {
        
    $foo->doSomething();
    } else {
        throw new 
    Exception('Return value must be instance of MyClass');

    And knowing that $foo is an instance of MyClass because the interface ensures so, so we would have.
    PHP Code:
    $foo $bar->baz();
    $foo->doSomething(); 
    More concise, and it's also obvious from looking at the interface declaration that it should return an instance of MyClass, thus helping code readability and makes the interface more self-documenting.
    Last edited by chestertondevelopment; Aug 29, 2008 at 07:25.


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
  •