Re: [PHP-DEV] On not rushing things at the last minute

[Peter Lind]

On 10 July 2018 at 15:26, Dustin Wheeler  wrote:

*snip*


> Personally (for Class Friendship), I opted to target either 7.4 or 8.0
> (whichever was decided to be next-in-line)
>

Seems to me this is one of the issues - that this is something that isn't
just set in stone. If there was an overall roadmap of major and minor
versions, along with set dates and deadlines that could not be moved, this
wouldn't be an issue.


>
> At the same time, I would hate to see a TON of additional process /
> voting constraints come as a response to this issue.
>
> That said, if feature freeze for a release is announced well in
> advance, published, and there was an agreed "best intentions" policy
> to not submit RFCs that encroach on that date, then I think all would
> be well. I don't think there's any intent to slide features in under
> the finish line. It just seems like a lot of ideas finished baking at
> a weird time. That, or subconsciously, the talk of a new version of
> PHP sparked folks to get off their ass and put forth their ideas! :P
>
>
>
I think a hard deadline would be a better solution. Past that date, it
simply doesn't matter what the RFC is about, it'll make the next version at
the earliest, not the current one. Movable feature freeze and release dates
do not benefit the language or its users, nor most of the core developers,
I'd say.

Just my take on it.

-- 
CV: https://stackoverflow.com/cv/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Mailing list moderation

[Peter Lind]

On 3 Jan 2018 18:13, "Chase Peeler"  wrote:

On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev  wrote:

> Hi,
>
> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler 
> wrote:
> >
> > I agree with Paul. It would be different if email clients that allowed
> > filtering were expensive or hard to find. They aren’t, though. Pretty
> much
> > every email client not only allows filtering, but rather advanced
> filtering
> > as well.
> >
> > Instead of suspending users, no matter how egregious their offenses may
> be,
> > let individual users filter them out as they see fit.
> >
>
> You have a point, but also have it in mind that we're talking about
> individuals participating in a discussion thread, and that's not the
> same as filtering out spam email or a news category that you're not
> interested in.
>
> Cheers,
> Andrey.
>

Are you saying you can't configure your client to delete/move to another
folder any emails with a subject beginning with [PHP-DEV] that are sent
from tonymars...@hotmail.com or li...@rhsoft.net?
--
-- Chase
chasepee...@gmail.com


Missing the point and going for personal attacks instead. You make the
point of the OP rather than your own.

Re: [PHP-DEV] Re: PHP's mail servers suck

[Peter Lind]

On 7 Nov 2017 16:40, "Eli White" <e...@eliw.com> wrote:

On Tue, Nov 7, 2017 at 9:07 AM, Peter Lind <peter.e.l...@gmail.com> wrote:

> Might be worth noting that fixing the mailing lists does not amount to
> taking on the php.net mail servers. The two are separate - just in case
> someone should be up for one, but not both tasks.
>

In this case I believe that they are one and the same Peter.   As the
issues with the mailing list(s), are actually issues with the mail server
itself.


You might be right, but as far as I can tell, the lists server handles
receiving and sending for lists.php.net without the use of PHP.net. The
only issue outside of lists.php.net would be DNS, but that's handled
externally - the rest is handled on the lists server, by some derelict
mailing list software. That's also what previous discussions on the topic
bring up.

Re: [PHP-DEV] Re: PHP's mail servers suck

[Peter Lind]

Might be worth noting that fixing the mailing lists does not amount to
taking on the php.net mail servers. The two are separate - just in case
someone should be up for one, but not both tasks.

On 7 November 2017 at 14:48, Eli White  wrote:

> Just chiming in that I have constantly had issues (since you asked for
> hands), get emails denied (let's see if this one goes through), and
> semi-constant threads of being auto-removed because of bounces that have
> nothing to do with me (see above gmail discussion).
>
> Yeah, it sucks.  And it's been brought up in the past.  And invariably it
> all falls back to "Oh, only one person really knew how to maintain that
> random mail server and they aren't active anymore, and now no-one really
> does, so it just keeps running and no-one wants to take the effort to try
> to update/fix/move it"
>
> Eli
>
> PS. Not it
>
>
> On Tue, Nov 7, 2017 at 8:38 AM, Sara Golemon  wrote:
>
> > Biweekly reminder that PHP mail servers suck.
> >
> > On Wed, Oct 25, 2017 at 10:30 AM, Sara Golemon  wrote:
> > > Quick show of hands: Who's had a "looks like spam" bounce from php.net
> > > mail servers in the past... lets say the past month.
> > > Or how about the fact that new users tend to have a very hard time
> > > even subscribing to this list?
> > > This isn't directed at any one person because AFAICT, the maintainer
> > > of those systems is "nobody".
> > > Is it time to pick someone to actually maintain that pile of mierde?
> > > Maybe replace the pieces that haven't worked since the 90s?
> > >
> > > Fed up with something this basic not working,
> > > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>



-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 13:15, Lester Caine <les...@lsces.co.uk> wrote:

> On 12/08/16 12:09, Peter Lind wrote:
> > And if all typos were switching 'e' and 'n', what a wonderful world it
> > would be. That is not the case though - it's possible to accidentally
> enter
> > " and > too.
> And the browser validation strips them and handles the ' when used in
> text fields.
>
>
No, it doesn't. It likely handles it on *most* browsers, but that still
doesn't mean you're safe - you don't know when someone suddenly decides to
try a new browser that doesn't behave the way you think it will.


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 13:01, Lester Caine <les...@lsces.co.uk> wrote:

> On 12/08/16 11:01, Peter Lind wrote:
> > On 12 August 2016 at 11:54, Rowan Collins <rowan.coll...@gmail.com>
> wrote:
> >
> >> On 12/08/2016 10:21, Lester Caine wrote:
> >>
> >>> Many of my systems run on secure intra-nets and much of the 'safety
> >>> concerns' that have been brought up recently as 'essential' simply
> don't
> >>> apply.
> >>
> >> There's always rogue employees / students / visitors with temporary
> >> access... But yes, IF you trust your users 100% to be non-malicious,
> >> non-curious, and uninfected, THEN you can trust your user input. :)
> >>
> > You forgot non-clumsy. Typos also happen and can have problematic
> results.
> >
> > You cannot trust user input. End of discussion.
>
> That someone puts in Joens rather than Jones is a fact of life, and will
> result in records that can't be matched. But a UK formatted date
> validated in the browser makes checking it's in a valid range easier in
> the PHP end. It's simply a matter of just what you can test and where,
> and if needs be the system keeps track of who is making mistakes in data
> entry and their supervisor deals with them. THAT is a report my CMS
> systems have had from day one :)


And if all typos were switching 'e' and 'n', what a wonderful world it
would be. That is not the case though - it's possible to accidentally enter
" and > too.



> But if they have stolen someone else’s
> access card then all bets are off. But there is no 'delete' function on
> the data so all changes are recorded.
>
>
 No, all bets are not off. That's the whole point of defense in depth.


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 12:52, Lester Caine <les...@lsces.co.uk> wrote:

> On 12/08/16 11:23, Peter Lind wrote:
> > On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote:
> >
> >> On 12/08/16 10:42, Peter Lind wrote:
> >>> On 12 August 2016 at 11:25, Lester Caine <les...@lsces.co.uk> wrote:
> >>>
> >>> Thanks for the ideas on this feature.
> >>>
> >>> A few thoughts.
> >>> 1. The RFC for this isn't a change - it's an addition. If it gets
> >> accepted
> >>> and implemented, you still would not have to change your code if you
> >> didn't
> >>> want to.
> >> I think that is the whole point ...
> >>
> > You're making different points, so maybe you should then be clearer.
>
> If you don't set a constraint or other 'intelligent' action then nothing
> changes?
>
>
This is missing the point entirely. The RFC was for a new feature, that you
don't have to use. Not for changing existing ones.



> >>> 2. There are differing ways of using the language. Yours is not better
> -
> >>> merely different. So I would think a relevant question is: can the RFC
> in
> >>> point support your style of coding along with that of others. A
> critical
> >>> point is throwing exceptions on invalid data, which might be hard to
> >> handle.
> >> Exceptions get generated hen something unhandled happens. Simple example
> >> 'divide by zero' only happens if the divisor is zero. If the variable
> >> used has a constraint of 'not zero' and has been validated then the
> >> exception will not be raised. My style would validate the divisor and
> >> only call the divide if it was going to work, others would allow the
> >> divide to fail and MAY actually handle the exception ;)
> >>
> > That doesn't address the point: if the feature should throw exceptions or
> > not, or allow for both styles.
>
> We already have a 'strict' mode which enables exceptions on some actions
> or leaves them as errors. I'm simply happy for both to co exist to keep
> others happy.
>
>
Good point.



> >>> 4. I think your suggestions might conflate validation and sanitation -
> >>> these are not the same and cannot be handled as one
> >> That people try to inject malicious input via variables is a different
> >> problem. Firebird database has always preferred parameter data so SQL
> >> injections just don't work, but other stuff does need clearing when
> >> input rather than simply relying on escaping unprocessed output. Again
> >> it's programming sytle?
> >>
> > No, it's not programming style. Conflating validation and
> > sanitation/escaping is wrong, because the contexts are different.
>
> The programming style 'point' is that many sites do simply slap
> htmlspecialchars() around all output and not worry that internally
> suspect data is floating around. On a couple of projects I've been using
> this was the sticking plaster while I prefer to ensure that the
> variables being passed were clean in the first place. In some situations
> sanitising the input may not be practical because of the workflow used
> but THAT is a matter of programming style?
>
>
But other programmers entirely foregoing validation is besides the point.
The point was that conflating validation with escaping/sanitizing is wrong
- and that still applies, even if your chosen method of validation is "I
don't".


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote:

> On 12/08/16 10:42, Peter Lind wrote:
> > On 12 August 2016 at 11:25, Lester Caine <les...@lsces.co.uk> wrote:
> >
> > Thanks for the ideas on this feature.
> >
> > A few thoughts.
> > 1. The RFC for this isn't a change - it's an addition. If it gets
> accepted
> > and implemented, you still would not have to change your code if you
> didn't
> > want to.
> I think that is the whole point ...
>
>
You're making different points, so maybe you should then be clearer.



> > 2. There are differing ways of using the language. Yours is not better -
> > merely different. So I would think a relevant question is: can the RFC in
> > point support your style of coding along with that of others. A critical
> > point is throwing exceptions on invalid data, which might be hard to
> handle.
> Exceptions get generated hen something unhandled happens. Simple example
> 'divide by zero' only happens if the divisor is zero. If the variable
> used has a constraint of 'not zero' and has been validated then the
> exception will not be raised. My style would validate the divisor and
> only call the divide if it was going to work, others would allow the
> divide to fail and MAY actually handle the exception ;)
>
>
That doesn't address the point: if the feature should throw exceptions or
not, or allow for both styles.



> > 4. I think your suggestions might conflate validation and sanitation -
> > these are not the same and cannot be handled as one
> That people try to inject malicious input via variables is a different
> problem. Firebird database has always preferred parameter data so SQL
> injections just don't work, but other stuff does need clearing when
> input rather than simply relying on escaping unprocessed output. Again
> it's programming sytle?
>
>
No, it's not programming style. Conflating validation and
sanitation/escaping is wrong, because the contexts are different.



> > That said, I generally think that built-in methods that accept Callables
> > are a great way to go. It encourages reuse through modular composition -
> > and could likely be a neater way around the throw exception/return error
> > code issue. It's obviously doable from userland, but could probably be
> > improved if implemented in the language.
>
> It was the fact that Yasuo was adding these rules into his array
> validation stuff that just grates so badly with what is actually needed ...
>
>
>
Yasuo was presumably scratching an itch that he (and possibly others) feel.
As such, it is in fact "what is actually needed". It just doesn't happen to
be what *you* actually need, but that doesn't mean it won't fit perfectly
for many others.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 11:54, Rowan Collins  wrote:

> On 12/08/2016 10:21, Lester Caine wrote:
>
>> Many of my systems run on secure intra-nets and much of the 'safety
>> concerns' that have been brought up recently as 'essential' simply don't
>> apply.
>>
>
> There's always rogue employees / students / visitors with temporary
> access... But yes, IF you trust your users 100% to be non-malicious,
> non-curious, and uninfected, THEN you can trust your user input. :)
>
>
You forgot non-clumsy. Typos also happen and can have problematic results.

You cannot trust user input. End of discussion.


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Simple variable handling.

[Peter Lind]

On 12 August 2016 at 11:25, Lester Caine  wrote:

> On 12/08/16 10:07, Christoph M. Becker wrote:
> >> > I'm thinking
> >> > $var->setConstraint()
> >> > $var->setEscape()
> >> > $var->setReadOnly()
> >> >
> >> > Rather than having to build 'reflections' classes to pull out data
> that
> >> > a simple $var->is_valid or echo $var will output a correctly escaped
> >> > piece of text.
> > Actually, this is already possible; just use objects.  E.g.
> >
> >   class Container {
> > function __construct() {}
> > function setConstraint() {}
> > function setEscape() {}
> > function setReadOnly() {}
> > function isValid() {}
> > function __toString() {}
> >   }
> >   $var = new Container($some_value);
>
> This has been the problem all along. There is no overriding reason to
> change what we already have, but ALL of the improvements currently being
> discussed MAY be better handled with a return to the basic model of a
> variable. If a variable is 'readonly' there is no need to worry about
> each variable.
>
>
Thanks for the ideas on this feature.

A few thoughts.
1. The RFC for this isn't a change - it's an addition. If it gets accepted
and implemented, you still would not have to change your code if you didn't
want to.
2. There are differing ways of using the language. Yours is not better -
merely different. So I would think a relevant question is: can the RFC in
point support your style of coding along with that of others. A critical
point is throwing exceptions on invalid data, which might be hard to handle.
3. Your assumption of secure intra-nets is questionable. Defense in depth
is what one should strive for.
4. I think your suggestions might conflate validation and sanitation -
these are not the same and cannot be handled as one

That said, I generally think that built-in methods that accept Callables
are a great way to go. It encourages reuse through modular composition -
and could likely be a neater way around the throw exception/return error
code issue. It's obviously doable from userland, but could probably be
improved if implemented in the language.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Function auto-loading

[Peter Lind]

