SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 41 of 41
  1. #26
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Guess what? Inner/Nested class is also on RFC now, this is incredible! To me, an implementation of an inner class is like a dream come true, I honestly wouldnt expect that until PHP 6.0. But anyway, we can hope cant we?
    https://wiki.php.net/rfc/nested_classes

  2. #27
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Does PHP not have this problem?
    [it used to be...] that any attempt to [...] mix Unicode and 8-bit strings in Python 2.x, it would work if the 8-bit string happened to contain only 7-bit (ASCII) bytes, but you would get UnicodeDecodeError if it contained non-ASCII values. This value-specific behavior has caused numerous sad faces over the years.
    Depends what you mean by 'problem' - PHP does not support mixing Unicode and 8-bit strings if by 'support' you mean anything elegant. But you can mix them if you like - you can concatenate anything because variables are binary data in PHP. What you can do with such a string is a different problem... But anyway, why would anyone want to mix strings of different character sets? If I have such a case I simply convert all the strings to a common character set and then I can mix them and work with them. Perhaps there are more elegant ways to do this in other languages but it's really not so much work.

    Quote Originally Posted by Stomme poes View Post
    I do not know how they addressed speed, but it was also a strong concern at the time.
    Speed is what worries me most in plans/suggestions to implement unicode in PHP. It's enough to compare the speed of mb_ functions to their standard counterparts to see that mb_ functions are not slightly slower - they are *many* times slower. The regex 'u' operator can make preg_match() 50-100 times slower (I don't remember the exact numbers now but the ratio was really that high - tested in real life)! This combined with the complexity of rewriting many core components of PHP (I suppose, I don't know PHP internals) makes this endevour not worth the effort.

    But - a different example is MySQL. From version 4.1 it supports a large number of character sets and to be honest I haven't noticed any performance problems with unicode. I always use UTF-8 and MySQL is very fast. I once did a few benchmarks to see how much slower UTF-8 is than a simple latin on some sample data and the difference was so small that I could hardly measure it. I don't know how they managed to do it but their unicode support is really fast. Now most of the time I don't even bother setting a latin or ascii character set on columns that don't need unicode because there is no noticeable performance drop. And there are all kinds of string functions that work with unicode, string comparisons using so many different and complicated collations, etc. and all is fast. If PHP managed to do it so well then I'm all for native unicode! But I'm afraid we can only dream

  3. #28
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    But anyway, why would anyone want to mix strings of different character sets?
    It's not that, it's that in Python you might have a string of bytes and you might have Unicode (both of which would look like... a string). In Python 3, your strings are always Unicode unless they're binary.

    So there's no "mixing", it's just that no problems are mentioned to you the dev if what you're dealing with is a string of 7-bit ASCII and an encoded string. Many of our strings *would* count as ASCII, and many others would not : )


    But I'm afraid we can only dream
    Dunno, the problems mentioned in the slides posted earlier didn't seem insurmountable, really. Just needs another group of dedicated people with lots of time and patience to return to it : )

  4. #29
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Looks like its in voting phase now, but damn three stupid people already voted 'no'. It would be a pity if PHP doesnt implement this feature by version 5.6, Id be pissed. If they just dont find it useful 'cause they dont understand how to use this very feature, why not just stay out of the voting poll at all? >_<

  5. #30
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    699
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Hall of Famer View Post
    Looks like its in voting phase now, but damn three stupid people already voted 'no'. It would be a pity if PHP doesnt implement this feature by version 5.6, Id be pissed. If they just dont find it useful 'cause they dont understand how to use this very feature, why not just stay out of the voting poll at all? >_<
    Instead of calling people stupid, why not fork the code, implement the features and then show everyone how much it improves your production applications?

  6. #31
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by ahundiak View Post
    Instead of calling people stupid, why not fork the code, implement the features and then show everyone how much it improves your production applications?
    'Cause throughout the past few years of my lives I've come to realize that some people never change and can't be helped. There's a reason why Anthony Ferrara left PHP internal, now that you think about it.

  7. #32
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hall of Famer View Post
    Looks like its in voting phase now, but damn three stupid people already voted 'no'. It would be a pity if PHP doesnt implement this feature by version 5.6, Id be pissed. If they just dont find it useful 'cause they dont understand how to use this very feature, why not just stay out of the voting poll at all? >_<
    Or perhaps they, like I, are tired or piecemeal introduction of features which look cool without any coherent plan as to how they will be used or implemented.

    For example, PHP is an interpreted language. As such, it is possible (certainly not recommended by me but possible) to add prototypical inheritance to the language to make it behave more like Java Script. That would allow for some truly powerful programming patterns to be employed, but at high complexity cost both at the maintenance and end user level. Such an addition would have to be thought out very carefully.

  8. #33
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Or perhaps they, like I, are tired or piecemeal introduction of features which look cool without any coherent plan as to how they will be used or implemented.

    For example, PHP is an interpreted language. As such, it is possible (certainly not recommended by me but possible) to add prototypical inheritance to the language to make it behave more like Java Script. That would allow for some truly powerful programming patterns to be employed, but at high complexity cost both at the maintenance and end user level. Such an addition would have to be thought out very carefully.
    I completely disagree, the usefulness of a language construct/feature is totally subjective, it depends on your coding style and the applications you work with. Some of you may not find inner classes useful, but for me I have a HTML gui package with components and container objects like buttons, checkboxes, textfields, and dropdownlist/ combobox, each has some specific render methods that convert object graphs into html strings ready for output. If inner classes are available, it will be very convenient for me to define renderer classes as inner class for each gui object. These renderer classes can inherit base renderer classes too, and their usage is restricted to their corresponding outer classes.

    Now you see, there are always people who find such featured useful, the fact that you don't find them beneficial or that they don't make sense to you does not dictates that the other developers will feel the same way. This is why you've always gotta give people choices, also you never know when you will find something you ever used or bothered before actually helpful at some point.

    I personally don't find generators and finally clause useful, but if I were on PHP internal if vote yes for these features because I am convinced that there are and will be other developed who benefit from using generators and finally. If I vote no just because I don't understand the usages of a specific feature, I'd consider myself a jerk 'cause I am being mean to the other people who feel differently from me.

    Of course it's a different story if we are talking about misfeatures like goto or langurge constructs that may break the compiler code. I was just referring to people rejecting a suggestion not because they are bad, but that they don't understand it.

  9. #34
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    You're typing and not reading. I'm not opposed to this idea you find super cool and are willing to call names and bicker at people over. I'm opposed to the unorganized incorporation of features without any overarching rhyme or reason. PHP is messy enough as is, it doesn't need more of a mess.

    A prime example of this is database access. There's mysql, mysqli, and pdo. We don't need all three. If PHP was halfway organized and competently managed, when PDO was incorporated into 5.0 then ALL of the alternative db access functions would have been deprecated.

    Namespaces are another debacle. Instead of figuring out how to get them to use the static scope resolution operator, a THIRD scope operator was tacked on, worse they chose the backslash which has to be escaped anytime the namespace is in a string. To be honest, I would have rather seen ::: instead of the \\ everywhere nonsense.

    I don't know the engine well, but I get the impression the maintainers are painted into a corner. The language is on the verge of choking on the ineptitude of its design by committee growth where everything is thrown in without considering the consequences. Eventually these decisions are going to leave the language in a state where nothing meaningful can be added because at least one oddball cool addition will break.

    Understand that in programming when you add something you by necessity take something else away. All programs, even the PHP interpreter, start as clean slates, but each choice made constrains future choice. We are still suffering from the choice to have "." be the connection operator, instead of the scope resolution operator as it is in all other ADA family languages I'm aware of (C, C++, C#, Java, Java Script). Do we really need the assign # to being a comment marker alongside the ADA // and /* */ markup? And what the hell is an error suppression operator "@" doing in the language anyway? Oh, and while having variables off on their own symbol table (which is why they must start with $ in PHP) was a brilliant idea when web-servers ran on Pentium processors clocking around 600mhz it's a major interruption to the workflow of the language these days - most critically variables are not affected in anyway by namespaces. Nor is it even possible to have a namespaced variable. Namespaces remain useful, but they could have been so much more than they are.

    As far as this particular suggestion goes, I'm not particularly opposed to it beyond the fact that its something else to maintain while the language has serious structural problems that need to at least be evaluated and analyzed to determine what, if anything, can be done about them. My feeling is it's already too late - that any major version that tries to fix these problems will have enough BC breaks to split the community just as python got split for a long while between version 2 and 3.

  10. #35
    SitePoint Member
    Join Date
    Oct 2013
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'fits the nature of PHP'....great idea..

  11. #36
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    You're typing and not reading. I'm not opposed to this idea you find super cool and are willing to call names and bicker at people over. I'm opposed to the unorganized incorporation of features without any overarching rhyme or reason. PHP is messy enough as is, it doesn't need more of a mess.

    A prime example of this is database access. There's mysql, mysqli, and pdo. We don't need all three. If PHP was halfway organized and competently managed, when PDO was incorporated into 5.0 then ALL of the alternative db access functions would have been deprecated.

    Namespaces are another debacle. Instead of figuring out how to get them to use the static scope resolution operator, a THIRD scope operator was tacked on, worse they chose the backslash which has to be escaped anytime the namespace is in a string. To be honest, I would have rather seen ::: instead of the \\ everywhere nonsense.

    I don't know the engine well, but I get the impression the maintainers are painted into a corner. The language is on the verge of choking on the ineptitude of its design by committee growth where everything is thrown in without considering the consequences. Eventually these decisions are going to leave the language in a state where nothing meaningful can be added because at least one oddball cool addition will break.

    Understand that in programming when you add something you by necessity take something else away. All programs, even the PHP interpreter, start as clean slates, but each choice made constrains future choice. We are still suffering from the choice to have "." be the connection operator, instead of the scope resolution operator as it is in all other ADA family languages I'm aware of (C, C++, C#, Java, Java Script). Do we really need the assign # to being a comment marker alongside the ADA // and /* */ markup? And what the hell is an error suppression operator "@" doing in the language anyway? Oh, and while having variables off on their own symbol table (which is why they must start with $ in PHP) was a brilliant idea when web-servers ran on Pentium processors clocking around 600mhz it's a major interruption to the workflow of the language these days - most critically variables are not affected in anyway by namespaces. Nor is it even possible to have a namespaced variable. Namespaces remain useful, but they could have been so much more than they are.

    As far as this particular suggestion goes, I'm not particularly opposed to it beyond the fact that its something else to maintain while the language has serious structural problems that need to at least be evaluated and analyzed to determine what, if anything, can be done about them. My feeling is it's already too late - that any major version that tries to fix these problems will have enough BC breaks to split the community just as python got split for a long while between version 2 and 3.
    First of all, I apologize if I made it sound like I was specifically directing to you. When I use the word 'you', it does not necessarily mean the very person I am replying to, more like a collection of people of certain type. Hopefully this clears confusion, I didnt mean to offend you.

    Yes I agree with you on the namespace part, the backslash is ugly, a leading backslash is uglier(why wont class name resolve to root namespace if not imported? Its done the same way not only in C++,Java/C#, but also Python and ruby). I'd love to see wildcard namespace import being enabled, and if this is not possible at least gives us an opportunity to import one core namespace in which all of its classes are used in pretty much all other classes so that I do not have to manually import my object, string and array classes. Unfortunately, there is not even a proposal of namespace refinement on PHP RFC. It will probably get declined even if it exists, after witnessing what happened with anonymous class. *sigh*


    Quote Originally Posted by Rossyjordin View Post
    'fits the nature of PHP'....great idea..
    lol... Come to think about it, this 'fits the nature of PHP' thing is by far the biggest bullsh*t I've ever heard about PHP Dev, some people have absolutely no idea that languages evolve over time just as we human beings. Objects dont fit the nature of PHP at all, the language started as a pure procedural language. Oh wait a minute, it was actually a template language when it was born. thats the true nature of PHP some people are so desperately trying to find!

  12. #37
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    some people have absolutely no idea that languages evolve over time
    They do evolve, (even Ada, w00t). But some evolve chaotically, with seemingly random things stuck in here and there. Others are planned by a small, core group. And then some try to be planned by a small, core group after a bunch of seemingly random things were already stuck here and there and you get to dance on eggshells in stilettos while juggling flaming piranhas.

  13. #38
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    They do evolve, (even Ada, w00t). But some evolve chaotically, with seemingly random things stuck in here and there. Others are planned by a small, core group. And then some try to be planned by a small, core group after a bunch of seemingly random things were already stuck here and there and you get to dance on eggshells in stilettos while juggling flaming piranhas.
    Good point, consider PHP added goto back in PHP 5.3 and then rejected property accessors in PHP 5.5, it apparently is evolving chaotically... *sigh*

  14. #39
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    I'd forgotten about goto being added. I will now have nightmares about programming the Commodore 64 for a week. Thank you.

  15. #40
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    370
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    I'd forgotten about goto being added. I will now have nightmares about programming the Commodore 64 for a week. Thank you.
    Since goto was added in PHP 5.3, I doubt you will see it in most available PHP scripts. But well, it can be annoying if you do spot goto being used in a script, I mean, its so painful for the eyes.

  16. #41
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Once it reaches the CPU there's gonna be jmp statements all over the place anyway. Personally I put goto up there with eval as features of the language which are very powerful but which there is almost always a more appropriate method to accomplish what they do. As language goto's go, PHP's is pretty limited since it won't let you hop into loops or into/out of functions. The ability to do that in C was the stuff of legendary nightmares.

    Programmers should be pragmatic, not dogmatic. Saying goto is "always" evil is dogmatic. Saying it is usually evil, and that there will be usually be a better way, is pragmatic. Sometimes though, goto will be useful.

    That said, I haven't had occasion to use it yet.


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
  •