| # |
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 |
| # |
Jul 24th 2017, 15:00 |
inoas |
if we want to go ahead - pick php 7.1 now |
| # |
Jul 24th 2017, 15:00 |
inoas |
yeah, think about it, come on! ;) |
| # |
Jul 24th 2017, 15:00 |
dereuromark |
oh come on, |
| # |
Jul 24th 2017, 15:00 |
inoas |
verbosity kills productivity |
| # |
Jul 24th 2017, 14:59 |
inoas |
there is a 500 chars reading issue on big source code |
| # |
Jul 24th 2017, 14:59 |
inoas |
there is no 3 char issue |
| # |
Jul 24th 2017, 14:59 |
inoas |
anyway, grouping stateful objects into 3 kinds: builders, readers and vanilla objects is a very consistent concept |
| # |
Jul 24th 2017, 14:59 |
dereuromark |
also: lets for once lead by example and not run behind the others for years. We might be able to have a clear, PHP7 supportive API rather sooner than later even. |
| # |
Jul 24th 2017, 14:59 |
dereuromark |
it is :slightly_smiling_face: by not limiting yourself to a 3char issue |
| # |
Jul 24th 2017, 14:59 |
inoas |
most other code and libraries are concise and verbose? <= how is that possible at the same time ;)? |
| # |
Jul 24th 2017, 14:58 |
dereuromark |
ionas: you are wrong IMO, most other code and libraries are already concise and verbose here. they all use explicit getters and setters, and I would not use laravel for reference here though :slightly_smiling_face: |
| # |
Jul 24th 2017, 14:57 |
inoas |
$immutableRequest->data() is unambigious |
| # |
Jul 24th 2017, 14:56 |
inoas |
$queryBuilder->where() really is unambigouous |
| # |
Jul 24th 2017, 14:56 |
inoas |
if you do not use an IDE then that is you (mine ;-) choice ... but if you do you can click the class and also you should know what context an object works in... maybe builders should be called builders |
| # |
Jul 24th 2017, 14:55 |
jeremyharris |
that’s why I brought up the marketing aspect. unfortunately, it’s part of the whole deal |
| # |
Jul 24th 2017, 14:55 |
inoas |
tbh |
| # |
Jul 24th 2017, 14:55 |
inoas |
and dereuromark the barrier will not go down... people will see the verbosity and walk to laravel. |
| # |
Jul 24th 2017, 14:54 |
inoas |
I don't want to diminish the work being done to have a consistent API across all of Cake - I think that's very important. <= leaving out set or get PER class or there doesnt make it inconsistent - magic setters/getters may do ... and they are luckly gone |
| # |
Jul 24th 2017, 14:53 |
inoas |
yeah all I am saying is - me neither ;-) |
| # |
Jul 24th 2017, 14:53 |
jeremyharris |
I wasn’t suggesting that :slightly_smiling_face: |
| # |
Jul 24th 2017, 14:53 |
inoas |
so no work is wasted! |
| # |
Jul 24th 2017, 14:53 |
inoas |
@jeremyharris https://github.com/cakephp/cakephp/issues/10930#issuecomment-317447201 I did not want to - in any way - reverse the removal of magic getters/setters |