# |
Jul 25th 2017, 11:04 |
neon1024 |
Worried you’ll wear away your fingerprints? :slightly_smiling_face: |
# |
Jul 25th 2017, 11:04 |
neon1024 |
lol |
# |
Jul 25th 2017, 11:03 |
inoas |
and the other consequence will be that we add setters/getters everywhere and reading/writing code will be a lot more work |
# |
Jul 25th 2017, 11:03 |
inoas |
The consequence will be that the query builder will be excempted and we will have inconsistency... the reasons being: deprecation of magic method is easier (markstory) and PSR7 enforces get verbosity even on immutable objects (as it seems, which seems to be bad design in PSR7) |
# |
Jul 25th 2017, 11:02 |
inoas |
I am not catching the train now ;)) |
# |
Jul 25th 2017, 11:01 |
neon1024 |
It’s worthwhile to discuss though |
# |
Jul 25th 2017, 11:01 |
inoas |
what?;) |
# |
Jul 25th 2017, 11:01 |
neon1024 |
Not all RFC’s get supported |
# |
Jul 25th 2017, 11:01 |
neon1024 |
You need to stay involved with the discussion. |
# |
Jul 25th 2017, 11:01 |
inoas |
anyway |
# |
Jul 25th 2017, 11:01 |
inoas |
and (even if PSR7 says otherwise) there is no reason to prefix get to get values out of a immutable object |
# |
Jul 25th 2017, 11:00 |
inoas |
you would ue with to clone - all good |
# |
Jul 25th 2017, 11:00 |
neon1024 |
As with PSR7 |
# |
Jul 25th 2017, 11:00 |
neon1024 |
No, you’d use with |
# |
Jul 25th 2017, 11:00 |
inoas |
I am not calling you a robot, I am saying we are NOT robots |
# |
Jul 25th 2017, 11:00 |
inoas |
if you are working with immutable objects there is really no reason to add "get" |
# |
Jul 25th 2017, 11:00 |
neon1024 |
I don’t think calling me a robot is productive discussion :slightly_smiling_face: |
# |
Jul 25th 2017, 11:00 |
inoas |
robots do not |
# |
Jul 25th 2017, 10:59 |
inoas |
cause humans understand context |
# |
Jul 25th 2017, 10:59 |
neon1024 |
You’ve swapped my example to the query class |
# |
Jul 25th 2017, 10:59 |
inoas |
yes |
# |
Jul 25th 2017, 10:59 |
neon1024 |
You’ve added context already |
# |
Jul 25th 2017, 10:59 |
inoas |
where $query->getWhereClause() does not |
# |
Jul 25th 2017, 10:59 |
inoas |
if you are a robot then you should not code... you do not need a docblock do know that $query->stuff() modifies the query |
# |
Jul 25th 2017, 10:59 |
neon1024 |
(shrug) |
# |
Jul 25th 2017, 10:59 |
neon1024 |
What is stuff doing? |
# |
Jul 25th 2017, 10:59 |
neon1024 |
`$something->stuff()` |
# |
Jul 25th 2017, 10:59 |
neon1024 |
You don’t have a docblock when calling a method. |
# |
Jul 25th 2017, 10:58 |
neon1024 |
Pfft |
# |
Jul 25th 2017, 10:34 |
inoas |
aynway I won't answer to that ticket anymore... there has been one answer by neon1024 basically saying the discoverability lacks when you don't have consistent set/get classes... and I think thats false as you cannot pretty much work with tools where you did not even read the docblock or 1st chapter of the docs... if you know you are working with a builder (we are not dumb robots, are we?), then you know calling methods will mutate the state of the object |
# |
Jul 25th 2017, 10:31 |
inoas |
dereuromark if you make a statement it may happen that it counts also for what you do not support... that's just a good culture of finding solutions via discussions |
# |
Jul 25th 2017, 10:11 |
johnwayne |
Sometimes you have to check out whole process from A to B -> to be sure :) |
# |
Jul 25th 2017, 10:05 |
littleylv |
so it is a hard-coded path lol |
# |
Jul 25th 2017, 10:03 |
johnwayne |
@littleylv error comes from developer, he has written that warning info in model and I was always getting same error. Thank you for help! |
# |
Jul 25th 2017, 09:14 |
littleylv |
:cakephp: |
# |
Jul 25th 2017, 09:12 |
johnwayne |
@littleylv if I debug that path it looks ok (always path from testing server - localhost, development or staging) but from somewhere during CSV Export hes taking that local url like that is somewhere hard-coded... however thank you for your support and time |
# |
Jul 25th 2017, 08:48 |
neon1024 |
Especially if someone got hold of the session id |
# |
Jul 25th 2017, 08:48 |
neon1024 |
If a session could be extended, and someone took over the session, the hijacked session could be kept alive indefinitely |
# |
Jul 25th 2017, 08:47 |
neon1024 |
At least then you can invalidate the cookie on the server side giving you more control |
# |
Jul 25th 2017, 08:47 |
neon1024 |
I’d probably just include a ‘remember me’ cookie or similar |
# |
Jul 25th 2017, 08:47 |
neon1024 |
I can’t think why you’d want to, it feels like a security risk to me |