On 10 Aug 2016 19:05, "Bishop Bettini" <bis...@php.net> wrote:
>
> On Wed, Aug 10, 2016 at 5:37 AM, Peter Lind <peter.e.l...@gmail.com>
wrote:
>>
>> On 10 August 2016 at 10:51, Lester Caine <les...@lsces.co.uk> wrote:
>>
>> > On 09/08/16 06:54, Sara Golemon wrote:
>> > > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine <les...@lsces.co.uk>
wrote:
>> > >> So Composer IS now the rule rather than some optional extra?
>> > >>
>> > > Yes, the community has decided that for us.  Or at least, Composer is
>> > > a *significant* player in the ecosystem of PHP development.
>> > > require_once() might be fine for NiH applications, but for the
>> > > collaborative world of modern PHP, it's the defacto standard.
>> >
>> > Much as PSR also does.
>> > This is probably fine if one is starting a project from scratch, but
>> > with now 15+ years worth of code that does not follow this 'modern
>> > style' it's another barrier to moving code forward. There is nothing
>> > wrong with the code other than newer users done approve of the style of
>> > working :(
>> >
>> >
>> EVERYTHING is a barrier to moving your code forward. You tell the mailing
>> this on a regular basis.
>> Perhaps you should just migrate your 15+ year old code already and be
done
>> with it?
>>
>> Either that or fork PHP and never upgrade again. If you're this unhappy
>> with any/all changes to PHP, that seems a viable option.
>
>
> Please, let's keep the list clean of ad hominem reactions. Lester has a
valid opinion, based on what seems to be a successful legacy of working
code. That kind of code is essential PHP, and I, for one, value his
perspective and welcome his feedback. If we break his code, or establish
barriers to his code modernization efforts, we're probably doing the same
to a whole class of users whom we might not hear from otherwise.

That was not an ad hominem attack. It was a description of the emails
Lester send to the list.

"Update your code or fork PHP" is not a particularly constructive comment.
Neither, of course, is "don't make changes to my programming language of
choice". Especially given that the feature discussed here would not
actually directly influence Lester - he does not have to use it. In
essence, Lester was arguing against this feature because others in the
community would use it, and that would be a problem for him.

>From what i can tell, Lester has an infrastructure problem. Not a PHP
problem. But he still wants to halt language development so the community
doesn't pick up new features that might make problems in his code. That
does not seem reasonable to me.

Re: [PHP-DEV] Function auto-loading

[Peter Lind]

On 10 August 2016 at 10:51, Lester Caine  wrote:

> On 09/08/16 06:54, Sara Golemon wrote:
> > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine  wrote:
> >> So Composer IS now the rule rather than some optional extra?
> >>
> > Yes, the community has decided that for us.  Or at least, Composer is
> > a *significant* player in the ecosystem of PHP development.
> > require_once() might be fine for NiH applications, but for the
> > collaborative world of modern PHP, it's the defacto standard.
>
> Much as PSR also does.
> This is probably fine if one is starting a project from scratch, but
> with now 15+ years worth of code that does not follow this 'modern
> style' it's another barrier to moving code forward. There is nothing
> wrong with the code other than newer users done approve of the style of
> working :(
>
>
EVERYTHING is a barrier to moving your code forward. You tell the mailing
this on a regular basis.
Perhaps you should just migrate your 15+ year old code already and be done
with it?

Either that or fork PHP and never upgrade again. If you're this unhappy
with any/all changes to PHP, that seems a viable option.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] New RFC

[Peter Lind]

On 2 August 2016 at 09:11, Dan Ackroyd  wrote:

> Hi Tomáš,
>
> It has been thought about, and several people are looking at an
> implementation of generics: https://wiki.php.net/rfc/generics However,
> it seems quite hard to implement.
>
> I am beginning to wonder if rather than aiming for full support of
> generics listed in that RFC, instead we just aimed for arrays that can
> only contain one type of variable as a good first step.
>
> cheers
> Dan
>
>
It's probably worth noting that creating "arrays" that can only contain one
type of variable is already possible by implementing ArrayAccess, Iterator
and Countable.

It won't work exactly like arrays and probably never will (see
https://www.mail-archive.com/internals%40lists.php.net/msg59199.html) but
might be worth as a starting point.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] Pipe Operator

[Peter Lind]

On 9 May 2016 at 08:45, Stanislav Malyshev  wrote:

> Hi!
>
> > I have the feeling that if everyone involved *explicitly* prefixed their
> > opinions with "I think that", this would be a better and more fruitful
>
> Is there any other option?
>

As in "better options"? I don't think so. As in "could my statement be
taken any other way"? Clearly, as the way you put it forward you were
claiming not that you though things unobvious, but that they were
unobvious. You are trying to make the exact same argument, in different
words, in your argument below.


>
> > discussion. *You* think the syntax completely unobvious - that doesn't
> > make it so. Clearly others find it much easier to read.
>
> If you think it's obvious - it also doesn't make it so, then.


That is a logical conclusion, yes. I didn't state my opinion on the pipe
operator, though.



> It appears
> we have no way to determine if it's obvious or not. But I'd like to
> venture a proposal - find somebody who is not familiar with this
> proposal and maybe even with PHP and ask them - what do you think * or +
> or -> may mean in PHP? If they are familiar with any other languages
> like PHP, they would venture a guess with would be pretty close to the
> truth. Now ask them what |> and $$ may mean. Are you ready to tell me
> their answers would be as accurate and close to the truth as before?
>

Are you willing to argue that PHP should never implement features not found
commonly in other languages? Because that's where you're going with that
argument.

Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] Pipe Operator

[Peter Lind]

On 9 May 2016 at 07:37, Stanislav Malyshev  wrote:

> Hi!
>
> > "|>" is just a building block for simpler coding. It could be used
> badly, but
> > it helps a lot. Procedural code could be much simpler and readable with
> "|>".
>
> I don't see how it helps anything. It just replaces clear variable names
> with cryptic sequences of characters with no intuitive meaning and magic
> semantics invented solely to save a few keystrokes. Moreover, it would
> only in one sole use case where functions always return a value that is
> immediately passed to the next one and is sole argument for it, and
> never produce errors or require any logic beyond calling them in a
> sequence on one value.
>
>
That seems to be a misrepresentation of the proposal - the $$ is needed
*because* there might be other parameters. As for sole use case - there are
many pieces of code that manipulate the return values of functions, step by
step.



> > "|>" version is much easier to read and write.
>
> Quite the opposite. It has completely unobvious syntax (what is $$? What
> is the value of $$? how I see this value if I need to debug this code?)
> and does not allow to do anything but making code more cryptic.
>

I have the feeling that if everyone involved *explicitly* prefixed their
opinions with "I think that", this would be a better and more fruitful
discussion. *You* think the syntax completely unobvious - that doesn't make
it so. Clearly others find it much easier to read.

Regards
Peter



-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] Pipe Operator

[Peter Lind]

On 30 Apr 2016 16:43, "Lester Caine"  wrote:
>
> On 30/04/16 14:57, Marco Pivetta wrote:
> > Relevant: https://youtu.be/UvD1VjRvGIk
>
> Trimming the now useless error code 
>
> As I said in the message ... no problem if you simply have a SINGLE
> pathway through the code. That video simply assumes that anything that
> is not success is an error. MUCH of my code base has turntables or three
> way switches which in addition to possible errors, you have a lot more
> than one 'success' output.
>
> The pipe operator does not provide a work flow as demonstrated in that
> video ...

So in essence, any feature that doesn't fit your codebase is wrong. About
tight?

> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: Improving PHP's type system

[Peter Lind]

On 14 April 2016 at 01:43, Zeev Suraski  wrote:

