SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 41
  1. #1
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)

    PHP Anonymous Class Support is now on RFC!

    Oh man I am so happy to know that, was expecting nested or anonymous class for a while now, and the latter looks totally possible for PHP 5.6. Whats real amazing is that it was just proposed on Sep 22th, and now its already 'under discussion' rather than 'in draft'. Here is one example as given from the rfc page:

    PHP Code:
    class MyObject extends MyStuff {
        public function 
    getInterface() {
            return new class implements 
    MyInterface {
                
    /* ... */
            
    };
        }

    Of course the example above only shows the proposed syntax, the power of anonymous classes will be more evident working with event classes. I actually consider the syntax a little bit verbose, why not use this instead?

    simple syntax:
    PHP Code:
    return new MyInterface{


    vs proposed syntax:
    PHP Code:
    return new class extends MyInterface{


    But even with this minor verbosity, the anonymous class proposal is really nice and we should all support it to make to PHP 5.6. I'd love to see inner/nested class as well at some point, but Id already be happy if at least anonymous class support is added. I mean, one is better than zero like always?

    Also there are other proposed features on PHP RFC that I'd really love to see in PHP 5.6, such as Extended Keyword Support(so that you can create a class called Array rather than attempting to avoid keyword conflict) and Named Parameters(likely a C# port, but its gonna be nice). Looks like Java style variable number argument-list feature is already accepted and will be implemented in PHP 5.6, it looks great and still we need a bigger feature comparable to PHP 5.3's namespace, PHP 5.4's trait and PHP 5.5's generator in PHP 5.6 since it's a major new version. Anonymous class can be this big feature, dont you agree? For me though, this is definitely the most exciting feature to be added to PHP since namespace, I cant wait to see it in action already.

  2. #2
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,412
    Mentioned
    45 Post(s)
    Tagged
    12 Thread(s)
    I've never come across anonymous classes before. What are they used for and why are they useful? And which other languages have this feature?

  3. #3
    PHP Guru lampcms.com's Avatar
    Join Date
    Jan 2009
    Posts
    921
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In Java they are pretty common. Usually they are used to implement an interface in-place. Common use of them in the UI design where you need to implement some type of event listener with minimal amount of extra coding, so you write a few lines of code and implement inside of your class as anonymous inner class (a class inside a class). I am not sure if php will allow inner classes.
    My project: Open source Q&A
    (similar to StackOverflow)
    powered by php+MongoDB
    Source on github, collaborators welcome!

  4. #4
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,162
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hall of Famer View Post
    simple syntax:
    PHP Code:
    return new MyInterface{


    vs proposed syntax:
    PHP Code:
    return new class extends MyInterface{


    I'm not sure I agree with your "simple" syntax. That limits what you can do. With the proposed syntax, it seems to me they are allowing me to extend other classes or implement an interface, or I could just create an anonymous class that has no tie to an existing class/interface. It would also seem appropriate, that it would permit me to implement multiple interfaces, not just one.

    So the following becomes an option (which is VERY cool in my opinion)
    PHP Code:
    return new class extends MyBaseClassMyInterfaceMyInterface2 {


    How would you do that with the simplified syntax? Not to mention, writing new MyInterface is just awkward. Interfaces are not classes, they can't be constructed that way, they have to be implemented (personal opinion).

    @fretburner ; This result was a good read, I thought it summed it up well. C# and Java both have this.

    In C# specifically, it comes into great use when using LINQ to SQL. You can return a new object containing the columns from your table on the fly and then iterate through them without the need to create an actual class. Most cases (all cases?) anonymous classes are to be short lived. Meaning you don't see value of a physical class in your project because it will only be used in this particular scenario; once you exceed that, you should consider creating a physical class (my opinion).

  5. #5
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Very interesting concept. I'm struggling to think of any practical applications where this is useful though... other than saving a couple of lines of code (if that!) what advantage is there over formally defined classes?

    It does strike me as an odd thing to desire from an OOP perspective as arbitrarily constructing objects throughout the code is a bad idea and I can't think of a single use for this that wouldn't involve exactly that. From a TDD perspective this sounds like a rather large headache.

  6. #6
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by cpradio View Post
    I'm not sure I agree with your "simple" syntax. That limits what you can do. With the proposed syntax, it seems to me they are allowing me to extend other classes or implement an interface, or I could just create an anonymous class that has no tie to an existing class/interface. It would also seem appropriate, that it would permit me to implement multiple interfaces, not just one.

    So the following becomes an option (which is VERY cool in my opinion)
    PHP Code:
    return new class extends MyBaseClassMyInterfaceMyInterface2 {


    How would you do that with the simplified syntax? Not to mention, writing new MyInterface is just awkward. Interfaces are not classes, they can't be constructed that way, they have to be implemented (personal opinion).
    Well its actually simple enough, below are two possible proposals:

    PHP Code:
    return new MyBaseClassMyInterfaceMyInterface2{

    }; 
    Or:

    PHP Code:
    return new (MyBaseClassMyInterfaceMyInterface2{

    }; 
    There is little ambiguity with the simpler syntax, they may feel more like java or C# but apparently there's a reason why anonymous classes are designed this way in these two languages. I don't see how awkward it is to use the syntax new Interface since that's exactly how java's anonymous class works and no one complains. I know PHP is not java, it's nice to invent new syntax unique and natural to PHP, but inventions are only innovations when their advantages outweigh disadvantages.

  7. #7
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,162
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    @Hall of Famer ; That's fair enough. I think they may be trying to reuse existing logic in their parser, which already supports finding class ... extends ... (just a guess)

    Ah, think about it. With your approach, it would create a new instance of MyBaseClass instead of an anonymous class that extends MyBaseClass (without parser changes).

  8. #8
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Yes that's a possibility, I'd say its a bit more difficult to implement the shorthand syntax I suggested, but it seems that the developer said he has tried and it worked. He didn't like it cause it feels more java, but I disagree since after all java does not hold copyrights of this anonymous class syntax anyway. I can say the same thing on PHP's anonymous/ lambda functions look like javascript, and nobody seems to have a problem with that.

    I'd personally be more interested in performance difference, if there is a clear justification that the simpler syntax is more expensive on performance I'd completely drop my suggestion. Yeah, it's meant to be a suggestion not an argument, as even with the more verbose syntax I'd rather have this feature than not. The verbosity of syntax is a small price to pay for a big feature to be implemented, don't you think so?

  9. #9
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,162
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hall of Famer View Post
    Yes that's a possibility, I'd say its a bit more difficult to implement the shorthand syntax I suggested, but it seems that the developer said he has tried and it worked. He didn't like it cause it feels more java, but I disagree since after all java does not hold copyrights of this anonymous class syntax anyway. I can say the same thing on PHP's anonymous/ lambda functions look like javascript, and nobody seems to have a problem with that.

    I'd personally be more interested in performance difference, if there is a clear justification that the simpler syntax is more expensive on performance I'd completely drop my suggestion. Yeah, it's meant to be a suggestion not an argument, as even with the more verbose syntax I'd rather have this feature than not. The verbosity of syntax is a small price to pay for a big feature to be implemented, don't you think so?
    Yes, I agree with that. And I think you have a valid argument. I just see the readability of it to be confused with new MyBaseClass(); versus new MyBaseClass { }; produce two different results to be really hard to detect just by reading it.

  10. #10
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,034
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    Things we need: UTF Encoding
    Things we get: Anonymous classes

    :sigh: PHP.

  11. #11
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Things we need: UTF Encoding
    Things we get: Anonymous classes

    :sigh: PHP.
    As far as I know, anonymous class has not made it to voting phase yet... It has just been recently proposed, that's it.

  12. #12
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,034
    Mentioned
    65 Post(s)
    Tagged
    0 Thread(s)
    It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.

  13. #13
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.
    I'm not quite sure tbh, can't find a pattern that describes what features are more likely to be added to PHP than the others. I wonder why goto makes it to PHP, it's one of the worst programming practices for coders of any experience level.

  14. #14
    SitePoint Member
    Join Date
    Feb 2009
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Andrei Zmievski did a slideshare of what went wrong with UTF-8 and PHP

    http://www.slideshare.net/andreizm/t...code-and-php-6

    It seems to be more than grunt work is needed as it was tried but it effectively failed for a few reasons. Being hit with sticks may be far more pleasurable than trying to get that working across everything without major BC breaks.

    This anonymous class thing is one guy doing a patch which would of probably got a lot more negative conversation prior to Anthony Ferrera leaving the internals. The voting counts on many things such as BC break, maintenance overhead, implementation, fits the "nature of PHP" etc. It will likely need a 66% vote like the failed properties vote.

  15. #15
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    umm what happened to Anthony Ferrera? Why did he leave PHP internals? I wonder what it means to 'fits the nature of PHP', does PHP have a nature?

    Anyway it is interesting to see if an RFC actually reaches exactly 2/3 of the votes and barely passes the requirement, property accessors still dont come that close to cause a serious controversy.

  16. #16
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,279
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I wonder what it means to 'fits the nature of PHP', does PHP have a nature?
    I'm not sure if PHP has one, though I suspect it does, but many languages have a "feel" to them, or a more-socially-accepted-way-of-doing-things, determined by the community. In Python, it's called "Pythonic", and means little more than "yeah that other way works but it doesn't respect our Zen Of Python guidelines we strive to live by". An example would involve the difference between using some well-loved and built-in functionality to help implement some new idea, as opposed to cobbling the new idea from many other areas and not using stuff someone bothered to optimise the compiler for, or cobbled together in a way that doesn't match the readability style of similar ideas. That kind of thing.

    The opposite would regard the saying "You can write FORTRAN in any language".

  17. #17
    SitePoint Member
    Join Date
    Feb 2009
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'fits the nature of PHP' is one of those things that caused a lot of arguments in prior RFCs. Basically Stomme poes is right but in PHP land the 'way' is largely a figment. For example Wordpress plugin development is probably very different from large scale/long life time development so even seeing things "as a way" is likely to be problematic as different approaches have different benefits and change can benefit one and be detrimental to the other. For example upgrading to PHP5.4 and running E_ALL can be problematic as strict is now included and it can it can break a lot of legacy code if E_ALL is deemed important and that upsets at least one person heavily, the code can be easily rectified if it has good unit test/integration test coverage but the development has to live in a world where having good automated tests is important. Sometimes the PHP way is chuck it out cheap and quick and then throw it at a server. Other times the cost of keeping it has to be taken heavily into account so that approach is just not feasible. I personally don't believe there is a way, but some people are quite attached to what they view PHPs identity is (sometimes that identity is simply "Its not Java").

    Anthony writes about why he left here
    http://blog.ircmaxell.com/2013/09/ra...internals.html

    And Phil Sturgeon also has these two posts here about life in the internals as it can be quite intimidating.
    http://philsturgeon.co.uk/blog/2013/...rnals-workflow
    http://philsturgeon.co.uk/blog/2013/...tayim-v-sanity

    I know a developer who describes a group of developers as an "argument of developers" and it is pretty much the case in internals as new functionality often has to be forged in quite a violent process. Possibly spend months doing patches, rfc's and being constantly active in what seems to be quite stressful discussions and then get a no vote at the end with no clear reason.

    The strongest voices on internals who would usually be against something like anonymous classes( who are also the ones more likely to implement the UTF-8 stuff) are staying pretty quite in this discussion so far so it will be interesting to see how it turns out.

  18. #18
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    It will. It has all the markings of "Look, shiny" that appeals to the dev team, while the grunt work changes the language needs to have done get neglected. Proper UTF-8 handling being chief among them.
    I disagree as to UTF-8 - this is bound to make PHP overall slower while providing not enough benefit to be worth it. The sites I code are all UTF-8 and most often in languages that have non-English letters and I don't feel the need for native UTF-8 support at all. We have mb functions, we have the regex 'u' modifier - that's enough to cover all my needs, and still I find using them pretty rarely. Just improving the existing mb library is the best direction IMHO.

    However, I agree that anonymous classes are nothing really important. I'd rather see a complete and fully usable namespace support without the present quirks.

  19. #19
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    I disagree as to UTF-8 - this is bound to make PHP overall slower while providing not enough benefit to be worth it. The sites I code are all UTF-8 and most often in languages that have non-English letters and I don't feel the need for native UTF-8 support at all. We have mb functions, we have the regex 'u' modifier - that's enough to cover all my needs, and still I find using them pretty rarely. Just improving the existing mb library is the best direction IMHO.

    However, I agree that anonymous classes are nothing really important. I'd rather see a complete and fully usable namespace support without the present quirks.
    Just because *you* don't use features often doesn't make them pointless. A lot of the sites I work on daily are multi-lingual. Yes, you can make it work.. but it presents yet another hurdle for developers. It's something that causes annoying bugs and constantly having to be "on guard" while developing.

    I haven't looked into it and there's probably a reason but why can't the PHP developers add unicode support and just make it off by default (for now) and available in php.ini? That avoids backwards compatibility issues because it only gets enabled by people who have explicitly decided to use it.

    That said, I agree with your opinion on namespaces. One of the biggest missing features is being able to load legacy code into an explicit namespace e.g. require_once 'someclass.php', 'My\Legacy\Code\Namespace';

  20. #20
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Just because *you* don't use features often doesn't make them pointless. A lot of the sites I work on daily are multi-lingual. Yes, you can make it work.. but it presents yet another hurdle for developers. It's something that causes annoying bugs and constantly having to be "on guard" while developing.

    I haven't looked into it and there's probably a reason but why can't the PHP developers add unicode support and just make it off by default (for now) and available in php.ini? That avoids backwards compatibility issues because it only gets enabled by people who have explicitly decided to use it.
    I didn't mean this was pointless but it would have a serious (in my opinion) drawback of making PHP slower. Having an option for on/off in php.ini also doesn't cut it because then I either choose to slow down all of my site or not use unicode at all. The use cases I find most often in are ~95% ascii and ~5% unicode - then it's logical I want to use unicode only in those 5% without slowing down the rest. If there was a way to easily choose on run-time whether I want to use unicode or not for each statement/function/method/etc. then I'm all for it (for instance something la MySQL's COLLATE keyword).

  21. #21
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by pbyrne84 View Post
    'fits the nature of PHP' is one of those things that caused a lot of arguments in prior RFCs. Basically Stomme poes is right but in PHP land the 'way' is largely a figment. For example Wordpress plugin development is probably very different from large scale/long life time development so even seeing things "as a way" is likely to be problematic as different approaches have different benefits and change can benefit one and be detrimental to the other. For example upgrading to PHP5.4 and running E_ALL can be problematic as strict is now included and it can it can break a lot of legacy code if E_ALL is deemed important and that upsets at least one person heavily, the code can be easily rectified if it has good unit test/integration test coverage but the development has to live in a world where having good automated tests is important. Sometimes the PHP way is chuck it out cheap and quick and then throw it at a server. Other times the cost of keeping it has to be taken heavily into account so that approach is just not feasible. I personally don't believe there is a way, but some people are quite attached to what they view PHPs identity is (sometimes that identity is simply "Its not Java").

    Anthony writes about why he left here
    http://blog.ircmaxell.com/2013/09/ra...internals.html

    And Phil Sturgeon also has these two posts here about life in the internals as it can be quite intimidating.
    http://philsturgeon.co.uk/blog/2013/...rnals-workflow
    http://philsturgeon.co.uk/blog/2013/...tayim-v-sanity

    I know a developer who describes a group of developers as an "argument of developers" and it is pretty much the case in internals as new functionality often has to be forged in quite a violent process. Possibly spend months doing patches, rfc's and being constantly active in what seems to be quite stressful discussions and then get a no vote at the end with no clear reason.

    The strongest voices on internals who would usually be against something like anonymous classes( who are also the ones more likely to implement the UTF-8 stuff) are staying pretty quite in this discussion so far so it will be interesting to see how it turns out.
    I see, so he withdrew all the RFC proposals he made upon leaving PHP internal? That explains why there is a sudden increase in the number of withdrawn RFCs sinc early September, must say its a big loss for PHP community.

  22. #22
    SitePoint Member
    Join Date
    Sep 2013
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hall of Famer View Post
    Yes that's a possibility, I'd say its a bit more difficult to implement the shorthand syntax I suggested, but it seems that the developer said he has tried and it worked. He didn't like it cause it feels more java, but I disagree since after all java does not hold copyrights of this anonymous class syntax anyway.
    I also said that
    it doesn't make good sense to pass arguments to a constructor that may not yet be defined
    it is consistent with how a class is declared now
    it makes the patch to the parser and the logic therein much simpler ...
    that it looks like java everyone can understand, so that's what they tend to remember, but there are actually super good reasons for me to prefer this syntax over the other.

    About needing native unicode support; are you mad or are you mental !? you do not want PHP to support unicode natively, learn a bit about what unicode actually is, and think about how that impacts on every character of input and output; and then rest assured that the people making these decisions know what they are ruddy well up too, and it's high time people stopped using pernicious rhetoric to show their gratitude.

    pbyrne84, you have a very low opinion of the way internals works, I don't know who you are, so don't know where that opinion is rooted ...

    Antony leaving is a blow; I won't pretend that trying to work within internals is easy, it is not. But if you don't expect that, then you're being very naive: The people who identify as patrons of internals are very, very intelligent, highly motivated, high opinionated and highly experienced individuals, to spend any time there at all and know what is going on around you, those attributes are an absolute prerequisite. When you are in this kind of environment, sparks fly, emotions run high.

    I have a feeling Antony will be back, he is one of those individuals, the situation overwhelmed him, he'll come back, I think ... but it's a wake up call, for everyone involved. PHP thrives on individuals such as Antony, it's ecosystem requires them to function, moreover to continue evolving, loose to many and the ecosystem could, and will suffer.

    To look at the internals mailing list and conclude that this is how PHP works, is a bit like looking at books in the old testament and deciding that is how all Christians work; internals is a very very restrictive lens through which to view how PHP works, I do hope that nobody is put off getting involved because of the myth that everyone is nasty to everyone else and life is one big argument. I don't find it to be a big argument at all, if you fancy an argument then there's always one to be picked, but you can choose to engage in that or not; you can sit fixing bugs or looking at patches too, you can do translations, you can help with QA, you can run test suites, you can do a billion things that are useful, don't focus on one mailing list, it is just one mailing list.

    I like Phil, he calls a spade a spade, he does have a set of internals specs on, but he battles through anyway .... note that, he chooses to engage in that medium; here's a guy that also engages in hundred mile bicycle rides ... draw your own conclusions !!

    On a more technical note, nested classes are also possible, this lays a kind of foundation for it, whether I bother to put any time into it depends on the success of this patch ...

    That's all I have to say about that ...

  23. #23
    SitePoint Member
    Join Date
    Feb 2009
    Posts
    17
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by krakjoe View Post
    pbyrne84, you have a very low opinion of the way internals works, I don't know who you are, so don't know where that opinion is rooted ...
    It is rooted from reading pretty much every piece of internals for the last two years. I think the list should be paid more attention to as it explains why some things appear and why some things don't. Personally I don't know how traits really appeared but that is my own religion speaking.

    Quote Originally Posted by krakjoe View Post
    Antony leaving is a blow; I won't pretend that trying to work within internals is easy, it is not. But if you don't expect that, then you're being very naive: The people who identify as patrons of internals are very, very intelligent, highly motivated, high opinionated and highly experienced individuals, to spend any time there at all and know what is going on around you, those attributes are an absolute prerequisite. When you are in this kind of environment, sparks fly, emotions run high.
    I do think they are very smart, in fact I'd happily listen/read anything that most of them say. Most of the issue comes from the human side of their personalities start to dominate as reactions of "If you want PHP to be like Java, write Java" have been uttered too many times by at least one of the lead individuals as rhetoric. Being smart does not mean all actions from that person are smart. That might be a little thing but it is highly destructively shallow.

    Quote Originally Posted by krakjoe View Post
    To look at the internals mailing list and conclude that this is how internals works is a bit like looking at books in the old testament and deciding that is how all Christians work; internals is a very very restrictive lens through which to view how internals works, I do hope that nobody is put off getting involved because of the myth that everyone is nasty to everyone else and life is one big argument. I don't find it to be a big argument at all, if you fancy an argument then there's always one to be picked, but you can choose to engage in that or not; you can sit fixing bugs or looking at patches too, you can do translations, you can help with QA, you can run test suites, you can do a billion things that are useful, don't focus on one mailing list, it is just one mailing list.
    No I pay very close attention as I find it very interesting, the behaviour is also very common of smart people. But smart people with strong personalities can easily dominate smarter people who are less eloquent, especially in numbers. If anything truth to be told I believe everyone is more likely to get dumber in a social environment due to the group mind gets momentum and the feeling of righteousness overtakes actually being right. That I feel is human, but it is very infuriating to be on the receiving end as I have experienced quite a few times. I would just describe it as emotionally nullifying. But that is a personality thing, some people thrive in that environment as it is where they are strongest and it may be more akin to the high grade pressured educational environments they may of came from. Personally I have a massive dislike for that sort of environment so that also may be where a chunk of my negative bias comes from.

    I'm pretty knackered but I hope I have replied with the diligence your reply required.

  24. #24
    SitePoint Addict bronze trophy
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    351
    Mentioned
    6 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by krakjoe View Post
    On a more technical note, nested classes are also possible, this lays a kind of foundation for it, whether I bother to put any time into it depends on the success of this patch ...

    That's all I have to say about that ...
    That will indeed be amazing, I actually like inner/nested class even better than anonymous class. But just as you said, anonymous class lays a foundation for the more complex inner class feature, so its not a good idea to expect nested class until anonymous class is at least available. For now I wish you good luck getting this implemented, even if some people dont see the potential of anonymous class right now it will prove to be useful sooner or later.

  25. #25
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,279
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Off Topic:


    Personally I have a massive dislike for that sort of environment so that also may be where a chunk of my negative bias comes from.
    I wonder how many OS projects would be so much further off if this weren't such a regular, persistent occurrence.


    I disagree as to UTF-8 - this is bound to make PHP overall slower while providing not enough benefit to be worth it.
    (assuming "UTF-8" here meant "Unicode" instead) Maybe Python figured it was already slow as a handicapped duck so it didn't matter because when they need speed they use C? but they had fought the problems of mixing Unicode and plain-strings and encoding and decoding too long, mostly/especially with libraries and packages (rather than individual developers within their own code) that they'd had enough, and made all text Unicode by default. It was likely very awful to convert everything... which is why moving to 3 from 2 was/is so slow... but worth it. Where I work, even if we only used Latin-1, we wouldn't remain 7-bit ASCII because too many accented characters (fwiw, we use UTF-8, the encoding, everywhere. But not all of our strings are Unicode strings, because we still use 2.x... same as everyone using PHP today I assume?).
    Does PHP not have this problem?
    Quote Originally Posted by python release notes
    [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.
    I do not know how they addressed speed, but it was also a strong concern at the time.


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
  •