# |
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 |
# |
Jul 24th 2017, 15:01 |
inoas |
I am not |
# |
Jul 24th 2017, 15:01 |
dereuromark |
you are confusing and mixing all kind of issues here now, though. |
# |
Jul 24th 2017, 15:01 |
inoas |
etc |
# |
Jul 24th 2017, 15:01 |
inoas |
add use_strict now |
# |
Jul 24th 2017, 15:00 |
inoas |
I'd love that |