>
> > On 14 באפר׳ 2016, at 7:14, Larry Garfield 
> wrote:
> >
> >> On 4/13/16 3:24 PM, Stanislav Malyshev wrote:
> >> Hi!
> >>
> >>> May I suggest you the following article (more of a starting point into
> >>> Ceylon actually) regarding this topic:
> >> There was a time where PHP was considered a good beginner's language.
> >> Now it seems we want to pivot and target category theory PhDs instead?
> :)
> >
> > A language that is usable primarily by beginners will only be useful for
> beginners.  Non-beginners will shun it, or simply grow out of it and leave.
> >
> > A language that is usable only by PhDs will be useful only for PhDs.
> Beginners won't be able to comprehend it.
> >
> > A language that is usable by both beginners and PhDs, and can scale a
> user from beginner to PhD within the same language, will be used by both.
> >
> > Doing that is really hard. And really awesome. And the direction PHP has
> been trending in recent years is in that direction.  Which is pretty danged
> awesome. :-)
>
> I would argue that PHP was already doing that almost since inception.  I
> think we have ample evidence that we've been seeing a lot of different
> types of usage - both beginners' and ultra advanced going on in PHP for
> decades.
> I would also argue that in recent years, the trending direction has been
> focusing on the "PhDs", while neglecting the simplicity seekers (which I
> wouldn't necessarily call beginners).  Making PHP more and more about being
> like yet-another-language, as opposed to one that tries to come up with
> creative, simplified ways of solving problems.
> Last, I'd argue that a language that tries to be everything for everybody
> ends up being the "everything's and the kitchen sink", rather than
> somethings that is truly suitable for everyone.
>
> We also seemed to have dumped some of our fundamental working assumptions
> - that have made PHP extremely successful to begin with:
>
> - Emphasis on simplicity
> - Adding optional features makes the language more complex regardless of
> whether everyone uses them or not
>
>
Really? The recent number of RFCs focusing on making some of PHPs
annoyances go away have passed you by? They seem to fall squarely within
"emphasis on simplicity" as far as I can tell.

Also, PHP is known as the language with a million ways to do things, where
some functions even have aliases because reasons. It's been that way since
a very long time. That suggests to me that complexity/optional features are
not frowned upon - only some types of complexity are seen as bad, and only
some types of simplicity are apparent worthwhile. Spelling out personal
preferences here would probably help solve these discussions faster.



> It does seem as if we're trying to replicate other languages, relentlessly
> trying to "fix" PHP, which has been and still is one of the most successful
> languages out there - typically a lot more so than the languages we're
> trying to replicate.
>
>
Regards
Peter


-- 
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Handling of withdrawn RFCs

[Peter Lind]

On 21 January 2016 at 21:53, Ronald Chmara  wrote:

> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana 
> wrote:
> > An RFC could still be valuable for the project, even if the original
> > author leaved, so taking it over should be possible. And it should not
> > be painful in any way.
> > Would we need some rules in case multiple people want to take it over,
> > or should we say the first one wins?
> > Is there any way to abuse the taking over of an withdrawn RFC?
>
> Hypothetically:
>
> An RFC being used primarily for ongoing debate/argument/trolling
> purposes could live indefinitely, generating hundreds, or thousands,
> of messages, and changesets/PR's, and list churn, in the name of
> "making sure an issue is adequately discussed and resolved".
>
> Even as individual trolls, marks, and sockpuppets were knocked down,
> new ones could pick up the mantle of "but we're discussing important
> things, here!", and continue the loop, only finally exhausting the
> suite of RFC mechanisms all of the trolls/marks/puppets finally gave
> up, or were someho0w being administratively prohibited from all future
> participation.
>
> Which, if the PHP email lists were an endless trolling/argument/debate
> forum like twitter or reddit, would be completely appropriate.
>
> This is all hypothetical, of course.
>
>
This thread being about withdrawn/re-proposed RFCs, how is that comment
relevant? Seeing as anyone wanting to debate/argument/troll indefinitely
can do so using their own RFC - or, for that matter, without an RFC.

Regards
Peter


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Handling of withdrawn RFCs

[Peter Lind]

On 21 January 2016 at 22:24, Ronald Chmara <rona...@gmail.com> wrote:

> On Thu, Jan 21, 2016 at 12:59 PM, Peter Lind <peter.e.l...@gmail.com>
> wrote:
> > On 21 January 2016 at 21:53, Ronald Chmara <rona...@gmail.com> wrote:
> >> On Thu, Jan 21, 2016 at 12:33 PM, Flyingmana <flyingm...@googlemail.com
> >
> >> wrote:
> >> > Is there any way to abuse the taking over of an withdrawn RFC?
> Snip_>
> >> An RFC being used primarily for ongoing debate/argument/trolling
> >> purposes could live indefinitely, generating hundreds, or thousands,
> >> of messages, and changesets/PR's, and list churn, in the name of
> >> "making sure an issue is adequately discussed and resolved".
> >> Even as individual trolls, marks, and sockpuppets were knocked down,
> >> new ones could pick up the mantle of "but we're discussing important
> >> things, here!", and continue the loop...
> Snip_>
> > This thread being about withdrawn/re-proposed RFCs, how is that comment
> > relevant?
>
> The relevance is in ways to "abuse the taking over of an withdrawn RFC".
>
>
Ahhh good point, missed that.



> > Seeing as anyone wanting to debate/argument/troll indefinitely can
> > do so using their own RFC -
>
> Creating a new RFC has a higher barrier to entry, requiring additional
> effort.
>
>
If your aim is to clutter the mailing list indefinitely, that's really not
going to get in your way.



> > or, for that matter, without an RFC.
>
> I would suggest that random email trolling does not have the same
> audience, impact, or formal trappings of a public RFC process.
>
>
Random email trolling, no. But then again, random email trolling is not
really what we're talking about, is it?
Plus, it's a mailing list, not a forum. The default is that you follow
every thread, and have to actively mute them. Email trolling by splitting
off of threads would actually be more effective than keeping to one RFC
thread - not less effective.

Regards
Peter


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

[Peter Lind]

On 13 January 2016 at 16:49, Adam Howard  wrote:

> Alright, you want a straight up answer, I'll provide you one.  Here is
> my constructive criticism.  I'd like to be able to opt-out of this
> conversation and not further have it flood my inbox and be able to actually
> get back to what matters and what I and most everyone else signed up for
> (PHP Development, Code).
>

1. You're top-posting
2. You're posting from a gmail address. Gmail has mute function. Use it

Regards


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 7 Jan 2016 20:59, "Chase Peeler"  wrote:
>
> On Thu, Jan 7, 2016 at 2:51 PM, Pierre Joye  wrote:
>
> > On Jan 8, 2016 2:44 AM, "Paul M. Jones"  wrote:
> > >
> > >
> > > > On Jan 7, 2016, at 13:39, Pierre Joye  wrote:
> > > >
> > > >
> > > > On Jan 8, 2016 2:27 AM, "Paul M. Jones"  wrote:
> > > > >
> > > > >
> > > > > > On Jan 7, 2016, at 13:25, Pierre Joye 
> > wrote:
> > > > > >
> > > > > >
> > > > > > On Jan 8, 2016 2:21 AM, "Paul M. Jones" 
> > wrote:
> > > > > > >
> > > > > > >
> > > > > > > > On Jan 7, 2016, at 13:15, Pierre Joye 
> > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >> On Jan 8, 2016 1:58 AM, "Paul M. Jones" <
pmjone...@gmail.com>
> > wrote:
> > > > > > > >>
> > > > > > > >> I notice you did not answer my question. I'll ask again:
when
> > you say "proven guilty" what exactly do you mean?
> > > > > > > >
> > > > > > > > I see you are going to nitpick here. So let clarify it.
> > > > > > >
> > > > > > > When we're talking about banning people as a result of their
> > actions, we'd better be clear on the details, don't you think?
> > > > > > >
> > > > > > >
> > > > > > > > If there is a clear set of evidences that someone harassed,
> > insulted, attacked another person then it fits this definition.
> > > > > > >
> > > > > > > What to you would be "a clear set of evidences"?  (If you have
> > examples of actual occurrences, that would be better than building
> > hypotheticals, and probably easier.)
> > > > > > >
> > > > > > >
> > > > > > > > Please keep in mind than harassment, attacks or insults have
> > nothing to do with opinions.
> > > > > > >
> > > > > > > Unfortunately, too many people confuse "argument" with
> > "harassment", and "disagreement" with "attacks", and "observations" as
> > "insults."  So I'd like to hear first what "clear evidence" means to
you.
> > > > > >
> > > > > > This is what I mean by nitpicking. I am sure you perfectly
> > understand my point as well as what I would consider as bad. Just in
case,
> > an opiniated hot discussion is not. I would appreciate a clear answer as
> > well from your side and little less nitpicking.
> > > > >
> > > > > To give clear answers, I need clear statements. For example, if a
> > person *claims* harassment, what to you would be *evidence* of that
> > harassment?  This is not nitpicking; this is defining the terms of the
> > conversation. If you are unable to clarify, that's cool, just say so.
> > > >
> > > > I think you are playing.
> > >
> > > I have never been more serious. This RFC, if passed, is going to have
> > wide-ranging consequences, and if the terms in it are so vague as to
give
> > open-ended powers to those charged with enforcing it, I think that's a
> > dangerous thing.
> > >
> > > So again: What to you would be "a clear set of evidences"?  (If you
have
> > examples of actual occurrences, that would be better than building
> > hypotheticals, and probably easier.)
> > >
> > > And again, if you are unable to clarify this, I'm OK with that. I get
> > that it's messy.
> >
> > It is not. To me to distinguish harassment vs hot discussions (public or
> > private) is part of common sense and I trust us to have this common
sense
> > when this group will be created.
> >
> > Also the very definition of harassment is pretty clear. Read
> > http://legal-dictionary.thefreedictionary.com/harassment for the
> > reference.
> > If it is not clear for you then yes, I cannot make it clearer. Sorry.
> >
> > I do not think we need to build up our own definition because some
thinks
> > we will abuse powers.
> >
>
> " the act of systematic and/or continued unwanted and annoying actions of
> one party or a group, including threats and demands."
>
> Nothing in the definition beyond that is exclusionary. It includes various
> examples, but does not limit it beyond that. To me, "unwanted or annoying
> actions" probably describes how a lot of people feel about Paul's comments
> (I'm not one of them). Does that make him guilty of harassment?
>

Paul has switched to constructively participating in the discussion. He is
also not singling out any group or person for unwanted or annoying actions.
So no, he is not guilty of harassment.

Was that answer you were looking for?

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 6 January 2016 at 21:43, François Laupretre  wrote:

> Le 06/01/2016 20:38, Ryan Pallas a écrit :
>
>>
>> I agree, a conflict resolution document *and team* seems infinitely
>> better.
>> This team's job is to resolve things quietly and without further incident,
>> however if action may be required - its an open vote (as previously
>> suggested).
>>
>
> Agreed. 'Don't be evil' is sufficient as a CoC. Anything we add to this
> will be redundant, ambiguous, and subject to interpretations.
>
>
If you had but an inkling of the irony in that sentence ...


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 16:59, Stanislav Malyshev  wrote:

> Hi!
>
> > How exactly would you feel about having all of this made explicit to all
> > the other PHP devs? Presumably you look up to some of these people -
>
> I presume you would feel bad. However your example is purely theoretical
> and hand-crafted to exactly fit your argument.


Yes, I thought it up, hence it's theoretical. If you think that means it
hasn't happened countless times along those lines, you need to learn how to
google.



> It is easy to imagine
> theoretical example that found fit practically any argument - including
> one that nobody should have any due process at all, since proving any
> allegations just hurts the victim again (and you can imagine
> unbelievably hurtful circumstances for your theoretical case, since the
> only limit is your imagination), so any allegation should be considered
> true by mere fact of alleging.


Is there any particular reason you feel the need for arguing strawmen? At
which point has *anyone* argued for against due process? If you cannot
point to any such point, would you mind not assuming them?



> I hope that would be going too far for you?
>

See above.


> In practice, there's rarely an allegation that can not be published to
> the measure that makes it clear what happened.


Unless you've been through abuse and harassment along the lines of
http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
I would suggest you stop assuming what it is like.



> That does not mean
> "verbatim" - in some cases, like publishing private information,
> reproducing it verbatim as a proof would be obviously counterproductive,
> but there are also obvious way to describe it without reproducing
> verbatim, such as "publishing private information".
>
>
See above.



> > If you happen to belong to a minority group that often is at the
> > receiving end of abuse, what would you think if this was the message
> > being sent? Would you expect to be understood by your peers, or would
>
> I think the message that is being sent is that everybody will be treated
> equally and fairly. If somebody has done something bad, it would be
> known and the solution would be found, if nothing bad happened, people
> can be reasonably assured that they are safe from false accusations.
> That applies to majorities, minorities, mediocrities and any other
> groups, however one would like to label oneself that particular day.
>

And you would be wrong - that is not the message being sent.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

>
> +1. The proposed CoC is too vague for a multi-cultural environment like
> ours. Reference to ethics, for example, is subjective by nature. But I'm OK
> for a more precise text that everybody must explicitely approve before
> getting any karma.
>
> But I am opposed to any form of law enforcement board. I understand it
> ensures privacy but my feeling is that we don't need privacy here, and we
> never needed such a mechanism during 20 years. Most questionable messages
> are published on the mailing list. If someone receives an offending private
> mail or is victim of harassment in any other way, he can just publish it on
> the list and everyone will judge if it is offending or not. Then, if we
> need to consider banning someone, anybody can create a specific RFC for
> this, but it is an extreme case that, fortunately, has a very low
> probability..
>

A quick question: suppose you're from a minority group, and you've been the
target of abuse previously your life. You now join the PHP community and
for whatever reason, someone takes a dislike to you and starts harassing
you in private. The abuse makes use of the same stuff you've been through
before, and because this is a real douchebag, some very humiliating things
are thrown in for good measure.

How exactly would you feel about having all of this made explicit to all
the other PHP devs? Presumably you look up to some of these people - would
your first thought be "Oh I know! I'll post all this nasty stuff to a
public mailing list, that is archived on the web where EVERYONE can see all
the humiliation coming my way - and where google is sure to pick up all
these things about me!"?

If you happen to belong to a minority group that often is at the receiving
end of abuse, what would you think if this was the message being sent?
Would you expect to be understood by your peers, or would their concern
about being possibly accused of something seem like an out-of-hand
rejection?

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 19:53, Stanislav Malyshev  wrote:

> Hi!
>
> > Yes, I thought it up, hence it's theoretical. If you think that means it
> > hasn't happened countless times along those lines, you need to learn how
> > to google.
>
> I hope you realize how weak is an argument along the lines of "I am
> right, if you don't see it, learn how to google".
>
>
I'm sorry. I, wrongly, assumed that it was common knowledge by now how
toxic the tech environment and culture can be, and how many people have
been abused and harassed, both online and offline.



> > Is there any particular reason you feel the need for arguing strawmen?
> > At which point has *anyone* argued for against due process? If you
> > cannot point to any such point, would you mind not assuming them?
> >
> >
> >
> > I hope that would be going too far for you?
> >
> >
> > See above.
>
> As you see, I have assumed exactly the opposite: that you are *not*
> against due process. That's what "going too far" means. You are merely
> using an argument that proves too much
> (https://en.wikipedia.org/wiki/Proving_too_much) - following that
> argument, we could conclude that due process is bad. Which is an absurd
> conclusion - that's how reductio ad absurdum works.
>
>
You argued against a strawman. I pointed that out. One of us was misreading
something, and seeing as you put the argument with no due process
whatsoever forward, I thought it was you. My mistake.



> > Unless you've been through abuse and harassment along the lines
> > of
> http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
> > I would suggest you stop assuming what it is like.
>
> I can not stop it since I never started. But what is like, however bad
> it is, is not an argument for what we are discussing, since we do not
> argue what happened there is good. We argue whether adopting the RFC is
> a good way to prevent something like that from happening or reduce its
> incidence. Saying "introducing safe mode is not a good way to improve
> security" is not the same as saying "we need no security" :)
>
>
It seems to me you did in fact assume that things could be handled
transparently on the mailing list - as that was the proposed solution you
put forward. I then pointed to a specific case that I doubt most people
would be happy about making public.

And yes, we're discussing how to best handle things. My specific point was
that requiring people to post to the mailing list if they have any
grievances is not a good idea. Doesnt mean that the watchmen shouldn't be
watched.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 20:26, Stanislav Malyshev  wrote:

> Hi!
>
> > That is the problem: you cannot discuss how to protect the accused
> > without having the context of the abused. As you have yourself pointed
> > out with examples, it is a tradeoff.
>
> But that is exactly what I want - to have full(er) context! The secret
> procedure makes that harder. Of course, there are tradeoffs and some
> details must be withheld - but the first version of RFC (did not read
> the new one yet) was "maximum confidentiality", and that's not good IMO.
> I think the default should be "maximum disclosure, unless it's obviously
> damaging (personal data, etc.) or no-content (insults, slurs, etc.)".
> I.e. I recognize there's no absolute, I just want the balance be different.
>
>
That makes very good sense. I think the process could be optimized, but I
think aiming for maximum disclosure is as problematic as maximum
confidentiality - it ignores the perspective of one party.



> > That is a truism: doing more damage is not fixing anything. However,
> > unless I am mistaken, you yourself put forward the lack of explicit
> > problems as an argument in favour of not doing anything.
>
> Right. So that's one point of discussion - should we do anything at all
> or not. But if we *are* doing something - that's the second point of
> discussion - namely, institute new structure with broad powers in the
> community - we should do it in a way that is least likely to cause damage.
>
>
I wholeheartedly agree.


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 19:42, Stanislav Malyshev  wrote:

> Hi!
>
> > It's interesting to note how few people in this thread consider the
> > perspective of potential harassed or abused people - instead only
> > focusing on how to protect the accused.
>
> We do not discuss it much because it is a) covered in the RFC thus
> forming context of the discussion and b) most of it is non-controversial
> - we know hurting people is bad, we should not do it, and we should not
> accept such behavior in our community. It is *how* we achieve that which
> is the question for discussion.
>
>
That is the problem: you cannot discuss how to protect the accused without
having the context of the abused. As you have yourself pointed out with
examples, it is a tradeoff.



> > Quick check: how many times in the history of PHP has someone been
> > called out, wrongly, for being abusive or harassing others? If, as seems
>
> There was some amount of "meta" discussions, in which all kinds of
> complaints and counter-complaints were voiced, many times. But since we
> have no formal mechanism for "accusing" or for determining "wrong", we
> can't really know how many of such cases there were.
>
> > to the argument ("we're such a great and tolerant community, we don't
> > need this"), this hasn't happened - what's with the paranoia behind
> > assuming it will suddenly happen constantly and that people will be
> > banned left and right for no reason?
>
> Because unfortunately we have witnessed, in other communities, how
> applying such things too hastily and without due consideration can cause
> damage. While abuse is undeniably damaging, doing more damage, this time
> by ourselves, is not the right way to fix it.
>
>
That is a truism: doing more damage is not fixing anything. However, unless
I am mistaken, you yourself put forward the lack of explicit problems as an
argument in favour of not doing anything.

A middle way could be - like we're doing now - discuss options that amount
to more than doing nothing (status quo) and less than voting in the worst
possible option.



> > voting is allowed. Even in the most clearcut case where someone is being
> > a complete asshole, you're then either allowing them to continue the
> > harassment or ignoring your own point. It's hard to see how either
> > option benefits PHP, let alone the abused person.
>
> In most clearcut case where somebody is obviously misbehaving, we have
> plenty of people that can revert commits or remove people from ML. That
> happened in the past. We do not need a special troika for that.
>

 Ah, I mistook the idea of using the RFC to handle problems with conduct to
be a general way to deal with things.

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Peter Lind]

On 5 January 2016 at 05:49, Paul M. Jones  wrote:

>
> > On Jan 4, 2016, at 22:42, Sara Golemon  wrote:
> >
> > Formalized rules and due process are terrible for a free and open
> society?
>
> This proposal is neither formalized, nor due process.  You're great at C,
> Sara, but you're horrible at law.
>
> OMG WAS THAT OFFENSIVE?  BAN BAN BAN!
>
>

Troll much?


-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Peter Lind]

On 4 September 2015 at 09:43, Pavel Kouřil <pajou...@gmail.com> wrote:

> On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.l...@gmail.com> wrote:
> > On 4 September 2015 at 08:44, Pavel Kouřil <pajou...@gmail.com> wrote:
> >
> > You're arguing that, subjectively, to you - parentheses make things
> harder
> > to read. For others they clarify things.
> > It should be obvious to everyone that this particular path of the
> discussion
> > has about as much merit as tabs vs spaces.
>
> Sure, it is subjective - but what isn't?
>
>
Consistency isn't.



> > That being the case, I would argue for consistency and simplicity. If you
> > need parentheses for other variants of this, require parentheses all the
> way
> > through. It will be simpler to learn and trip fewer people up.
>
> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.
>
> Sure, parenthesis can help people understand things, but I'd say that
> at the same time, too many of them can be a problem as well (as the
> fun name for LISP - "lost in stupid parenthesis" - suggests).
>
>
Is it? And are the examples you make use of the only two options?
What about requiring parentheses around arguments, but not around the
function body? That would guard against stupid "I'll add another argument
... why isn't it working?!?!?!" errors (getting a syntax error and then
having to fix your code isn't easier than just consistently adding
parentheses around arguments).


> > Just think, if whoever constructed the if conditional hadnt thought "hey,
> > let's be clever and save some keystrokes by making the curlies optional
> in
> > some cases" we wouldn't have the multitude of bugs and security holes we
> > know to exist, we wouldn't have to warn the young'uns against improper
> use
> > of if, we wouldn't have to write codesniffer rules against single line
> ifs,
> > etc, etc.
> >
> > Any argument to the effect of "let's be clever" or "it'll save some
> > keystrokes" is void. Period.
>
> This is not about saving characters, it's about not overcomplicating
> things.
>

You're aiming for the "let's be clever" camp, far as I can tell.




-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Peter Lind]

On 4 September 2015 at 08:44, Pavel Kouřil  wrote:

*snip*


> But even just #3 seems kinda "harder" to read than the form without
> any parenthesis.
>
> function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }
>
> I know the parenthesis are optional in just one scenario, but I'd
> argue it's probably the most common one.
>

