SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 55
  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)
    Quote Originally Posted by irkengir View Post
    Errr... then you would have to implement an exception (quite a few lines) before you could throw one.
    c'mon ... They could require the object to implement IException, but provide a default Exception, which implements the interface. Then people could use the default Exception for most cases, but be free to not do it.

    Or they could do like javascript and simply allow you to throw anything, and then leave it for the catch block to deal with whatever arrived. If they kept the typehint in catch(), you would even have backward compatibility with PHP5.

  2. #27
    SitePoint Enthusiast irkengir's Avatar
    Join Date
    Mar 2006
    Location
    UK
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I guess I didn't like the comment about blindly copying Java because I really don't see anything wrong with Exception the way it is. The best way to improve it, if that really is necessary, is as you suggested kyberfabrikken.

  3. #28
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Or they could do like javascript and simply allow you to throw anything, and then leave it for the catch block to deal with whatever arrived.
    That's what I was getting at. Extending Exception means writing a new class. Even implementing an interface imposes a burden.

    Quote Originally Posted by d11wtq View Post
    I don't think visibility should be removed... perhaps made optional, but not removed. You get PHP4 behaviour by simply using "public" anyway.
    As long as I can just ignore it I'm happy. But how long will it be before a plain:
    PHP Code:
    function foo() {

    becomes an E_STRICT error...?

    I should say a well-defined class interface is very important it's just that I don't believe it needs to be enforced.

  4. #29
    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 d11wtq View Post
    I don't think visibility should be removed... perhaps made optional, but not removed.
    The problem with visibility, at least as it's implemented in Java, is that tries to govern two separate things, and does either job pretty badly.

    On one hand, it defines which property may be accessed by which objects, and on the other it also defines which properties are inherited by subclasses. First of all, let me note that limitations on inheritance are nonsense, as they go against the basic "is a" principle of inheritance.

    And second, I see any property as being either accessible only by the object it belongs to (private), or being accesible by any object, regardless of its descent or package. Even more, any attribute should be private and nothing but private -- only methods could be made public, creating the object's interface.

  5. #30
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I find that visibility restrictions are somewhat useful if you don't make too much fuss about them, but visibility in PHP is less useful than in Java since Java has package visibility.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  6. #31
    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 dagfinn View Post
    I find that visibility restrictions are somewhat useful if you don't make too much fuss about them, but visibility in PHP is less useful than in Java since Java has package visibility.
    Package visibility is an entirely different thing from property access. Thanks for reminding me, that's a third thing Java's trying to roll into a single feature.

  7. #32
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ironically the majority of features listed already exist in other languages...
    Changing to PHP 6 will most likely break so much you may as well change languages too = )

  8. #33
    SitePoint Evangelist ClickHeRe's Avatar
    Join Date
    Mar 2005
    Location
    Ottawa, Canada
    Posts
    580
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Unicode
    Namespaces
    Multiple Inheritance (no I don't want a flame war on interfaces can replace ...)
    Inner functions

    That's pretty much all I need
    David

  9. #34
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > perhaps made optional, but not removed.

    At the moment it's optional, and from what I can tell, class and property visibility will continue to remain an option to the developer; The great thing about PHP is that you can do the same thing a dozen different ways, and there isn't anything to get in your way.

    Much so visibility is much like that as well; I have not yet read anywhere that this feature is going to be made mandatory, for any version of PHP now or further down the road

  10. #35
    An average geek earl-grey's Avatar
    Join Date
    Mar 2005
    Location
    Ukraine
    Posts
    1,403
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    cleanup of standard library by creating new sets of string, array and file functions with consistent naming and arguments order, collating similar functions using optional flag params i.e. a_sort($ary, SORT_KEYS | SORT_DESC) etc
    I agree with many statements mentioned here, but this one the most of all. Current standard library is too incosistent.

  11. #36
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    That's what I was getting at. Extending Exception means writing a new class. Even implementing an interface imposes a burden.
    There's a reason for this though. Yes, javascript lets you throw any type of object as an exception, but that's mainly because there aren't any classes or interfaces, so there'd be no other way to do it anyway. The downside of this is that, unlike php, you can only have a single catch statement; you can't have multiple catch statements for different types of errors, which means you have to add if statements and instanceof operators, which is messy.

    Besides, an exception is an object that represents an error message, nothing more, so it makes sense for it to be a subclass of Exception. Having it be an interface means you could write an object that is more than just an exception, which deviates from the intention of exceptions. This could be convenient, but it could lead to some very messy code, as it could be easily abused. If you find yourself needing to pass $this, you could simply add it as a property of your custom exception, so you could throw new MyExpection('an error', 1, $this).

    I understand the additional burden that extending a class or implementing an interface creates, but the concept of exceptions requires it, IMO.

  12. #37
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As for new features, i'd like to see, my humble list would be.

    - Unicode support
    - A proper property mechanism
    - Non scalar constants
    - Shorthand for creating arrays: $arr = [1, 2, 3]
    - Namespaces (but I'm not holding my breath for anything genuinely useful)
    - Moving the built-in functions into individual namespaces and cleaning up naming

    I could go on, but I'm more likely to move to another language than see things like blocks and open classes.

  13. #38
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees View Post
    The downside of this is that, unlike php, you can only have a single catch statement
    Or, if the fatal error was turned off in catch(), hints could allow catchers to choose whether to accept a thrown object. I've no idea if the php internals would make that problematic to do.

    Besides, an exception is an object that represents an error message, nothing more
    That's exactly why I don't like the implementation. Why create an object just to pass a string around? OK there's some extra information in there as well as the error string but what I really want to do is interrogate the failing object directly rather than pull stuff out, wrap it up in an exception class, and then drag it all out again in the catcher - cuts out the middle man.

  14. #39
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FWIW: Give me namespaces, add unicode, add an opcode cache, add sandboxing and whitelisting and remove any of the new PHP5 E_* idioms (such as E_STRICT).

    Why create an object just to pass a string around? OK there's some extra information in there as well as the error string but what I really want to do is interrogate the failing object directly rather than pull stuff out, wrap it up in an exception class, and then drag it all out again in the catcher - cuts out the middle man.
    I think there is a reason that it is called "throwing an exception" and not "throwing the offending object". Objects represent state and an exception is a contextual state-transfer. Throwing any old object is ... well, it is a strange sort of "casted goto" and I suspect that people who want it might want to use exception handling to deal with standard program logic rather than exceptional concerns. Anyways, the offending condition may not arise from an object itself.

    Further, an exception object is not merely a string representation -- it is an abstracted way to manage errors. Now lets consider a real problem. Say you have a consistency check that occur in various types of objects, not all derived from the same object. You want your error handling to deal uniformly across all objects for that sort of incident. Do you re-implement that handling in each base class? I think not. You abstract it as a general exception type (ECrossCuttingConcernX) and you throw that from each of the objects. As a bonus, you can decorate that exception type, change the base class definition or even inject behaviors as required. You can't do that with a string and it becomes messy quickly without a standardized and abstracted mechanism (ie. the exception class).

    Well, that's the way I see it anyways.

  15. #40
    SitePoint Zealot
    Join Date
    Nov 2002
    Location
    Belgium
    Posts
    147
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, next to Unicode support, overloading is certainly a must-have.

  16. #41
    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 BerislavLopac View Post
    Package visibility is an entirely different thing from property access. Thanks for reminding me, that's a third thing Java's trying to roll into a single feature.
    I'm not sure I understand what you mean. Terms like private, public and protected seem to have a well-defined, albeit somewhat general meaning. Final, on the other hand, is ambiguous.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  17. #42
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots View Post
    Further, an exception object is not merely a string representation -- it is an abstracted way to manage errors. Now lets consider a real problem. Say you have a consistency check that occur in various types of objects, not all derived from the same object. You want your error handling to deal uniformly across all objects for that sort of incident. Do you re-implement that handling in each base class? I think not. You abstract it as a general exception type (ECrossCuttingConcernX) and you throw that from each of the objects. As a bonus, you can decorate that exception type, change the base class definition or even inject behaviors as required. You can't do that with a string and it becomes messy quickly without a standardized and abstracted mechanism (ie. the exception class).
    Well said. Nevertheless wouldn't it be convenient if you could pass a string if you're not using custom exceptions? Maybe an Exception instance could be created internally and have the string assigned as its message.
    PHP Code:
    throw 'Message' 
    instead of
    PHP Code:
    throw new Exception('Message'

  18. #43
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by michel View Post
    ...wouldn't it be convenient if you could pass a string if you're not using custom exceptions? Maybe an Exception instance could be created internally and have the string assigned as its message.
    PHP Code:
    throw 'Message' 
    instead of
    PHP Code:
    throw new Exception('Message'
    Hmm. Well, it is not at all clear to me why you would want to do the former. Maybe your intention is to simply log some condition's outcome? Besides, I don't see how much more convenient it really is -- the latter is just 15 more characters to type (less with a good IDE) and gives the handler much more information to work with.

    I guess this is getting OT, so I'll wrap it there. Cheers.

  19. #44
    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 dagfinn View Post
    I'm not sure I understand what you mean. Terms like private, public and protected seem to have a well-defined, albeit somewhat general meaning. Final, on the other hand, is ambiguous.
    The issue with access modifiers (private, public, protected and package in Java) is that they're handling two different things which are not related.

    One thing is controlling which objects may see and call properties (attributes and methods). Generally, public means that anyone may access a property, while private restricts access to the owning object only.

    The other thing is controlling whether a property gets inherited by a subclass. In this role, public means that it does, while private means that it doesn't.

    This double role of these keywords necessitated the additional keyword "protected", which means that it is accessible as if it was private, but it inherits as if it was public.

    My issue with this system is twofold:

    a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times? A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property, it's only natural that its subtype does it as well; if it doesn't, it's the subtype's responsibility to define its properties, and not the parent's. IOW, the second role of these keywords is totally superfluous and should, ideally, be completely removed.

    b) If the above would be true, a property could have only two states: visible to all (public) and visible only to the object itself (private). This means that one of this keywords is not needed, since we could determine a default state by the lack of a keyword -- and IMO the default should be private and the keyword public, as public properties define our object's interface.

    An extra step could be taken by restricting the public keyword to methods only -- attributes should be private and never public; if you need an attribute, use a method. Or even better, we could eliminate the attributes completely and turn them into dynamic properties defined as methods; but that might be stretching it a bit.

  20. #45
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As for the private / protected debate: private members are indeed inherited to a certain extent in that a child class can not redeclare those member names. What this says is that the defining class is insisting on that name for its own internal use. In this way it protects itself from children classes that may otherwise abuse that member. OTOH, protected members allow child classes to do what they will. So, the argument that a type contains members that are always visible is a misnomer -- there are times when a type may want to restrict its internal mechanism so that even subclasses can not access it. This, undoubtedly, will disturb those who favor a purely dynamic style of coding since for those sorts of codes, everything is usually kept entirely open without any concern for "safety", which itself is considered a hindrance. Personally I think we can live with only two access levels in PHP but at the same time, it doesn't bother me at all that there are 3 levels.

  21. #46
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots View Post
    What this says is that the defining class is insisting on that name for its own internal use.
    I wonder if that could be a smell suggesting an inheritance hierarchy should be broken up?

  22. #47
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All I really want to see is:

    - Full Unicode support (needed especially in the string manipulation functions)
    - Array shorthand syntax $a = {1, 2, 3};
    - Support for functions and constants in declarations, like below:

    PHP Code:
    function myFunction($option1 0$option2 OPT2_DEFAULT$option3 getOpt3Default())
    {
        
    // etc...
    }

    class 
    xyz
    {
        public 
    $option1 0;
        public 
    $option2 OPT2_DEFAULT;
        public 
    $option3 getOpt3Default();

        
    // etc...



  23. #48
    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 BerislavLopac View Post
    a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times?A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property,
    Pragmatically speaking, the bigger problem is that parent and child classes are tightly coupled. I'm not sure, but I'm inclined to see this behavior as an attempt to alleviate that problem. It's probably not a successful attempt; it's better to find alternatives to implementation inheritance.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #49
    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 BerislavLopac View Post
    a) I see absolutely no reason, except for the paranoia of incompetent programmers, why would a property not be inherited at all times?A class is a representative of a type, and a type is defined by the properties it displays; so if a type has some property,
    This is an interesting idea I've never thought through. My initial reaction is this: Pragmatically speaking, the bigger problem is that parent and child classes are tightly coupled. I'm not sure, but I'm inclined to see the behavior of private properties as an attempt to alleviate that problem. It's probably not a very successful attempt; it's better to find alternatives to implementation inheritance.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #50
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Czaries View Post
    - Support for functions and constants in declarations, like below:

    You can already use constants, and I'm not sure being able to use functions is truly required, since you can easily work around it.


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
  •