Log message #4056285

# At Username Text
# Jul 24th 2017, 15:23 cleptric Foe example, not even Hetzner offers php 7.1 on their managed web server right now ^^
# Jul 24th 2017, 15:23 hmic it's the hosters you have been talking about that move there
# Jul 24th 2017, 15:22 cleptric Hmm, I don’t see any needs to move to a containerised environment right now. Sure it has his benefits, but for small websites, a stand alone server is just fine.
# Jul 24th 2017, 15:22 hmic by introducting so much of bc changes/breakage in cake4, why not show the balls and go all in with the features that are available in the langugage (by then), which are relly usefull not just nice to have ones actually!
# Jul 24th 2017, 15:21 hmic so, if cake4 gets released within 2017, you might have a case. if thats not the plan *cough cough* the world will have changed by then (to the better i hope)
# Jul 24th 2017, 15:20 hmic cleptric: like i said, everybody moves to containers, needs to, no matter which frameowrk. the hosters will have adapted within a year - all of them, or gone out of business. - my prediction alone of course *not*.
# Jul 24th 2017, 15:19 hmic but, with the introduction of the BC and code breaking introduction of middlewares, the upgraded version requirement to 5.6 and things like that - you should have the balls to play the in front of the herd game to the full extend! it could very well be a losing game though.
# Jul 24th 2017, 15:19 cleptric Libsodium alone would be super awesome to have for Cake 4. But letting a lot of folks out there standing in the rain because the don’t have a php72 environment is also a bad decision
# Jul 24th 2017, 15:17 hmic to make it clear: i am *not* saying cake should get in front of the others. i very much appreciated the long term support and lifetime of the project, and beeing BC to the point of feasibility, maybe beyond even...
# Jul 24th 2017, 15:17 neon1024 Pushing the minimum PHP version up also excludes lots of other libraries
# Jul 24th 2017, 15:16 cleptric That’s ok IMO
# Jul 24th 2017, 15:15 cleptric Php 7.1, the version we picked for Cake 4, will be actively maintained until the end of 2018, with another year of security fixes.
# Jul 24th 2017, 15:15 hmic by swicthing from 5.5 to 5.6 during the 3.x lifetime alone is a break that could not be justified by your reasoning @cleptric
# Jul 24th 2017, 15:14 hmic there are real live benefints, like inoas mentioned. LOTS of them in more recent php releases!
# Jul 24th 2017, 15:12 hmic regarding hosting and php versions: by the time 4.0 will be released, *everything* will be eighter outdated and unsupported - check the php timeline alone - or be run in containers anyways! so go for php-next and keep going for php-next till beta phase starts, then switch to php-next till it's mature. cake does not move this fast.
# Jul 24th 2017, 15:12 jeremyharris maybe some examples are the theoretical url builder, the current http client
# Jul 24th 2017, 15:10 jeremyharris but keeping the query builder the way it is goes against the “make everything consistent regardless” argument
# Jul 24th 2017, 15:10 dereuromark when you dont have any IDE or framework code to see what the method is doing.
# Jul 24th 2017, 15:09 dereuromark especially when reading small code snippets either in docs or on SO or some gist somewhere.
# Jul 24th 2017, 15:09 jeremyharris is there a reason that the way the query builder looks cannot be applied to other classes? I don’t have a great example at the moment
# Jul 24th 2017, 15:09 dereuromark its super useful
# Jul 24th 2017, 15:08 cleptric We had the discussion about the query builder and decided not to touch it. That’s ok
# Jul 24th 2017, 15:07 inoas prefixing all things with set/get - even the query builder = aweful unproductive - especially when maintaining code.
# Jul 24th 2017, 15:06 inoas splitting magic setters/getters, having clear interfaces and less mixed types = really useful yes
# Jul 24th 2017, 15:06 cleptric It’s not cosmetic. It’s really useful IMO
# Jul 24th 2017, 15:05 inoas why isn't picking 7.1 possible right now? who says semver restricts you to platform constraints? - it is a decision, one I have to accept, but really not something "pushing forward"
# Jul 24th 2017, 15:05 inoas meh :(
# Jul 24th 2017, 15:04 inoas cleptric see that's what I mean, why do we add annoying verbosity "to be ahead" which is just cosmetic, but then to be REALLY ahead (return types, strictness) we say "nah not possible because of shared hosts"
# Jul 24th 2017, 15:04 cleptric And picking ph7.1 now isn’t possible and you know why @inoas ;)
# Jul 24th 2017, 15:04 inoas with many objects you mostly work in one context, writing OR reading, with many in both... result: 3 groups of classes that instantiate stateful objects
# Jul 24th 2017, 15:04 cleptric If you can foresee that every one click hoster supports 7.2, we clearly should go all in with php 7.2 for cake 4. Unfortunately this won’t happen. I know, all the fancy kids on the block will use php 7.2 when it’s release but there a lot of guys out there that will even have difficulties getting php 7.1 running.
# Jul 24th 2017, 15:03 inoas well maybe I should fork dereuromarks retrified and create retrified-retrified ;)
# Jul 24th 2017, 15:03 hmic and even they just copied the things from express (node)
# Jul 24th 2017, 15:02 hmic this is PSR, complain there :P
# Jul 24th 2017, 15:02 inoas and use that to build my url options
# Jul 24th 2017, 15:02 inoas but I really don't want to have an ultra verbose url object
# Jul 24th 2017, 15:02 inoas so maybe it was the right choice, you don't know... no A/B test
# Jul 24th 2017, 15:01 inoas the magic getters/setters where a bad thing maybe and we did probably wait to long and should have removed them in 3.x ... however it is always a trade off... markstory says 3.x break left many users confused and behind
# Jul 24th 2017, 15:01 inoas yes hmic
# Jul 24th 2017, 15:01 hmic rather 7.2 or later, as that will be around when 4.0 will be released - i'm up for that!
# Jul 24th 2017, 15:01 dereuromark yes you are. I talk about reading the methods and what they do