You're arguing that, subjectively, to you - parentheses make things harder
to read. For others they clarify things.
It should be obvious to everyone that this particular path of the
discussion has about as much merit as tabs vs spaces.

That being the case, I would argue for consistency and simplicity. If you
need parentheses for other variants of this, require parentheses all the
way through. It will be simpler to learn and trip fewer people up.

Just think, if whoever constructed the if conditional hadnt thought "hey,
let's be clever and save some keystrokes by making the curlies optional in
some cases" we wouldn't have the multitude of bugs and security holes we
know to exist, we wouldn't have to warn the young'uns against improper use
of if, we wouldn't have to write codesniffer rules against single line ifs,
etc, etc.

Any argument to the effect of "let's be clever" or "it'll save some
keystrokes" is void. Period.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Peter Lind]

On 4 August 2015 at 10:13, Lauri Kenttä lauri.ken...@gmail.com wrote:

 On 2015-08-03 23:54, Scott Arciszewski wrote:

 $AES = new \PCO\Symmetric('openssl:cipher=AES-128');


 It would be great if you could just ask for cipher=AES-128 without
 explicitly specifying the provider (openssl).


Even better would be splitting arguments up. There's not much point to
multi-valued arguments, they're just harder to parse/memorize.
If you need a common constructor, use a configuration object instead of a
made-up string format.

Apart from that, thumbs up on this!


-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] PHP 7.1 Cryptography Projects

[Peter Lind]

On 4 August 2015 at 13:56, Scott Arciszewski sc...@paragonie.com wrote:


 Hi Peter,

 It's not really a made-up string format, in the sense that it has a
 precedent (PDO).


True, and that format sucks royally. It trips people up.

Combining several arguments into one string is bad design. If it was good
design, you'd see userland code using it all over the place.



 Hopefully my response to Lauri makes this design decision seem more
 reasonable.


No, quite the opposite.

You're arguing that this:

new \Namespace\Class(:cipher=AES-256;mode=GCM);

is easier to work with than:

new \Namespace\Class(null, 'AES-256', 'GCM');

Or possibly

$config = new \Namespace\ConfigClass();
$config-setCipher('AES-256')
 -setMode('GCM');

$crypto = new \Namespace\Class($config);


Your parameter layout may be easier for you to deal with, but all the
people you're trying to help with this will be worse off for it.
PDOs constructor has only lead to more debugging, not better code (unlike
the rest of PDO).

Regards
Peter

Re: [PHP-DEV] DateInterval bug

[Peter Lind]

On 13 April 2015 at 22:20, Derick Rethans der...@php.net wrote:

 On Sun, 12 Apr 2015, Peter Lind wrote:

  Hi,
 
  I wanted to get into PHP code development so I grabbed a random bug from
  bugs.php.net. Which turned out to be
 https://bugs.php.net/bug.php?id=69378
 
  The problem the bug report describes is that creating a diff between two
  dates and then subtracting the diff from the later date does not give you
  the former date. Or, as the bug report state, this should hold:
 
  B - (B - A) == A
 
  But it doesn't, because of the way DateInterval and DateTime interact. A
  DateInterval is broken up into years, months, days, hours, minutes and
  seconds - which can be added or subtracted from a date. However, months
 are
  not fit size, so the order in which things are added or subtracted
 matters.
  In the bug report, the problem arises because months are subtracted
 before
  days - and there's a huge difference between subtracting 17 days from 2.
  April and from 2. March.
 
  In itself, this isn't a big problem - but apparently this behaviour is
 how
  the system is supposed to work. In the tests for the date extension, I
  found this test for DateTime::add
 
  echo test_years_positive__6_shy_1_day: ;
  examine_diff('2007-02-06', '2000-02-07', 'P+6Y11M30DT0H0M0S', 2556);
 
  echo test_years_negative__6_shy_1_day: ;
  examine_diff('2000-02-07', '2007-02-06', 'P-6Y11M28DT0H0M0S', 2556);
 
  The third argument in the examine_diff calls is used in the constructor
  call to DateInterval. The difference is whether the interval will be
  positive or negative. Note the difference of two days - if you add a
  positive interval, then 7 years minus 1 day is 6 years, 11 months and 30
  days. If you add a negative interval, then 7 years minus 1 day is 6
 years,
  11 months and 28 days.
 
  Is there a good explanation for this behaviour (which applies both to
  DateTime::add and DateTime::sub)? I've tried searching the internals list
  but couldn't see any discussion of it. It seems like a bug that never got
  fixed to the point where there are tests to make sure things are still
  calculated wrong.

 Why is it a bug? With DateTime math, reversing an operation isn't
 necessarily going to work...


Forgot to mention - this has nothing to do with reversing operations. As
you can see from the unit tests for the Date extension, figuring out what
the interval is between two dates depends on knowing which dates you're
dealing with and if your interval is positive or negative. The fact that
the bug shows up for the example in the bug report is just a symptom of the
underlying problem.

Regards
Peter


-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] DateInterval bug

[Peter Lind]

On 13 April 2015 at 22:20, Derick Rethans der...@php.net wrote:

 On Sun, 12 Apr 2015, Peter Lind wrote:

  Hi,
 
  I wanted to get into PHP code development so I grabbed a random bug from
  bugs.php.net. Which turned out to be
 https://bugs.php.net/bug.php?id=69378
 
  The problem the bug report describes is that creating a diff between two
  dates and then subtracting the diff from the later date does not give you
  the former date. Or, as the bug report state, this should hold:
 
  B - (B - A) == A
 
  But it doesn't, because of the way DateInterval and DateTime interact. A
  DateInterval is broken up into years, months, days, hours, minutes and
  seconds - which can be added or subtracted from a date. However, months
 are
  not fit size, so the order in which things are added or subtracted
 matters.
  In the bug report, the problem arises because months are subtracted
 before
  days - and there's a huge difference between subtracting 17 days from 2.
  April and from 2. March.
 
  In itself, this isn't a big problem - but apparently this behaviour is
 how
  the system is supposed to work. In the tests for the date extension, I
  found this test for DateTime::add
 
  echo test_years_positive__6_shy_1_day: ;
  examine_diff('2007-02-06', '2000-02-07', 'P+6Y11M30DT0H0M0S', 2556);
 
  echo test_years_negative__6_shy_1_day: ;
  examine_diff('2000-02-07', '2007-02-06', 'P-6Y11M28DT0H0M0S', 2556);
 
  The third argument in the examine_diff calls is used in the constructor
  call to DateInterval. The difference is whether the interval will be
  positive or negative. Note the difference of two days - if you add a
  positive interval, then 7 years minus 1 day is 6 years, 11 months and 30
  days. If you add a negative interval, then 7 years minus 1 day is 6
 years,
  11 months and 28 days.
 
  Is there a good explanation for this behaviour (which applies both to
  DateTime::add and DateTime::sub)? I've tried searching the internals list
  but couldn't see any discussion of it. It seems like a bug that never got
  fixed to the point where there are tests to make sure things are still
  calculated wrong.

 Why is it a bug? With DateTime math, reversing an operation isn't
 necessarily going to work...


Math that isn't consistent is problematic, in my book. Or, to put it
another way: if someone told me, that there is 6 years, 11 months and 30
days between 7th Feb 2000 and 6th Feb 2007, I would agree. If the same
person then told me that the interval *is also* 6 years, 11 months and 28
days *and that both intervals are correct* - I would question the sanity of
that person. I would go so far as to say: don't ever manage my calendar.

The bug as I see it is that two classes/behaviours have been packed into
one - there should be DateIntervalRepresentation and DateInterval. The
first shows you how many years, months, days, etc there are between two
dates. The second is the actual interval between two dates. The first is
context dependent - it needs anchoring in at least one date. The second is
context independent.

Either that or do away with math you can't rely on. I think what we should
aim for in programming languages is the opposite of isn't necessarily
going to work...

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

[PHP-DEV] DateInterval bug

[Peter Lind]

Hi,

I wanted to get into PHP code development so I grabbed a random bug from
bugs.php.net. Which turned out to be https://bugs.php.net/bug.php?id=69378

The problem the bug report describes is that creating a diff between two
dates and then subtracting the diff from the later date does not give you
the former date. Or, as the bug report state, this should hold:

B - (B - A) == A

But it doesn't, because of the way DateInterval and DateTime interact. A
DateInterval is broken up into years, months, days, hours, minutes and
seconds - which can be added or subtracted from a date. However, months are
not fit size, so the order in which things are added or subtracted matters.
In the bug report, the problem arises because months are subtracted before
days - and there's a huge difference between subtracting 17 days from 2.
April and from 2. March.

In itself, this isn't a big problem - but apparently this behaviour is how
the system is supposed to work. In the tests for the date extension, I
found this test for DateTime::add

echo test_years_positive__6_shy_1_day: ;
examine_diff('2007-02-06', '2000-02-07', 'P+6Y11M30DT0H0M0S', 2556);

echo test_years_negative__6_shy_1_day: ;
examine_diff('2000-02-07', '2007-02-06', 'P-6Y11M28DT0H0M0S', 2556);

The third argument in the examine_diff calls is used in the constructor
call to DateInterval. The difference is whether the interval will be
positive or negative. Note the difference of two days - if you add a
positive interval, then 7 years minus 1 day is 6 years, 11 months and 30
days. If you add a negative interval, then 7 years minus 1 day is 6 years,
11 months and 28 days.

Is there a good explanation for this behaviour (which applies both to
DateTime::add and DateTime::sub)? I've tried searching the internals list
but couldn't see any discussion of it. It seems like a bug that never got
fixed to the point where there are tests to make sure things are still
calculated wrong.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Debugging code ...

[Peter Lind]

It sounds like you're suggesting that all work on PHP that does not boil
down to bug fixes be stopped.

I'd suggest an alternative: fork PHP and only merge bugfixes in to your own
version. Best of both worlds, you get to keep your beloved PHP pristine
without any of the cumbersome new features, and the rest of us can enjoy an
evolving language.

On 4 November 2014 15:30, Lester Caine les...@lsces.co.uk wrote:

 On 04/11/14 14:01, Florian Margaine wrote:
  Hi,
 
  On Tue, Nov 4, 2014 at 2:28 PM, Lester Caine les...@lsces.co.uk
  mailto:les...@lsces.co.uk wrote:
 
  On 04/11/14 13:13, Florian Margaine wrote:
   On the basis of 'If it's not broken', what is actually broken,
  and what
   is just a matter of 'I don't like that way of working'?
  
   I have a working Annotation system that has not changed since
  I started
   working with PHP. PHPEclise simple displays the information
  from the
   docblock comments and allows me to open the relevant file. I
  can then
   review the other functions available. I can update the
  material and have
   even resorted to porting files and adding extra notes when
  trying to
   decipher other peoples work.
  
   The problem these days is that projects are stripping the
  docblock data
   as 'not the modern way of doing things' and we end up with
  code that
   does not work with the IDE. Fortunately DVCS systems have some
  other
   advantages and one can cherry pick code changes while
  maintaining a
   different style of working.
  
   In addition to 'Annotation', there is a lot of discussion
  about adding
   types into the code. Having moved to using arrays to pass data
 to
   functions, the docblock material includes details on what is
  required in
   the hash, something that you will never get from any of the
  current
   discussions?
  
   Just to add to the fun, PHPEclipse seems to have lost support
  and while
   I have learnt enough Java in the past to fix a few little
 niggles,
   currently it is unable to cope with a number of new
  developments in PHP
   so I'm stuck on just what IS the next move ... While it would
  be nice to
   get on with some new code, nothing is stable enough these days
  to allow
   that :(
  
   Right now, I'm afraid your emails looks like a rant more than
 anything
   else. I'm absolutely certain that you have something interesting
  to say,
   but the message just didn't get through. Could you elaborate?
 
  Just that what many of us have used for years is coming under
 increasing
  pressure as other people promote their own way of working. In the
 past
  we have been able to co-exist, but it is becoming increasingly
 difficult
  as people 'update' coding styles. Anything that is added to the
 'core'
  WILL be used to update third party code, but the rest of the
  infrastructure is simply not keeping up.
 
 
  I'm sorry... I may be stupid. I'm not sure I understand what you want to
  say.
  I have a guess though: are you saying that, for example, PHPEclipse at
  its version from 2008 can't cope up with PHP at its version from 2014?

 Every IDE I've used has always working nicely with docblock annotation
 and typing and has provided the facilities people seem to think should
 be built in to PHP. The problem with keeping the available IDE's up to
 date with the current code is secondary and PHPEclipse just happens to
 be my preference, but if I switch to other options I find similar lag in
 support for key features. Learning a new platform is a bigger stopper
 currently than living with the holes and I will probably fix the problem
 with :: before giving up in and changing ... but it would be nice not to
 have the hassle.

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] New globals for PUT and DELETE

[Peter Lind]

Last time it stranded here:
https://www.mail-archive.com/internals@lists.php.net/msg67294.html

And I believe it's been up a number of times before that.

On 14 October 2014 14:47, Kris Craig kris.cr...@gmail.com wrote:

 Hey guys,

 Does anybody know why we have $_GET and $_POST, but not $_PUT and
 $_DELETE?  As far as I can tell, the only way to get these out currently is
 to parse their values by reading the incoming stream directly.

 Is there a reason why we don't want this or is it just that nobody has
 actually written it yet?

 --Kris




-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Cases Where Bash Shellshock Does Not Apply (mod_php, php-fpm )

[Peter Lind]

On 26 September 2014 12:48, Andrea Faulds a...@ajf.me wrote:


 On 26 Sep 2014, at 11:46, marius adrian popa map...@gmail.com wrote:

  Maybe we need an official stance about shellshock

 Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m
 not sure there’s much we can reasonably do about it. Similarly to the
 Heartbleed bug, control is not in our hands here.


Informing people about the cases where they *might* be at risk when running
PHP doesn't seem a bad idea. Even though PHP itself is not at fault.



 --
 Andrea Faulds
 http://ajf.me/





 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Cases Where Bash Shellshock Does Not Apply (mod_php, php-fpm )

[Peter Lind]

On 26 September 2014 13:37, Ferenc Kovacs tyr...@gmail.com wrote:



 On Fri, Sep 26, 2014 at 12:59 PM, Peter Lind peter.e.l...@gmail.com
 wrote:

 On 26 September 2014 12:48, Andrea Faulds a...@ajf.me wrote:

 
  On 26 Sep 2014, at 11:46, marius adrian popa map...@gmail.com wrote:
 
   Maybe we need an official stance about shellshock
 
  Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m
  not sure there’s much we can reasonably do about it. Similarly to the
  Heartbleed bug, control is not in our hands here.
 
 
 Informing people about the cases where they *might* be at risk when
 running
 PHP doesn't seem a bad idea. Even though PHP itself is not at fault.


 I think we should only communicate when we have something definite to say,
 and currently our official stance is that we aren't aware any problems
 related to shellshock, but that doesn't mean that there is none, so I'm not
 sure that we have something definite to say.
 If we do end up finding something affecting significant amount of users
 (even if that requires some misconfiguration or lousy fastcgi wrapper) we
 could make an announcement.



I think it's worth communicating what Redhat is:
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

As a PHP dev I'd love to be able to find information like that on php.net,
not having to figure out from other sources if it pertains to me or not.



-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] [VOTE][RFC] intdiv()

[Peter Lind]

On 30 July 2014 19:57, Sara Golemon poll...@php.net wrote:

 On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote:
  On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote:
  -1 explanation: I don't think %% is clear enough
 
  % returns the 2nd part of the integer division, %% returns the 1st.
 Surely that makes sense?
 
 That makes sense in PHP.  Probably only in PHP.


Not even in PHP.


-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Peter Lind]

On 28 September 2013 11:27, Madara Uchiha mad...@tchizik.com wrote:

 You guys are missing the point. This isn't a language level issue. I
 can imagine some sort of package or a library being made, some sort of
 wrapper around the current session commands, perhaps integrated into
 some sort of extension.

 But it is NOT a language level issue. This isn't a problem the
 language needs to solve, ESPECIALLY since userland implementation is
 so trivial.


I would disagree. PHP has very low security levels by default and some WTF
security issues because of default settings. It should be the other way
round: high security by default that you need to actively change if you
want it lowered.

The problem is that the majority of PHP developers for better or worse
think they can copypaste solutions to problems and forget about things
after that as long as the output on their screens look ok. For many
developers, security is an afterthought if even that. And you are, quite
simply, NOT GOING TO CHANGE THAT IN THE FORESEEABLE FUTURE.

It's not a question of whether you're right or wrong in principle - it's a
simple question of statistics. You will have close to zero impact on the
PHP developers, no matter how many blog articles you write. It is too large
and too diverse a group.

So you're stuck with two choices: accept that PHP security is lax and that
as a result a lot of code will have many attack vectors, or try to change
the language itself for the better. The third option of educate is a
mirage.

Note: I'm not saying this feature would be an overall benefit for the
security of PHP, but the reasoning behind it is right.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Peter Lind]

On 28 September 2013 12:25, Leigh lei...@gmail.com wrote:


 On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote:
 
  So you're stuck with two choices: accept that PHP security is lax and
 that as a result a lot of code will have many attack vectors, or try to
 change the language itself for the better. The third option of educate is
 a mirage.
 

 PHP provides you with all the tools you need to write secure apps. I could
 go around writing mysql_query($_REQUEST[blah]) but I don't. Why? Because
 I have been educated. We don't have restrictions in the core that prevent
 me from doing it, and we don't need them either.

Care to back that up with an argument?


 I agree with you, being secure by default is a worthy objective, but the
 proposal here shouldn't even be on by default. (remember not everyone is
 able to control their ini settings and whatnot)

Worthy objective? You just stated your opinion that you don't want default
protection in the core language. Which is it?


 Education is not a mirage. People picked up their insecure coding habits
 from somewhere, and if its from laziness then I don't think they really
 deserve protecting. If it was from a terrible blog article promoting
 insecure practices then we need better articles. There's not much we can do
 to remove the content that's already out there, but there's a lot we can do
 with providing new, up to date and accurate content.


How many years have PHP been around? For how long have we been trying to
educate people to avoid mysql_* functions? Has it worked? No. You can
educate a fair amount of people but when you have the userbase of PHP it's
downright stupid to think you'll get the majority on board.

Also, saying that people deserve what they get because they're not educated
developers, is being arrogant.


-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Peter Lind]

On 27 September 2013 12:12, Leigh lei...@gmail.com wrote:

 On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com
 wrote:
 
  On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote:
 
  There's several scenarios where a users IP changes and you don't want to
  drop their session. (That doesn't mean it should simply have an option
 to
  disable it either)
 
 
  Let's be clear here: this won't happen (in most cases), because the
 client
  will simply get a new cookie and the session will keep working; it's like
  what you would implement if your user level goes from anonymous to
 logged in
  and vice versa.

 Right, so maybe I misunderstood the intent of this.

 I was reading it as: valid SID on new IP = drop session, which to me
 seems like the more secure approach.

 What you're saying is is when a valid SID is supplied on a new IP, you
 regenerate the SID and the session continues to be valid on the new
 IP?

 So on a successful session hijack (correct SID, new IP) the attacker
 gets a new SID and keeps the valid session while the legitimate user
 gets kicked out.

 Not seeing how that improves things at all.

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


In your scenario, user gets booted and thus knows somethings wrong. Much
better than the attacker hijacking the session without the user knowing
anything at all.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed

[Peter Lind]

On 27 September 2013 12:54, Leigh lei...@gmail.com wrote:

 On 27 September 2013 11:39, Peter Lind peter.e.l...@gmail.com wrote:
  On 27 September 2013 12:12, Leigh lei...@gmail.com wrote:
 
  So on a successful session hijack (correct SID, new IP) the attacker
  gets a new SID and keeps the valid session while the legitimate user
  gets kicked out.
 
  Not seeing how that improves things at all.
 
  In your scenario, user gets booted and thus knows somethings wrong. Much
  better than the attacker hijacking the session without the user knowing
  anything at all.
 
  Regards
  Peter

 And what is done to invalidate the session now gained by the attacker?
 Since this is a proposal to handle such things internally.


And what is done when the user thinks everything is fine and dandy? My
point was that the scenario you created did not pose a problem - if
anything it would be a benefit (as you actually *can* detect some problems
now).

Do you really think random user X will think something is wrong beyond
 the site they were using just kicking them out for no reason? So now
 what do they do now? Log in again? The attacker still has the
 previously valid session, so nothing is gained.


That's for the userland code to decide.


 This is exactly why this kind of logic belongs as user code. We're
 starting to define rules for a system that should be agnostic to how
 it is being used.


I would agree. I was just pointing out that your example was not in fact
much of an argument against the proposal.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Re: Parsing PUT data

[Peter Lind]

On 24 September 2013 16:59, Daniel Lowrey rdlow...@gmail.com wrote:

 The bigger issue here is that the superglobals are a leaky abstraction. Any
 HTTP request method is allowed to have an entity body, so should we also
 create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used
 request methods? Where does it stop? This is the problem I see with all the
 requests to support for PUT similarly to POST. PHP web SAPIs support 95% of
 the HTTP use-cases people have, but the abstractions break down after that
 and continuously bolting on support for individual scenarios beyond that
 would be a mistake IMO.


Supporting the base set would not seem a bad idea, I'd say -
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9

PUT is not exactly exotic, though it might not be as used as it could be -
however, with the focus on REST APIs that is changing. Your argument makes
good sense for random HTTP verbs - but suggesting we shouldn't support easy
access to the basic set because where does it stop is not a very good
argument, in my eyes.

Regards
Peter

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9--
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

[Peter Lind]

Interesting to note that although Perl 6 is apparently capable of
decrementing strings, it doesn't fully mirror the incrementing:

http://feather.perl6.nl/syn/S03.html#line_516

Specifically: decrementing 'AAA' would not turn into 'ZZ' but would error,
according to that link

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

[Peter Lind]

On 19 July 2013 11:18, Dan Cryer d...@dancryer.com wrote:

 What's the intended use case for string increment / decrement?


Personally, I instantly think of mirroring spreadsheet columns - works
quite well in that context.


 It just seems like madness to me, using mathematical operators with
 strings, producing seemingly arbitrary results in some circumstances (C -
 B - A - NULL / False ?).


Throw a warning and don't decrement A/a any further - that's not arbitrary.


 Also what happens in other languages? Take for example German, in which ß
 comes after S, Ü after U, and so on.


Nothing, works purely on ascii, as is currently the case. Perl handles
other character sets though - see the link I posted for details on how.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Feature Proposal: Allow letter decrementing

[Peter Lind]

On 19 July 2013 12:34, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi,

 2013/7/19 Peter Lind peter.e.l...@gmail.com

 On 19 July 2013 11:18, Dan Cryer d...@dancryer.com wrote:

 What's the intended use case for string increment / decrement?


 Personally, I instantly think of mirroring spreadsheet columns - works
 quite well in that context.


 ++/-- 'XYZ1234' would have use cases.




 It just seems like madness to me, using mathematical operators with
 strings, producing seemingly arbitrary results in some circumstances (C -
 B - A - NULL / False ?).


 Throw a warning and don't decrement A/a any further - that's not
 arbitrary.


 -- is more problematic.
 --'XYZ' would be 'XYZ' or 'XYY0' or 'XYY'?


php -r '$a = YZ9; var_dump(++$a);'
gives me ZA0

If  php -r '$a = ZA0; var_dump(--$a);' doesn't give YZ9 you'll just be
left scratching your head.

Granted, you might be left scratching your head as to why string
incrementing works at all, but that can of worms was opened long ago.

It would be better not to change length of string, IMO.
 e.g. --'XYZ' became 'XYY'


I'd go with --XYZ - XYY
Also, the string length shouldn't factor into it.


 All chars would stop decrement at lowest chars of [0-9], [a-z], [A-Z].
 e.g. Lowest value of 'XYZ' is 'AAA'.

 This is not a symmetric operation of ++, but it's impossible to achieve
 symmetric
 operation ++/-- on strings anyway.


Only at the edge case - and I personally can't see why that would mean
asymmetric operation in the rest of the cases.


-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] RFC Proposal: New assign value operator

[Peter Lind]

On 27 June 2013 11:04, Tom Oram t...@scl.co.uk wrote:

 Hi Richard,

 Thanks for your reply, the main reason would be operator overloading rather
 than the typecasting example, the typecasting version is more for
 consistency. I am also fairly that there might be situations where it would
 be useful to set the value of a scalar while preserving the time and save
 the need for checking the type first, however I do admit I can't think of a
 concrete example.

 The main thing I was thinking is I often find myself writing things like:

 $obj-set(2);

 $obj-setValue(5);

 $obj-setX(4);

 Where the object only really represent a single value, examples are things
 like EmailAddress class, ZipCode class, MoneyValue class, etc.


What's the reason you're not doing:

$obj = new EmailAddress('m...@example.com');

or

$obj = new Money('16.99', new MoneyType('USD'));

... actually, email is the only one of the above mentioned classes, that
could have just one value (neither zip code nor money make sense without
context, as zip codes and money depend on locale). That's an aside though.
Main question being: are you arguing for operator overloading in PHP when
you should just use better constructors?

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] property de-referencing

[Peter Lind]

On 1 May 2013 14:35, Rasmus Schultz ras...@mindplay.dk wrote:

 
  This is a fringe feature, as evidenced by the fact that you
  are having a hard time convincing people that it is needed


 As with anything that isn't already established and well-known, it's hard
 to convince anyone they need anything they don't understand - I think the
 barrier here is me having difficulty explaining a new idea/concept. That
 doesn't make it a fringe feature - I have already demonstrated by example
 how this would be useful in practically every mainstream framework.


Then why are you not convincing them first to get them on board as support
for your proposal. Right now you're obviously fighting an uphill struggle.
Whether that's because your proposal is without merit or because you have a
hard time convincing people on this mailing list remains to be seen - so
how about taking a smarter approach and convincing your target audience
first, then come back here with more support and a better proposal?

Just a thought.

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] property de-referencing

[Peter Lind]

On 1 May 2013 14:55, Rasmus Schultz ras...@mindplay.dk wrote:

 Then why are you not convincing them first to get them on board as support
 for your proposal.


 It's not a proposal yet - I didn't want to write a lengthy RFC just to
 learn that all I had was a brainfart, or that everyone was going to be
 totally opposed. Having the discussion here surfaced a ton of questions
 that (so far) indicate (to me) that this might be a good idea, and also
 helps me address all of those questions if I do end up writing an RFC.

 If you think gathering the information in an RFC is the next logical step,
 I will try to find the time :-)


I think that 1) you might as well start the work now, both to give people a
place to get an overview of the discussion and to gather up the questions
of which there are already a few, and that 2) if you don't start by
reaching out to your indicated main audience (frameworks) then you won't
get the support the idea needs. Also, 3) as your indicated audience is
frameworks they will presumably have a lot of feedback - including your
basic no we don't need this or this would be awesome.

Note that I don't think frameworks would necessarily be the sole audience
for this - I just think your time would be better spent taking the idea
there first.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Proposed changes to PHP language

[Peter Lind]

On 6 March 2013 15:50, Alexandre TAZ dos Santos Andrade 
alexandre...@gmail.com wrote:

 This item
 2. Introduce base class for all PHP classes. E.g. Object. It would help
 in type hinting and allow to add new common methods without any magic.

 StdClass Already do that


?php
class A
{}


$obj = new A();
var_dump($obj instanceof StdClass);

Result:
bool(false)


  3. Parse body of PUT request in the same manner as it's done for POST

+1

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

[Peter Lind]

On 20 February 2013 00:12, Nikita Nefedov inefe...@gmail.com wrote:
 On Tue, 19 Feb 2013 19:10:22 -, Rasmus Lerdorf ras...@lerdorf.com
 wrote:

 On 02/19/2013 03:07 PM, Nikita Nefedov wrote:

 Are you grepping for all the functions or you are grepping just for some
 specific function? If so, you are likely already know what visibility
 this function has, so couldn't you grep for `public %functionName%`
 instead of `function %functionName%`?
 At the end, you can always use `grep
 '(function|public|private|protected) functionName' file`, and if it's
 long to type, you can make sh script, or even alias.


 public is the default visibility so it is often left off, so no, I can't
 grep for that.

 -Rasmus


 As Sara noted, we shouldn't let users define methods without modifiers at
 all, so at least public/private/protected will have to be there.


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


Just a quick check: you're absolutely certain this issue isn't much
better/easier handled with IDE macros/plugins? Something along the
lines of zen coding? If you're really that obsessed with typing 9
characters less, you must have considered keyboard shortcuts that let
you type the docblock, visibility, etc. in just 3-5 keystrokes.

Just a thought from userland
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: release frequency?

[Peter Lind]

As an outsider I would say consistency is king. Knowing that I can
rely on when new versions come out is much more important than whether
they contain 9 or 11 bug fixes. So, pick a schedule that works and
stick to it.

Just my thoughts.


--
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Core liason for PHP FIG

[Peter Lind]

You realize that this is not the list of PHP FIG, right?

On 16 December 2012 15:26, Lester Caine les...@lsces.co.uk wrote:
 Lars Strojny wrote:

 for all of you who don’t know, PHP FIG (Framework Interoperability
 Group,http://www.php-fig.org/) discusses ways frameworks and libraries can
 work together and integrate much easier. Current PSRs are PSR-0 to
 standardize autoloading, PSR-1 and PSR-2 that deal with coding styles. All
 three are great initiatives so far in bridging gaps between projects and
 making the PHP ecosystem, well, rounder.


 Well I'm already classed as a dinosaur, but I have been requesting a guide
 to writing code these days, however some of the MUST elements of PSR-2 are
 totally opposite to the style guide that I have worked with for years and I
 see no point in arbitrary having to restyle 10+ years of code. Trying to
 restyle for e_strict is bad enough.

 As an example ...
 Code MUST use 4 spaces for indenting, not tabs.
 WHY - tab's has been the standard for all my C/C++ code and every other
 language and is automatically tidied up to that format by my editor. When
 did a switch of this 'rule' come in? Or is there a plan to switch all of the
 core code base to follow the same rule? ;)

 At the end of the day PHP FIG is simply an example of one style of working.
 It is perhaps the style that many developments in core are following as
 well? But it not the only way of working? Personally I prefer to avoid
 'magic loading of files' and stick with specifying what files are load and
 from where. Avoids problems with different distributions changing the rules
 themselves! I see no hope of promoting a 'flat platform' staring point,
 since each distribution loves to promote it's own style of working, and
 running PHP on top of THEIR version of the world makes some standards
 academic? Where ARE files loaded tends to be the first problem when
 debugging a new distribution :(

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?

[Peter Lind]

On 4 September 2012 15:09, Lester Caine les...@lsces.co.uk wrote:
 Pierre Joye wrote:

 On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk  wrote:

 ??? OH YES IT DOES !!!
 MANY times I get a a few lines of text on a white screen ...
 Switch off E_STRICT and everything works fine ... as it was on PHP5.2

 If you have any doubts about how to configure your development or
 production servers, how to use logs or how to effectively debug php
 applications, please ask questions on php-general or php-setup mailing
 lists.

 Thanks for your understanding,

 Butt out Pierre ...

 I keep being told that there is nothing wrong with E_STRICT, and again
 someone has said that it does NOT cause crashes. I beg to differ here - IT
 DOES!
 Now if you are saying that I need to document these crashes as they SHOULD
 not be happening then I'll roll things back and start doing that, but *I*
 thought that these crashes were simply a known effect of using E_STRICT? And
 so I followed the directions, and switched E_STRICT off. On production
 machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen
 crashes using older code ... as far as I was concerned that was a known
 fact. Switch it off and everything runs fine!


From php.ini:
; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

In a production environment with display_errors off, E_STRICT doesn't
crash anything. Actually, even with it on, it doesn't crash anything -
shitty code does, by creating notices and then using header() calls
afterwards to create redirects.

Solution: fix your server. Fix your code. It worked for the rest of us.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC for Adding __toString to DateTime

[Peter Lind]

Best solution from a random developers perspective:
- stick the 4-line solution in the docs and on to the bug report. Then
mark as won't implement

It's a far better solution than choosing a random format for users, as
should be more than evident by now.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions

[Peter Lind]

On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:

*snip*


 Also, be aware that BCrypt only uses the first 72 characters of the
 password field. So if you use a hex encoded sha512 output, a good deal of
 entropy would be lost (almost half of it)...


Seeing as the hashing function will default (at first, at least) to
bcrypt, would it be possible to add a warning if it's given an input
longer than 72 chars? Preferably make the function context-aware so
you don't get the same warning if using sha512. Otherwise I predict
that someone will do:

$hash = password_hash($my_128_char_pepper . $password, PASSWORD_DEFAULT);

Which obviously renders the hashing useless, as you'll be hashing the
same 72 chars over and over again. Which, currently, crypt() let's you
get away with without as much as a hiccup.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions

[Peter Lind]

On 31 July 2012 22:02, Anthony Ferrara ircmax...@gmail.com wrote:
 Peter,

 On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:

 On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:

 *snip*

 
  Also, be aware that BCrypt only uses the first 72 characters of the
  password field. So if you use a hex encoded sha512 output, a good deal
  of
  entropy would be lost (almost half of it)...
 

 Seeing as the hashing function will default (at first, at least) to
 bcrypt, would it be possible to add a warning if it's given an input
 longer than 72 chars? Preferably make the function context-aware so
 you don't get the same warning if using sha512. Otherwise I predict
 that someone will do:

 $hash = password_hash($my_128_char_pepper . $password, PASSWORD_DEFAULT);

 Which obviously renders the hashing useless, as you'll be hashing the
 same 72 chars over and over again. Which, currently, crypt() let's you
 get away with without as much as a hiccup.


 That's actually a very good idea.

 I'm curious though. Should we warning? Or should we sha512 hash (to bring
 down to 64 chars)...  That's something I think would be worth reaching out
 to the crypt() maintainers for advice...

I'd be wary of not doing what people actually expect - i.e. hash the
provided string with the specified algo. Better to educate the users,
I'd say, through a warning. Anyway, as you said, would be good to get
other opinions on this.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Peter Lind]

* snip*

 Stas has the right approach, not only should the methods be simplified and
 platform/algorithm agnostic but have a proper salt built in (there are a
 few CSPRNG implementations around), I've seen salts used from numbers to
 md5's to just being skipped altogether.

 Well, just to be clear, a salt does not need a CSPRNG. All it needs to
 be is reasonably unique. In fact, I wouldn't make it CS, as that would
 deplete the available entropy in the system for CSPRNG generation.

Whether or not a CSPRNG is needed depends on what you're doing, your
needed level of security. Perhaps add a parameter to control this, so
it would be possible to make use of this function even if you need the
maximum level of security? If it's not available, the function should
fail in some suitable fashion.

*snip*

 Or, we could implement a system like I did in
 https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random
 that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2
 Where it mixes together several sources of weak and moderate strength
 PRNG...

Will the entropy multiply by mixing sources? I.e. will the result be
more random? Won't it just be as random as the most random source?

Other than that, the SPL version seems like a nice idea.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Peter Lind]

On 14 June 2012 15:35, Anthony Ferrara ircmax...@gmail.com wrote:
 Peter,

 Whether or not a CSPRNG is needed depends on what you're doing, your
 needed level of security. Perhaps add a parameter to control this, so
 it would be possible to make use of this function even if you need the
 maximum level of security? If it's not available, the function should
 fail in some suitable fashion.

 For password hashing, it won't ever be needed for the salt. The salt
 is not a secret in the context of cryptography. But, on that note, if
 we were adding a stronger PRNG generator, it would be good to expose
 it natively. And that native exposure would likely take a parameter
 for CS-safe PRNG...

I would say it really depends upon the project. The salt can not only
protect against rainbow tables and password hash collisions, if it is
unknown to an attacker then it essentially acts to further strengthen
the hash by vastly expanding the keyspace. Supposing an attacker is
trying to get at the password for just one user account (say, admin)
and the hashed password is available - if the salt can be
predicted/guessed, then the keyspace is reduced to that of an unsalted
password and you can run a dictionary attack on the hash. If, on the
other hand, the salt is unpredictable and you don't have access to it,
there is no way to run a dictionary attack (offline, that is). The
security here depends upon storage as well, but the point remains - a
salt isn't by default something you can make public knowledge.

It might be a theoretical concern for most people and the people
really wanting the extra level of security would probably know well
enough how to get exactly what they need - but if provisions are made
so you could reuse the same function you might also be able to educate
developers better. I.e. make it easy to do the right thing and more
people will do it.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding a simple API for secure password hashing?

[Peter Lind]

On 14 June 2012 17:50, Ángel González keis...@gmail.com wrote:

*snip*

 May I ask how would you end up at the situation where the attackers have
 the password hashes but not the salt?

 Any process which needs to read the password hashes will also need
 knowledge of the salt. Thus an attacker would most likely also know both.
 That's precisely how salts are designed to work.

If your salts are not stored with your password hashes, then an sql
injection that would leak your password hashes would not leak the
salts. The recent database leaks come to mind: had they only contained
password hashes but no salts (I know the hashes were unsalted, but
*had* they been salted ...) attackers would have faced an impossible
task trying to bruteforce even just one hash. Otherwise, you'd be able
to focus on a given account (an admin account comes to mind) and spend
all your efforts on that using the typical options.

As pointed out once or twice, for most people/purposes, it's a
theoretical discussion. That doesn't mean it shouldn't be taken into
consideration though (people rarely break into your house where you
expect them to).


 I admit you could have a common salt for all users stored in php and
 only a leak of the database. But such salt would most likely be provided
 by the user, generated using a different program... expected to be secure.
 Using a shared salt is worse than a uniqe salt per user, so that's not
 something to promote either.
 You wouldn't be educating in the right way.

And I'm obviously not advocating a shared salt (at least, I wasn't
thinking I was, especially seeing as I asked for a parameter in
function to make sure that salts would be more random).

Regards
Peter


-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] running tests in parallel?

[Peter Lind]

On 3 May 2012 13:12, Derick Rethans der...@php.net wrote:
 On Thu, 3 May 2012, zoe slattery wrote:

 (a) Would it still be helpful if the tests could be run faster?

 Yes.

Running the tests on my netbook takes a very long time - yet is
presumably still a good thing to do. Having them run in parallel would
be a very nice feature :)

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] skipping optional parameters

[Peter Lind]

On 18 April 2012 07:56, Alexey Shein con...@gmail.com wrote:

*snip*


 One question about implementation:
 Given we have this function
   function create_query($where, $order_by, $join_type='', $execute = false, 
 $report_errors = true) {}
 and this statement
 On the engine level, it will be implemented by putting NULL in the place 
 where the parameter is passed.

 what value $join_type will get on this call?
 create_query(deleted=0, name,,, /*report_errors*/ true);

 NULL or empty string? I.e. will optional parameters always get NULLs
 or their default values?

It needs to be the default values, otherwise it will be a huge WTF for
developers.

With that in mind: +1 if default values are used when skipping
parameters, -1 if NULL is used when skipping parameters (not that I
have voting power, just showing preferences/support).

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)

[Peter Lind]

On Feb 22, 2012 7:05 PM, Larry Garfield la...@garfieldtech.com wrote:

 On 2/21/12 5:45 PM, Tjerk Meesters wrote:

 On 22 Feb, 2012, at 2:03 AM, Ralf Langl...@b1-systems.de  wrote:

 I see no reason why it would be not desirable to have PHP raise the
 exception rather than putting more or less repeating code snippets all
 around the place. That is why I am asking.


 You must be returning false/null somewhere. It's the same effor to
 instead throw an exception or to return a Ghost family member.


 The $baby-mother() method cannot know if the using code just wants to
collect the $mother object or execute code on it. It can also not know if
having no $mother is a problem or just a fact to deal with. Unconditionally
raising an exception is a bit overkill here, at least if we would get an
exception for trying to access (null)-mother();

 Currently the user code must check each link of the chain if it is
available, although it is only interested if it can get the final result or
not.

 I'll follow the suggestion and write an RFC.


 You'll have my vote! :) bloating code with chainable checks is just
crazy, something that the engine can do much more efficiently and
unambiguously.


 I would also support this.  There's a myriad reasons why something may
return NULL or FALSE when you expect it to return an object, some of them
even legitimate.  Any function/method whose documentation line is returns
the foo object, or NULL if someone screwed up and there isn't one is
perfectly reasonable in many cases, IMO, but makes all chains a potential
fatal.  An exception would make a lot more sense, and allow us to
centralize handling of such exceptional cases rather than throwing
if-checks everywhere.  (Which is exactly what exceptions are for.)

 --Larry Garfield


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


Seems to me this change would encourage bad habits (breaking the law of
Demeter) which would personally put me against it.

Regards
Peter

Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)

[Peter Lind]

On 22 February 2012 20:04, Larry Garfield la...@garfieldtech.com wrote:
 On 2/22/12 12:37 PM, Peter Lind wrote:

 I would also support this.  There's a myriad reasons why something may

 return NULL or FALSE when you expect it to return an object, some of them
 even legitimate.  Any function/method whose documentation line is returns
 the foo object, or NULL if someone screwed up and there isn't one is
 perfectly reasonable in many cases, IMO, but makes all chains a potential
 fatal.  An exception would make a lot more sense, and allow us to
 centralize handling of such exceptional cases rather than throwing
 if-checks everywhere.  (Which is exactly what exceptions are for.)


 --Larry Garfield


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


 Seems to me this change would encourage bad habits (breaking the law of
 Demeter) which would personally put me against it.

 Regards
 Peter


 How?  What bad habit does this encourage?


 --Larry Garfield


As I wrote, the law of Demeter (http://en.wikipedia.org/wiki/Law_Of_Demeter)

The OP started out with this code example, as a reason to introduce the change:

$granny_name = $baby-getMother()-getMother()-getName();

The code shouldn't be aware of all the links, it's a bad habit. Rewrite to:

$granny_name = $baby-getGrandmother()-getName()

or

$granny_name = $baby-getGrandmotherName();

And with the latter, you've reduced the amount of checks you have to
do, by putting them in the proper places (if baby and mother objects
inherit from the same class you've essentially got one check on null
inside getMother(), not many spread out in client code). Also, the
client code now only knows about the immediate surroundings - and
should obviously know if getGrandmother() or getGrandmotherName() can
throw exceptions.

So as far as I'm concerned, the feature proposed just makes it a
easier to couple your code more tightly. I'd rather the language
discouranged that - or at least not encourage it.

Regards
Peter


-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4's New De-referencing plus assignment

[Peter Lind]

On 30 November 2011 19:59, Will Fitch will.fi...@gmail.com wrote:
 Again, back to my question of why not use:

 MyComponent::factory($bar, $option);

 Depending on what ::factory does, it could then pass $option(s) to the 
 constructor or method getting your instance needed.


It brings to mind a review of Dart by a perl-guy
(http://blogs.perl.org/users/rafael_garcia-suarez/2011/10/why-dart-is-not-the-language-of-the-future.html).
Specifically:

I should note that the integration of popular design patterns at the
syntax level is disappointing: design patterns tend to emerge to work
around a language design's weaknesses. Embracing them is a bit like
admitting a design failure up front.

The proposed change has the same feel to it.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Peter Lind]

On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote:
 On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote:

 Sorry for jumping into the thread, but I couldn't help noting that you seem
 confused about the distro suggestion. I think Ubuntu was the example, and
 there's nothing random at all about their release process. There are fixed
 timelines and life cycles in Ubuntu - having less branches does not in any
 way stop them from having a fixed release process and schedule.

 It is about random release being chosen as LTS. For many users, it
 will preventing migration until a given feature is part of a LTS
 release.

 Our proposal to have fixed life time and release cycles does not have
 this random effect and each x.y release is equally supported for the
 same duration. The amount of branches can be reduced easily and even
 if we may have many at one point, it will be only about sec fixes,
 that's really not a problem (a bit of automated tasked will help here
 too).

Then it's an argument about wording, not content. See
https://wiki.ubuntu.com/Releases : the LTS have fixed life time and
come at fixed intervals - basically exactly the same you propose with
fixed life time and release cycles.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Peter Lind]

On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:

*snip*


 No, it is the same that what we proposed. What we proposed is that
 every release is actually a LTS release. What Ubuntu uses works fine
 for distros given that it is a distro with an insane amount of totally
 unrelated projects they distribute, and alternative repositories exist
 for almost each of them.

 For a programming language, it is a totally different story.


That makes more sense - you were, however, arguing against random LTS
releases which was rather confusing (there's a big difference between
every release is an LTS and all LTS releases are random - those
are not the only options).

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Peter Lind]

On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote:
 On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote:
 On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:

 *snip*


 No, it is the same that what we proposed. What we proposed is that
 every release is actually a LTS release. What Ubuntu uses works fine
 for distros given that it is a distro with an insane amount of totally
 unrelated projects they distribute, and alternative repositories exist
 for almost each of them.

 For a programming language, it is a totally different story.


 That makes more sense - you were, however, arguing against random LTS
 releases which was rather confusing (there's a big difference between
 every release is an LTS and all LTS releases are random - those
 are not the only options).

 The randomness is about which release-features tuples would become a
 LTS, that's something that can't apply well to a project like php.


It's hard to see how that would be any more or less random than now,
given that it would still be a question of votes or consensus.
Presumably, features would not be removed (unless they were bad for
the language) and so they would still make it into LTS releases - the
next one up.

Anyway, I'll stop it here, as I doubt I'll convince you of anything
(and vice versa).

Just one thing to add: thanks for the work on PHP :) Much appreciated.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Notice on array to string convertion

[Peter Lind]

On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote:


 Am 02.06.2011 16:24, schrieb Marcel Esser:
 I am not convinced that making this an error is a good idea.

 If I receive a $_GET/$_POST value that I expect to be a string value, but I 
 actually received an array, this would
 mean I need to now explicitly check for it, since it will stop the runtime 
 otherwise.

 so fix your code jesus christ

How about you take your medication, then chill down, then consider
your messages a couple of times before sending? It would make the
atmosphere quite a bit nicer.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Peter Lind]

On Jun 2, 2011 12:46 AM, Pierre Joye pierre@gmail.com wrote:

 hi Chris

 On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
 christopher.jo...@oracle.com wrote:
 
 
  On 06/01/2011 03:09 AM, Pierre Joye wrote:
 
  URL: https://wiki.php.net/rfc/releaseprocess
 
  Pierre,
 
  There are some immediately practical things here.  Some things will
  be a large jolt for the community and might be better introduced in
  future releases.
 
  Chris
 
  Good:
   - Scheduled releases
   - Use of RFCs
   - No PHP script breakages in x.y.z+1 releases
 
  Too complex or not good:
   - Number of concurrent branches: Johannes's suggestion was good

 This proposal for distros not for programming languages or similar
 tools. All users I talk to need fixed timeline, life cycle, etc. to
 have a clear and plan-able way to deal with php versions.


Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.

Regards
Peter

Re: [PHP-DEV] [RFC] Return type-hint

[Peter Lind]

On Apr 29, 2011 4:47 PM, Martin Scotta martinsco...@gmail.com wrote:


  Martin Scotta


 On Thu, Apr 28, 2011 at 5:15 PM, Peter Lind peter.e.l...@gmail.com
wrote:

 2011/4/28 Martin Scotta martinsco...@gmail.com:

 * snip *

  IMHO I would not trust on any return value, as PHP did not ensure
anything
  about them.
  Even more, I do not write code that depend on return values, I prefer
to
  use input/output parameters,

 I cannot help but wonder why PHP is your language of choice. I mean no
 disrespect, but PHP does not have strict typing (for a reason) and
 forcing it upon PHP seems strange to me. Seeing as a) you'll either
 have to implement the return type hinting yourself in which case you'd
 know anyway what the return value is or b) you'd have to have others
 implement it in their libraries in which case you'd have to wait years
 for any noticeable effect, the feature seems useful only in edge cases
 (such as Hiphop, which I think one can question the mainstream
 usefulness of, currently).


 I understand why PHP does not have strict typing as much as I understand
why PHP do not have good-qualities third-party libraries.
 I'm not saying that there aren't good libraries, but the language has many
holes that makes almost impossible to build solid library (ie: include)

I have come across good php libraries. In fact, I haven't used ant really
bad ones. Again, maybe its a question of different environments - but I
cannot see any reason why building a library should be inherently harder in
php than strictly-typed languages.

 All the strictness of ppp, typehint and the like are not restrict things,
they are meant as boundaries for client code, to ensure the correct and well
defined behavior.

There's a very big difference between ppp and typehinting. As Stas noted,
they serve very different purposes - and while ppp typically goes with oop
(though not in every language), strict typing is not in any way necessary to
do oop. That should be obvious given the large amount of working oop code
out there.

 It's ok if you write all you code as procedural, or you don't like to
write classes, but IMHO the language should provide a solid foundation for
them, this way you can rely on libraries for common task and make your
procedural code even simpler, shorter and safer.

My background was assembler before languages like php. To me, strict typing
makes it harder, not easier, to make or use a good library. That's not to
say that strict typing is bad - just that what you need depends on your
experience. I've never had a need for strict typing in php, I don't find
myself making the errors that strict typing solves in, say c#.

 I'm not sure if return typehint will be a good idea, but I'm not against
it.
 I believe the language has to deal with other pending stuff prior to
this. PHP has many blind areas, whenever you call something, you don't know
if you will return or it will just die in a non-sense Fatal error.

Honestly, I've never had this problem, and I'd like to hear mire of your dev
environment to see what leads to them :)

Regards
Peter


 Personally, I read code if I'm not sure what a given function/method
 will return - or just test. I actually thought unit tests took care of
 issues like this. I don't think having a list of possible return
 values would make things simpler than the good old try it and see -
 which is one of the greatest assets of PHP.

  This is the safer way I've found to achieve the same behavior
 
  function no_return(ReturnStatus $returnStatus) {
doSomething();
 
if ( itWasOk() )
{
$returnStatus-setReturnValue( new Foo ); // return type hint
$returnStatus-success(); // return status
}
elseif ( isWasCritical() )
{
$returnStatus-setException( new RuntimeException );
$returnStatus-exception(); // return status
}
else
{
$returnStatus-fail(); // return status
}
  }
 
  Of course I don't write all functions like this.
  This is pattern I use when I need to ensure that the type returned is
valid.

 I just return what I need to from the function/method or throw an
 exception. Indicating that you want to throw an exception instead of
 actually throwing one seems ... overly polite, at best. As far as I
 can tell, you'd have to check the ReturnStatus object anyway, so I
 don't see how you're any safer (PHP has functions for checking null
 values, false values, try/catch blocks and other things too). But
 maybe we're dealing with very different development environments and I
 just cannot see the usefulness of the suggested as it wouldn't make a
 positive difference in mine.

 Just a perspective from a typical webdev.
 Regards
 Peter

 --
 hype
 WWW: plphp.dk / plind.dk
 LinkedIn: plind
 BeWelcome/Couchsurfing: Fake51
 Twitter: kafe15
 /hype

Re: [PHP-DEV] [RFC] Return type-hint

[Peter Lind]

2011/4/28 Martin Scotta martinsco...@gmail.com:

* snip *

 IMHO I would not trust on any return value, as PHP did not ensure anything
 about them.
 Even more, I do not write code that depend on return values, I prefer to
 use input/output parameters,

I cannot help but wonder why PHP is your language of choice. I mean no
disrespect, but PHP does not have strict typing (for a reason) and
forcing it upon PHP seems strange to me. Seeing as a) you'll either
have to implement the return type hinting yourself in which case you'd
know anyway what the return value is or b) you'd have to have others
implement it in their libraries in which case you'd have to wait years
for any noticeable effect, the feature seems useful only in edge cases
(such as Hiphop, which I think one can question the mainstream
usefulness of, currently).

Personally, I read code if I'm not sure what a given function/method
will return - or just test. I actually thought unit tests took care of
issues like this. I don't think having a list of possible return
values would make things simpler than the good old try it and see -
which is one of the greatest assets of PHP.

 This is the safer way I've found to achieve the same behavior

 function no_return(ReturnStatus $returnStatus) {
   doSomething();

   if ( itWasOk() )
   {
       $returnStatus-setReturnValue( new Foo ); // return type hint
       $returnStatus-success(); // return status
   }
   elseif ( isWasCritical() )
   {
       $returnStatus-setException( new RuntimeException );
       $returnStatus-exception(); // return status
   }
   else
   {
       $returnStatus-fail(); // return status
   }
 }

 Of course I don't write all functions like this.
 This is pattern I use when I need to ensure that the type returned is valid.

I just return what I need to from the function/method or throw an
exception. Indicating that you want to throw an exception instead of
actually throwing one seems ... overly polite, at best. As far as I
can tell, you'd have to check the ReturnStatus object anyway, so I
don't see how you're any safer (PHP has functions for checking null
values, false values, try/catch blocks and other things too). But
maybe we're dealing with very different development environments and I
just cannot see the usefulness of the suggested as it wouldn't make a
positive difference in mine.

Just a perspective from a typical webdev.
Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] How deep is copy on write?

[Peter Lind]

On 19 January 2011 20:05, la...@garfieldtech.com la...@garfieldtech.com wrote:
 So it sounds like the general answer is that if you pass a complex array to
 a function by value and mess with it, data is duplicated for every item you
 modify and its direct ancestors up to the root variable but not for the rest
 of the tree.

 For objects, because of their pass by handle-type behavior you are
 (usually) modifying the same data directly so there's no duplication.

 Does that sound correct?

 Related: What is the overhead of a ZVal?  I'm assuming it's a fixed number
 of bytes.


http://lmgtfy.com/?q=php+zvall=1

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] new foo()-bar()

[Peter Lind]

On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
 Hi all,
 I'm here again to presents another proposal, which adds support for
 instantiating a class and calling its methods and accessing its properties
 on same command.

 Example:

 ?php

 class bar {
  public $x = 'PHP';
 }

 class foo extends bar {
  public function bar() {
    return $this;
  }
 }

 var_dump(new foo()-bar()-x); // string(3) PHP

 ?

 Other examples which describes the feature at
 http://wiki.php.net/rfc/instance-method-call

 Thoughts?

It seems fairly handy and I've been in situations where I wanted to do
something like that - in fact, I use factories to achieve something
similar.
 However, the more I use it, the more it feels like introducing code
smells into my code. You're essentially instantiating an object only
to immediately throw it away. That means you don't actually need the
object at all, you should probably be looking for static methods or
class properties. Trying to avoid statics by introducing a way to
instantiate and throw away objects in the same statement feels a lot
like reinventing OOP while adding overhead.

Anyway, just a personal observation. I generally favour the way that
PHP allows you to dig your own grave (i.e. I love the freedom of the
language), so as a developer I would probably favour this as well,
though I find it mainly a way to introduce hacks.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] new foo()-bar()

[Peter Lind]

On 26 November 2010 21:37, Ferenc Kovacs i...@tyrael.hu wrote:


 On Fri, Nov 26, 2010 at 9:25 PM, Peter Lind peter.e.l...@gmail.com wrote:

 On 26 November 2010 20:36, Felipe Pena felipe...@gmail.com wrote:
  Hi all,
  I'm here again to presents another proposal, which adds support for
  instantiating a class and calling its methods and accessing its
  properties
  on same command.
 
  Example:
 
  ?php
 
  class bar {
   public $x = 'PHP';
  }
 
  class foo extends bar {
   public function bar() {
     return $this;
   }
  }
 
  var_dump(new foo()-bar()-x); // string(3) PHP
 
  ?
 
  Other examples which describes the feature at
  http://wiki.php.net/rfc/instance-method-call
 
  Thoughts?

 It seems fairly handy and I've been in situations where I wanted to do
 something like that - in fact, I use factories to achieve something
 similar.
  However, the more I use it, the more it feels like introducing code
 smells into my code. You're essentially instantiating an object only
 to immediately throw it away. That means you don't actually need the
 object at all, you should probably be looking for static methods or
 class properties. Trying to avoid statics by introducing a way to
 instantiate and throw away objects in the same statement feels a lot
 like reinventing OOP while adding overhead.

 Anyway, just a personal observation. I generally favour the way that
 PHP allows you to dig your own grave (i.e. I love the freedom of the
 language), so as a developer I would probably favour this as well,
 though I find it mainly a way to introduce hacks.


 1, I have to use a non-trivial library or module for a simple task, and I
 don't want to write 20 line of code, and introduce 4 helper variable.

If it's a one-off, then I really don't see the problem. If you're
facing it again, write a facade.

 2. I want to get from point 1 to point 5 but I'm not interested in the steps
 in-between (classical method chaining), but sadly one of the steps requires
 object instantiation.

If it's your code, then why are you not simplifying it? What's the
point of writing code that you have to go through in five steps? Why
not write a wrapper method?
 The reasons presented sounds quite like I want to be able write
hacks easier rather than I want to fix an actual problem. I.e.
there are solutions for this already that use OOP principles.

That said, this fix may very well address other situations :)

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] new foo()-bar()

[Peter Lind]

On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
 On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote:


 It seems fairly handy and I've been in situations where I wanted to do
 something like that - in fact, I use factories to achieve something
 similar.
  However, the more I use it, the more it feels like introducing code
 smells into my code. You're essentially instantiating an object only
 to immediately throw it away.


 Not necessarily; you could be calling the method for the collateral effects 
 and that method return the object itself. This is not that uncommon.


And I can do that today with a factory pattern, if I want to.
Anyway, I don't want to argue against the feature, as it will just
introduce a slightly shorter version of something we can already do.

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] new foo()-bar()

[Peter Lind]

On Friday, November 26, 2010, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
 On Fri, 26 Nov 2010 20:25:32 -, Peter Lind peter.e.l...@gmail.com wrote:


 It seems fairly handy and I've been in situations where I wanted to do
 something like that - in fact, I use factories to achieve something
 similar.
  However, the more I use it, the more it feels like introducing code
 smells into my code. You're essentially instantiating an object only
 to immediately throw it away.


 Not necessarily; you could be calling the method for the collateral effects 
 and that method return the object itself. This is not that uncommon.


And I can do that today with a factory pattern, if I want to.
Anyway, I don't want to argue against the feature, as it will just
introduce a slightly shorter version of something we can already do.

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feasibility of additional support around constants.

[Peter Lind]

*snip*

Seems to me that some of this could be handled with a custom built
function wrapping
http://dk2.php.net/manual/en/function.get-defined-constants.php

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Peter Lind]

Den 2010 10 30 03:51 skrev Chad Emrys ad...@codeangel.org:

* snip *

 What is in a name anyway?

There's something VERY ironic about a statement like that given what you're
asking for ...

Regards
Peter

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Peter Lind]

On 30 October 2010 09:09, Mike Van Riel mike.vanr...@naenius.com wrote:

* snip *

 (additionally I wonder why people ask such a simple question on IRC whilst
 googling provides your answer faster..)

Most of the people coming to ##php on freenode asking questions like
that have a hard time learning (on their own or at all) - they expect
to be spoonfed. Changing the token name might lower the frequency of
this particular question, but it would have no overall effect on the
number of people coming to ask questions they could get answered in
two seconds by google.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Peter Lind]

On 30 October 2010 09:34, Chad Emrys ad...@codeangel.org wrote:
 On 10/30/2010 02:16 AM, Peter Lind wrote:

 On 30 October 2010 09:09, Mike Van Rielmike.vanr...@naenius.com  wrote:

 * snip *



 (additionally I wonder why people ask such a simple question on IRC
 whilst
 googling provides your answer faster..)


 Most of the people coming to ##php on freenode asking questions like
 that have a hard time learning (on their own or at all) - they expect
 to be spoonfed. Changing the token name might lower the frequency of
 this particular question, but it would have no overall effect on the
 number of people coming to ask questions they could get answered in
 two seconds by google.

 Regards
 Peter



 It's the same argument everyone else is giving,  and really it all comes
 down to this.:

 Nostalgia is valued over clarity and consistency.

 Do you guys REALLY want to claim that?


I wasn't arguing for or against a switch, just providing some
background. That said, people with no google skills bugging you on irc
is a very poor excuse for change. As for the rest of the discussion,
both sides seem to have merit, in my opinion.

Regards
Peter


-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Peter Lind]

On 30 October 2010 19:18, Chad Emrys ad...@codeangel.org wrote:
 On 10/30/2010 11:58 AM, Daniel P. Brown wrote:

 On Sat, Oct 30, 2010 at 12:47, Chad Emrysad...@codeangel.org  wrote:


 It's not that I'm that sure of myself, it's that I believe that my
 opinion
 has merit, and I keep seeing the exact same argument over and over again
 that I believe is not a very good argument (They can just google it
 thing).
  Some other people have provided other arguments as well and those are
 more
 valued. (Though I don't think they are strong enough reasons yet NOT to
 do
 it).


     It does have merit --- to you, and perhaps a few others.
 Hopefully without sounding like I'm ridiculing you (it's not my
 intent), have you seriously considered this at all, and are you
 realizing that it's just not going to happen at this time?  I mean, if
 you submitted a request or implementation proposal for an INI-based
 option to switch between token strings and expanded help messages,
 that would likely receive more serious attention than the dismissive
 responses and formed opinions of your own insight as based upon this
 discussion.



 Forking won't fix this particular problem.


     Well, if your statement about how no one here who disagrees with
 you does enough support (which is, quite frankly, an asinine
 assessment), then an equal rebuttal will be that you do not know
 enough about the inner workings of the software you claim to support,
 nor the culture of the group who maintains it.

     You're taking a minor annoyance and trying to convince the masses
 - and indeed the powers that be - that it is tantamount to Y2K38.
 Again, I'm really not trying to insult you or your original opinion
 here, Chad, but the continued arguments are almost coming off as silly
 now.



 If you haven't noticed, I am a bit stubborn, yes it's a problem.  When I
 submitted this proposal, I have to at least try to plant a bug in their
 brain that perhaps, they are being to hasty on dismissing this argument.
  True, I do not know a lot about this particular culture that maintains PHP.
  I just know the bigger culture of those who use PHP, and some of them are
 quite annoyed by the dismissive nature of the maintainers who are quite at
 odds to what the majority of the community want or needs.  And I am sort of
 glad to annoy those who are overly dismissive, and hopefully ploy the one's
 who are on the fence.

 No one said I was good at politics.  But the fact one has to play the
 politics game here to get anything worth while doesn't really phase me.

 Now I am starting to find this argument straying from the point.  I don't
 believe attacking me personally or me attacking the nature of this mailing
 list really has to do with the subject line.


Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems
to me that might get a lot more traction.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Peter Lind]

On 30 October 2010 22:13, Chad Emrys ad...@codeangel.org wrote:

*snip*


 I actually know Etienne, he does spend some of his time fighting the good
 fight of supporting PHP :p.  Anyway he has said the lemon parser project is
 going kind of slow as it is proving to be more difficult because some of the
 weirdness in PHP. (Don't ask me what that means.) Maybe more help should be
 put into that effort?

That was my point: perhaps that would be a less futile fight than
trying to persuade people that t_paamayim_nekudotayim should be
renamed.

Regards
Peter

-- 
hype
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Array Dereferencing

[Peter Lind]

On 8 June 2010 17:28, Brian Moon br...@moonspot.net wrote:
 The operator that really determines this is 'new' - which is already
 documented. So there isn't any ambiguity. Not to say that documenting
 the other operators would be bad, just saying there's no ambiguity
 here :)
  Also, allowing new (blah()); would be a fairly big BC break I'd say.

 How? Maybe you don't understand what BC break means. Currently, new (
 produces a parse error. So, no old code would ever be broken. That is what a
 BC break is. A change to the system that breaks old code. New code very
 often does not run on older versions of the parser.

I do understand what BC break means - I was probably just too quick on
that one. I figured that allowing 'new (blahblah())' would introduce
ambiguity for handling parentheses in general with regards to 'new',
but I'm probably wrong.

Regards
Peter

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Type hinting

[Peter Lind]

On 23 May 2010 07:52, Larry Garfield la...@garfieldtech.com wrote:
 On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
 At 01:01 23/05/2010, Hannes Magnusson wrote:
 On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
 wrote:
   On 22.05.2010, at 18:30, Josh Davis wrote:
   As you wrote, you worked on PHP's _type system_ which is dynamic,
   really cool, juggles strings with ints and what not. However, the
   topic here is the _type hinting system_. As far as I know, there's no
   weak type hinting; if a method signature hints for an array and is
   given an integer, it throws a catchable fatal error. Therefore, as a
   user, what I am familiar to is a strict _type hinting system_.
   Anything else would feel inconsistent to me.
 
 I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
 array(123) so introducing different meaning for scalar types feels
 very very wrong.

 You're ignoring one simple fact - in PHP, scalar types are
 interchangeable.  Unlike array-scalar which has always been a corner
 case and a sketchy one (and I said numerous times that had I rewrote
 the language now, array-scalar conversion would have probably
 resulted in an error) - string-number, number-string,
 string-boolean conversions are a cornerstone of the language.  If
 you don't like the fact that PHP's scalar types are interchangeable -
 you're in the wrong language!

 In terms of consistency, the difference between array type hinting
 and scalar type hinting you allude to is negligible in comparison to
 the inconsistency with, well, just about every other part of the
 language - operators, control structures and built-in functions
 (expecting sqrt(64) to fail, since sqrt() expects a
 number?  expecting if (7) to fail, since it expects a
 boolean?).  Auto-converting type hinting extends the same semantics
 available to internal functions (through zend_parse_parameters()) to
 userland functions.  That consistency is by far the most important IMHO.

 Zeev

 I have to largely agree with Zeev here.  I'm not an internals developer but I
 do write a lot of widely used framework-ish open source PHP.

 The current OO type specifying system I have always mentally viewed, and most
 people I know seem to view it, as a check not for is this an X, but can I
 treat this as X without things exploding?  In the context of an object,
 exploding would mean a method not found fatal.  In the context of an
 array, it would be the dreaded parameter 1 to foreach() is not an array.
 The idea is two fold: One, better documentation (especially for code
 assistance IDEs), and two, if it's going to explode it should explode in a way
 that's useful in terms of where it exploded.  (Vis, the error message is on a
 useful line and tells me what the actual problem was.)

 For scalar types, exploding would mean loss of precision.  There is no loss
 of precision in converting 5 to int(5), so that doesn't explode, nor should
 it.  There is similarly no loss of precision converting from int(5) to
 float(5), so that also shouldn't explode.  123abc does have a loss of
 precision (data would get lost in the conversion) so that should fail both int
 and float checks.

 If anything, I'd be even more forgiving than the table in Zeev and Lukas' RFP.
 float(12) converting to an int doesn't have any precision loss so I don't 
 think
 that should fail.

 The RFP includes a variety of good reasons why a more naive strict check is
 inconsistent to the point of making it a bug rather than a feature.  One in
 particular I want to call out: Everything that comes back from a database does
 so as a string.  To wit:

 table users(user_id, name, pass, blah);

 $user_id = $pdo-query(SELECT user_id FROM users WHERE name='bob' AND
 pass='foo')-fetchColumn();


 doStuff($user_id);

 function doStuff(int $user_id) {
  // Whatever.
 }


 The above code will fail with the current implementation, even though we know
 for a fact that user_id is integer data because that column is an int in the
 database itself.  Requiring an extra blind (int) stuffed in there is 
 pointless,
 and if anything just trains people to blindly cast data without thinking about
 what it really is.  I can see that introducing more bugs than it avoids.

 --Larry Garfield


+1

Regards
Peter

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Obscure token name

[Peter Lind]

On 29 April 2010 15:42, mathieu.suen mathieu.s...@easyflirt.com wrote:
 Steven Van Poeck wrote:

 Folks, can't you just accept that T_PAAMAYIM_NEKUDOTAYIM is intended to
 make you smile?  There's nothing to see here, please move along.

 - Martin

 +1

 Don' t you read what I say?

I'd be surprised if they haven't read it. My guess: they just don't
care because it seems you're kicking up a fuss about very little -
i.e. you're whining because you had to google.

If only all problems were as small as that.

Regards
Peter

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] A critique of PHP 6

[Peter Lind]

On 21 April 2010 11:46, Adi Nita adi.n...@gmail.com wrote:
 I cannot agree with the idea of preferring
 working applications to good working applications.

Except that's not what's at stake. The application does not become one
bit better or worse by using an updated function that's more
consistent with other functions. The *language* is what might become
better or worse by the change, not any applications. The *side-effect*
however, is that you're forcing incredible amounts of developers to
fix code if they want to move it to a newer version of PHP. With the
risk of having tons of code break or just never migrated to newer
versions of PHP with all the problems which that creates.
 A better option would probably be to introduce functions that
essentially do exactly the same as the old ones but consistently with
the other functions. Then deprecate the old functions slowly - no
instant BC break and people can migrate to the new proper functions in
good time.

Regards
Peter

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Assign array with __get

[Peter Lind]

Have you considered that perhaps you're trying to use the wrong
language for what you're doing? PHP does what it does now consistently
(in this regard) - what you're suggesting breaks that consistency. To
gain what, exactly?

On 19 March 2010 17:07, mathieu.suen mathieu.s...@easyflirt.com wrote:
 Right I could work around the issue with the return by reference without any
 problem.
 I am still thinking that if you try to write a meta-circular interpreter you
 gonna work very hard
 to make this subtleties worked. And according to Shriram Krishnamurthi in
 his textbook PLAI:

  a truly powerful language is one that makes it easy to write its
 meta-circular interpreter.

 -- Mathieu Suen



 Ionut G. Stan wrote:

 I guess what Mathieu is trying to say is that this:

    class Foo
    {
        public $bar = array();
    }

    $foo = new Foo;
    $foo-bar[3] = 1;

    var_dump($foo);




 ...is inconsistent with this:

    class Foo
    {
        public function __get($property)
        {
            if (! isset($this-$property)) {
                $this-$property = array();
            }

            return $this-$property;
        }
    }

    $foo = new Foo;
    $foo-bar[3] = 1;

    var_dump($foo);




 ...or even this:

    class Foo
    {
        private $bar = array();

        public function __get($property)
        {
            return $this-$property;
        }
    }

    $foo = new Foo;
    $foo-bar[3] = 1;

    var_dump($foo);


 Now, I'm not really sure this is that bad, as there may be use cases where
 one would like to return different values every time __get is called. And,
 as I wrote in a previous email, there are ways to work around this
 inconsistency by using return by reference, so everybody can be happy. I
 think.



 On 3/19/10 4:56 AM, Etienne Kneuss wrote:

 On Thu, Mar 18, 2010 at 5:47 PM, mathieu.suen
 mathieu.s...@easyflirt.com  wrote:

 Peter Lind wrote:

 On the contrary, it's quite obvious what's going on. In both examples
 __get() returns an array as PHP would normally do it (i.e. NOT by
 reference) which means that if you try to modify that you'll end up
 modifying nothing much. However, in your second example, the point at
 which you call __get() indirectly comes before the assign to the zork
 array - hence, the $this-zork['blah'] = 'blah'; no longer indirectly
 calls __get as object::$zork now exists.

  In other words, this is down to you confusing passing a variable by
 reference and passing it by value: PHP normally passes arrays by
 value, so when __get() returns an array, you're working on a copy of
 the array you returned. As someone noted earlier, you can easily
 change the behaviour of __get to return variables by reference, should
 you want to. However, I personally wouldn't want this to be default
 behaviour as that would make debugging apps much more annoying -
 things should be consistent, even if consistency at times confuse
 people.

 Regards
 Peter








 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Assign array with __get

[Peter Lind]

 I think there is a lot  to say why is not working but just look at those
 2 execution:

  1st
 class A
 {

        public function __get($name)
        {
                $this-$name = array();
                return $this-$name;
        }

        public function test()
        {
                $this-_zork;
                $this-_zork['bar'] = 67;
        }
 }

 $a = new A;
 $a-test();

 var_dump($a);
  2nd
 class A
 {

        public function __get($name)
        {
                $this-$name = array();
                return $this-$name;
        }

        public function test()
        {
                $this-_zork['bar'] = 67;
        }
 }

 $a = new A;
 $a-test();

 var_dump($a);
 


 Adding something that don't have side effect make the side effect
 work (more or less)
 You almost have to know how the VM is implemented in other to know what
 is going on.
 Nothing is obvious.


On the contrary, it's quite obvious what's going on. In both examples
__get() returns an array as PHP would normally do it (i.e. NOT by
reference) which means that if you try to modify that you'll end up
modifying nothing much. However, in your second example, the point at
which you call __get() indirectly comes before the assign to the zork
array - hence, the $this-zork['blah'] = 'blah'; no longer indirectly
calls __get as object::$zork now exists.

 In other words, this is down to you confusing passing a variable by
reference and passing it by value: PHP normally passes arrays by
value, so when __get() returns an array, you're working on a copy of
the array you returned. As someone noted earlier, you can easily
change the behaviour of __get to return variables by reference, should
you want to. However, I personally wouldn't want this to be default
behaviour as that would make debugging apps much more annoying -
things should be consistent, even if consistency at times confuse
people.

Regards
Peter

-- 
hype
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
/hype

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php