Re: [PHP-DEV] The real world ...

[Dustin Wheeler]

On Thu, Jun 13, 2019 at 9:36 AM Marco Pivetta  wrote:
>
> You'd still see the DSN in the traces.
>

My understanding is that if using pdo.dsn.mysql via INI, you wouldn't
see the username / password in traces. I only learned about this
configuration reading through Sjon's PR, but looks reasonable.

To the original issue Lester faces:

The crux of all this is "don't use exceptions to do customer support"!

Most, if not all, log aggregation software (Splunk, ELK-stack, etc.)
give you the ability to configure dashboards or reports to highlight
different levels of "fail-boat" in the environment. We do this in our
environment, which is very heterogeneous and uncontrolled; filled with
undergraduates, graduates, faculty, staff, other IT organizations and
everything in-between. Not only do I have to deal with *my* logs, but
I also have to help facilitate improvements to tenant applications. If
it were me, I would be looking to your system administrators to
improve the configuration and management of your application
monitoring. If you don't have any automated monitoring (Splunk or ELK
(free), Telegraf/InfluxDB, Nagios even), look into these things.
Configure these to solve this problem rather than having customers be
the "free" monitoring solution as a default.

If I tried to pitch to my team that we would just use our users as THE
monitoring solution, I'd not only get some strange looks, but also a
can of surströmming thrown in my face. As developers and system
administrators, we can do better by our users to prevent these types
of errors before they hit them. We can do this through improvements to
our software design life cycle (or, to keep it simple... write tests
and develop somewhere other than production). Ultimately, we're never
going to catch everything... but customers reporting literal
exceptions should be... exceptional :)

P.S. I fully understand the "real world" sentiment even if I perceive
a different reality than yours. In the "real world", people get set in
their ways and higher-ed is no better a place that I have found to
observe this. However, in my experience, even the saltiest of faculty
with their 50 year old "Fortran codes" are amenable to change if it
makes their lives easier. Applying some of these strategies *will*
improve quality of work-life and *will* improve your business. Having
customers report low-level exceptions / stack-traces cannot be "good
for business" and must lower confidence in the product.

Cheers,

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] PHP header files, restrict to declaring code only

[Dustin Wheeler]

On Fri, May 10, 2019 at 9:15 AM Lynn  wrote:
>
> 2. Certain features, can be restricted to php-header files only, meaning it
> does not affect
>"normal" PHP files. This might open up a whole new range of syntax
> possibilities that
>are currently blocked, such as `@trigger_error()` vs `@Annotation()`.
>

Hi Lynn, thank you for opening this discussion!

Could you explain how the range of syntax you suggest (regarding
annotations) is currently blocked? I'm not challenging your claim; I
*personally* don't know and am interested. While certainly not
supported natively, comment-based "annotations" can be implemented in
user-land and processed via reflection (See doctrine-annotations[1]).
There has also been previous work and discussion in the annotation
space [2][3][4][5]. Based on my light reading, I couldn't find any
objections to annotations with side-effects, but I could see that as
an argument. However, I'm more curious what your perspective is.

Personally, I really like the idea of being able to declare
"side-effect free" as a feature. I don't know if I prefer the idea of
a `phph` file, distinguished by extension (so I'm glad you mention
alternatives such as `declare`). That said, I think that's mostly from
shock and not wanting to ever go back to a world that included *.php4,
*.php5, *.phtml, etc. :)

Hope all is well,

1: 
https://www.doctrine-project.org/projects/doctrine-annotations/en/latest/index.html
2: https://wiki.php.net/rfc/annotations
3: https://externals.io/message/82813
4: https://externals.io/message/64895
5: https://externals.io/message/64722

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

[Dustin Wheeler]

On Thu, Apr 11, 2019 at 1:48 PM M. W. Moe  wrote:
>
> @Benjamin Morel
>
> you must certainly have basic comprehension troubles; read me back; it is
> public; keep for yourself your
> emotional false projections to myself and infantile behaviors to yourself;
> I would never dare simply by following
> the basic rules of education; maybe english grammar should introduce a
> point of `ironism`; would help or not.
>
> You have a good day; thank you.
>

Hello internals,

I am ALL for academic discourse and constructive criticism. This value
system has gotten many folks far in life and produces a better
product, which I know we all want. However, mo.mu@gmail.com's
behaviour on this list is not the type of academic discourse or
constructive criticism that inspires individuals to contribute and
share their knowledge, in my opinion.

mo.mu@gmail.com: could you please temper your language to consider
that a human is on the receiving end of your comments. Could you keep
your comments within the realm of the RFC discussion-at-hand and away
from personal or hyperbolic illustrative language? This RFC is really
straight-forward and really, really well documented, prepared and
presented. I perceive your hyperbole as a disrespect to the time of
contributors to the project and to this thread. Please, temper your
language.

I hesitate to single you out (as there are other non-ideal behaviours;
certainly on this list, but particularly in this thread), but in my
opinion, you are the individual with the power to bring us back to a
productive discussion.

Thanks!

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] Re: Password

[Dustin Wheeler]

> On Jul 17, 2018, at 5:08 PM, Christoph M. Becker  wrote:
> 
>> On 17.07.2018 at 20:38, Solovov Dmitry wrote:
>> 
>> Can I set a new password for my account?
>> 
>>  https://wiki.php.net
> 
> Did you try ?
> 

I don’t mean to hijack but I don’t have the ability to change my wiki password 
so I’ve just kept the one that was generated so log ago in a password manager. 

I would also like to change that password but do not have permissions to manage 
that aspect of my wiki account. 

Perhaps Solovov is in the same boat?

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

[PHP-DEV] Re: [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Fri, Jul 6, 2018 at 4:24 PM Dustin Wheeler  wrote:
>
> I would like to open the vote for an RFC to support Class Friendship in PHP:
>
> https://wiki.php.net/rfc/friend-classes
>
> The vote ends 2018-07-13 21:00 UTC.
>

Hello,

The RFC for Class Friendship failed to meet a 2/3 majority approval
and has been declined.

I appreciate everybody's time and consideration!

Thanks,

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

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

[Dustin Wheeler]

On Tue, Jul 10, 2018 at 1:43 PM Sara Golemon  wrote:
>
> On Tue, Jul 10, 2018 at 9:26 AM, Dustin Wheeler  wrote:
> > That said, if feature freeze for a release is announced well in
> > advance, published,
> >
> Depends on what you consider a proper announcement[1], but it is
> published[2] and the date can reliably be expected to occur around
> mid-July until and unless we change the GA date (FF is 18 weeks and 2
> days prior to GA, GA in turn is approximately 4 weeks before
> Christmas).  I'll admit that the publishing of the 7.3 timeline came
> very late this year and that's on myself and Remi.  The RM selection
> process should have started two months earlier than it did.
>

Yeah, I worded that pretty terribly. I should have put a parenthetical
after that if statement. Agree 100% on adequate annoucement.

> > and there was an agreed "best intentions" policy
> > to not submit RFCs that encroach on that date,
> >
> I had hoped there already was an agreement on this.  Seeing the SIX
> currently in voting makes me doubt that understanding is shared (okay,
> in fairness, Class Friendship isn't targeting 7.3).
>

Class Friendship is currently targeting the trash! :P

> > That, or subconsciously, the talk of a new version of
> > PHP sparked folks to get off their ass and put forth their ideas! :P
> >
> That's very likely a contributing factor, especially with talk of 7.4
> being deprecations focused (something I'm finding myself agreeing with
> less and less over time).  This isn't new to this year though, even if
> it's been less pronounced till now.
>

I'm relatively new to all of this. I think it's a bit strange to
earmark a minor release as deprecation-only, but I also wasn't around
for the last major upgrade to see discussion (was 5.6 the focus of
many deprecations?)

It can be frustrating, but I really like to see humans conversing and
finding flexible solutions for the greater good (which is already
happening here). Perhaps there is a reasonable way to document /
communicate the shared understanding that "sending new RFCs to a
release that's so close to feature freeze that it's questionable
whether voting will end in time" is bad form. Having a parenthetical
that covers "exceptional work" could also address situations like the
property types RFC, which ... not to minimize ANY other work on-going
... is in my opinion, worthy of such an exception.

Where would be a good place to document that? https://wiki.php.net/rfc/howto?

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

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

[Dustin Wheeler]

>
> We don't need to solve this now, this week, because there are plenty
> of rushed, last-minute proposals on the table already.  But I'd like
> folks to start thinking about this and ways we can mitigate this
> problem come future releases.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I agree with Sara. This is definitely a worthwhile discussion and the
issue probably puts additional stress on RMs that may be easily
avoided.

Personally (for Class Friendship), I opted to target either 7.4 or 8.0
(whichever was decided to be next-in-line; but *specifically NOT* 7.3
due to more important discussions happening at the moment. So I think
there's some "personal judgment calls" to make for folks submitting
RFCs.

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

Just my 2c, FWIW

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki  wrote:
>
>  I would like to vote to "yes".
> However, RFC does not have benchmark result. Do you have some results?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Yasuo,

I have documented a benchmark based on my last comment. This benchmark
could be improved through larger sample size but it looks like there
is little to no difference in performance between the two. The result
I determined with a sample size of 100N was a 0.000425905 second
difference between `master` and `feature/friend-classes-poc` (friend
branch was slower by that delta).

My experiment is documented at
https://gist.github.com/mdwheele/e4dce7adb7a4f523011c21de6b29f001.

Thanks,

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Sat, Jul 7, 2018 at 6:46 PM Yasuo Ohgaki  wrote:

>
>  I would like to vote to "yes".
> However, RFC does not have benchmark result. Do you have some results?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
I have not run a benchmark on the current implementation but would be happy
to (and also attach that to the results of the RFC, pass or fail). Since
there really isn't a good way to test this exact behaviour against master
(since it doesn't exist), do you have any ideas for a reasonable benchmark?
The only added clock time should be attaching "friended" classes to the
"friending" zend_class_entry and an additional runtime check for
`protected` member access. What about the following:

For master (control):

```
class Readable {
  public $property = 'foo';
}

class Reader {
  public function read(Readable $object) {
echo $object->property;
  }
}

$readable = new Readable();
$reader = new Reader();

// Time the following...
for ($i = 0; $i < 1; $i++) {
  $reader->read($readable);
}
```

For RFC (experiment):

```
class NotReadable {
  friend Reader;

  protected $property = 'foo';
}

class Reader {
  public function read(NotReadable $object) {
echo $object->property;
  }
}

$not_readable = new NotReadable();
$reader = new Reader();

// Time the following...
for ($i = 0; $i < 1; $i++) {
  $reader->read($not_readable);
}
```

If you have any better idea, let me know and I can move forward. Also, if
there is some "standard" benchmark you'd like me to run, please let me know.

Thanks!

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get
there."

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

On Sat, Jul 7, 2018 at 12:09 PM Niklas Keller  wrote:
>
> Hey,
>
> could you please fix the creation date in the RFC? It lists
> 2018-06-27, which would mean that the minimum discussion period
> wouldn't be over, yet, but it's actually been created somewhen last
> year.
>

Ugh, sorry about that! In my rush getting the voting doodle in, I
updated the date as well as a matter of habit.

I've updated the date to 2017-09-21, which was the date I considered
the RFC text finalized. For completeness, the last call for discussion
was almost 9 months ago [1].

1: https://externals.io/message/100743

Thanks for the heads up!

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] [RFC] [VOTE] Class Friendship

[Dustin Wheeler]

Hello,

I've let this RFC linger for a long time and finally wrapped up the
remaining administrative items to put it to vote. This has been
discussed a few times in the past:

https://externals.io/message/89732
https://externals.io/message/90311

I would like to open the vote for an RFC to support Class Friendship in PHP:

https://wiki.php.net/rfc/friend-classes

The vote ends 2018-07-13 21:00 UTC.

Thank,

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] PHP 8 next?

[Dustin Wheeler]

Hello, 

> On Jun 23, 2018, at 6:38 PM, Alice Wonder  wrote:
> 
>> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
>> 
>> This is slightly earlier than I intended to bring it up but I do too think 
>> that the next version beyond 7.3 should be 8.
> 
> I disagree.
> 
> I'm mostly a user, not a PHP developer.
> 
> RHEL 7.5, the latest version of RHEL, still ships 5.4.
> 

RHEL has official software collections for PHP 7.0 and 7.1. Remi has an SCL for 
7.2. We run 7.2 in production and 5.6 is gone in December. 5.4.16 in RHEL 
was... a mistake. There is nothing “un-enterprise” about the SCLs and they work 
very well. 

RHEL 8 is coming soon and is based on Fedora 28. It will likely ship 7.2, I 
imagine. 

> Other LTS distributions also probably ship 5.x.
> 

Ubuntu 16.04 LTS shipped with PHP 7.0. Ubuntu 18.04 LTS ships with PHP 7.2. PHP 
5.* was a great line but it has been time to move for a while. It’s getting 
harder to come up with reasoning to stay. I haven’t come across a codebase that 
didn’t run on 7+ and this includes a 16 year old codebase that started on PHP 
4. It’s an anecdote, but proof that anything is possible. 

> So a major version bump now would mean three major versions of PHP that web 
> applications intended to "just work" on enterprise *nix would have to support.
> 

For sure, this is the distribution’s choice, not the maintainers here. 

> If there was a major design flaw in PHP that can only truly be fixed by an 
> incompatible version bump past 7 then do it but otherwise, I think it would 
> be better to wait until the most recent versions of enterprise distributions 
> have moved to php 7.
> 
> I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
> 
> The issue is some customers of enterprise linux specifically don't want 
> frankenstein systems and want to use vendor supported packages only, and I 
> can see their point of view because they pay a lot of money for that support.
> 
> That being said, I try to get everyone running old PHP up to 7.1 or 7.2 even 
> if it means frankenstein systems. But some think the benefit of enterprise 
> vendor support outweighs the improvements in PHP.

I have Puppet to manage LAMP using httpd24 and php72 on RHEL if you’re 
interested. Once it is in config management, it’s not “Frankenstein” anymore. 
And if folks complain about “Frankenstein” systems when their definition of 
such is using software collections, I would argue their not getting value out 
of the product provided by RedHat, as SCL versions of PHP are provided by the 
vendor! Use them!


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

Re: [PHP-DEV] Mailing list moderation

[Dustin Wheeler]

On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison <le...@php.net> wrote:
>
> I doubt we have any official procedures. I agree with the proposed
> suspension as long as the suspension for a set amount of time; I
> believe in giving people a chance to reform. If they can't reform...
> well then I'm fine with an indefinite suspension.
>

I, too, would be in favor of suspension over outright ban, simply
because I have never seen such a ban happen on this list. It saddens
me that, rather than focusing on rigorous discussion, many RFC
discussions are completely sidetracked the moment a topic comes up
that might encroach on either of these individual's "ego" (I temper
language, but agree with Nikita's characterization).

There are, indeed, nuggets of truth in contributions both
li...@rhsoft.net and tonymars...@hotmail.com have made. Both have
legitimate concerns and points of view. Unfortunately, it is on the
reader to decipher that from the "ego" measuring that happens every
time they start one of their back-and-forths.

I hope we can do something about this sooner rather than later. I,
myself, refuse to explicitly censor communication from the list based
on who's talking and I *DO* value both of their opinions and concerns,
but this behaviour has been observed many times with several folks
on-list asking for some professionalism in communication. There must
be some form of consequence, I feel.

Thanks.

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Dustin Wheeler]

> 
> On Dec 31, 2017, at 10:33 AM, "li...@rhsoft.net"  wrote:
> 
> 
> 
>> Am 31.12.2017 um 11:27 schrieb Tony Marston:
>> "Michael Morris"  wrote in message 
>> news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dnbswf9csuyntyn8x...@mail.gmail.com...
>>> 
 On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine  wrote:
 
 
 Not being able to vote, many of us have no option to complain about the
 way things are going. Currently there seems to be several styles of PHP
 form the nice and simple untyped version I moved to from very strictly
 typed hard compiled code I'd been using up until then, through to
 current code which is reliant on third party things like PSR and
 Composer and expects only strictly typed PHP.
>>> 
>>> This is born of the fact that while ignoring datatype makes learning PHP
>>> easier, it makes using it harder - especially when testing.
>> I strongly disagree. I have been using PHP since 2001 and I have never used 
>> type hinting in any form whasoever. Does it make testing more difficult? No, 
>> it does not
> 
> "I have never used type hinting in any form whasoever" - so how can you be 
> qualified at all to tell anything about the difference how it would be if you 
> would have used it?

Could the discussion be re-centered around the RFC at-hand rather than 
measuring "ego"? It seems that any thread that has both rhsoft and Tony 
involved devolves into a competition of opinion without much attempt to meet in 
the middle or understand one another. 

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

[PHP-DEV] [RFC] [Discussion] Class Friendship in PHP

[Dustin Wheeler]

Hi!

Almost two years ago, I opened discussion regarding my proposal to support
class friendship through a new keyword, `friend`. For a number of reasons
(mostly work-related; some personal) I didn't have time to move the process
forward. There were several hot-topic discussions going through the mailing
list at the time that I believed deserved more attention. I feel that my
RFC was ill-timed, perhaps. That said, we're almost two years into the
future!

I would like to re-open discussion of my RFC and get it to vote
appropriately soon.

In the previous discussion, there was on-going work to introduce
package-private classes by Guilherme. As far as I can tell that work is
stalled, pending fundamental changes to how namespaces are implemented in
PHP (https://github.com/php/php-src/pull/947#issuecomment-224912697). Like
many others, I am very excited for the possibility of package-private
classes or namespace visibility features of any kind. Even so, my personal
vision of that landscape includes class friendship as a unique, explicit
and concise expression of tight-coupling between object-oriented
collaborators. I do not feel these efforts are either-or. I believe they
both contribute to a more expressive means of specifying the relationship
between collaborators with regard to visibility.

The RFC is at:

https://wiki.php.net/rfc/friend-classes

I need to rebase my implementation against `master` and send a PR. I will
have that done before voting begins as it includes several test cases and I
would appreciate additional perspectives to catch edge-cases I may not have
thought of. The implementation was quite straight-forward.

Thanks!

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get
there."

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[Dustin Wheeler]

Hi, (accidentally replied to only OP)...

> On Sep 15, 2017, at 1:35 PM, ilija.tov...@me.com wrote:
> 
> Hi Marco
> 
> I can see it’s usefulness in this case.
> 
> But wouldn’t it be better to implement this by hand in these rare cases (it’s 
> 3 lines of code) instead of encouraging the pollution of the symbol table by 
> unknown input? It’s also clearer since people who don’t know the `extract` 
> function probably don’t expect it to mutate the local symbol table.

This argument is predicated on the assumption that my input is unknown. This 
assumption is not universal to all codebases as implied. 

There are many "foot guns" in every language and framework. I don't think it is 
necessary (or wise) for the language to assume responsibility for abuse. 

This is the same line of reasoning that could be used to justify removing 
serialize/deserialize because a developer could "accidentally a tent" or we 
could build safer options into the feature (as you've already described)

Just my 2c

Re: [PHP-DEV] [RFC] Match expression

[Dustin Wheeler]

On Sun, Sep 10, 2017 at 4:18 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> The choice of "use" as the keyword was largely because it's already a
> reserved word, with multiple meanings in different contexts. As well as
> anonymous functions, it's the keyword for importing names from other
> namespaces, and for including a trait into a class. I would be perfectly
> happy to hear alternative keyword or syntax suggestions.
>

FWIW, within the scope of the suggested "switch-use" feature, I think
that the "use syntax", as suggested by Rowan, feels appropriate. I
agree with the usage based on it already being reserved and used
differently per-context. Additionally, the syntax feels natural and
expresses intent well-enough. All that said, I feel that some form of
strict-switch would be more immediately applicable to a wider
audience. In that regard, I prefer the keyword approach "strict switch
(...) { ... }" rather than using an additional parameter "switch($x,
true)".

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle

[Dustin Wheeler]

Hi Lester,

>
> Currently having followed the installation guide I have things working
> on a home directory. This is probably what people expect today, but I
> still expect tools to be available which ever login I use ... testing
> different client profiles.
>

There are a few options, as I'm sure you're aware, haha. By default,
global requirements are going into the executor's home directory.
However, you can configure all of those paths at run time. My advice
(if you cannot (or simply prefer not to) install these types of tools
per-application) would be to configure those paths to point to some
global space in (what I presume is a) shared development space where
it makes sense to have these tools installed globally (phpcs, phpunit,
etc). Then you would have the task of making sure that global bin-path
is in each users environment when they log in.

However! (and I don't know if this is "best practice" or whatever) ...
you *could* decide to specify bin-dir to be some UNIX / Windows path
that is in environments by default. The risk here is that you collide
with pre-existing binaries / symlinks (which is a trade-off to global
installations in general). Let's see what we can do...

```bash
# For purposes of demonstration, I'm doing this as a user that can create
# directories in /opt and can create and execute files in /usr/local/sbin
# I wouldn't do this as root, I'm just lazy...
$ sudo su -
$ whoami
root

# Arbitrarily decide to install here globally
$ mkdir /opt/composer

# Tell composer where to install dependencies
$ composer global config vendor-dir /opt/composer/vendor

# Tell composer where to put "binaries" (symlinks)
$ composer global config bin-dir /usr/local/sbin

# Verify our settings "took"
$ composer global config --list

[vendor-dir] /opt/composer/vendor
[bin-dir] /usr/local/sbin

# Note that there are other paths that should probably be specified
(where caches are stored, etc)
# In this example, Composer's global config is in-fact in root's home
directory. Caches are in root's
# home directory. This may or may not be acceptable, but is definitely
configurable to whatever you want

# Install PHPCS globally and cross fingers >_<
$ composer global require squizlabs/php_codesniffer

# Drop elevated permissions
$ exit
$ whoami
vagrant

# Try to use PHPCS out of my home directory with no special pathiness...
$ which phpcs
/usr/local/sbin/phpcs

$ phpcs --version
PHP_CodeSniffer version 2.7.0 (stable) by Squiz (http://www.squiz.net)
```

In this way, you *can* install composer "binaries" to a global
location that is accessible by default by normal users on your system.
This was done on a CentOS 7 machine, but I am positive this can be
equivalently applied to Windows or any environment, really.

I'll admit that most folks (it seems, anecdotally) have gone the way
of installing these development tools per-application using
`require-dev` but I completely understand where you're coming from. I
just wanted to show you what's possible.

I hope this helps, Lester.

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] Class Friendship

[Dustin Wheeler]

iscovery in a domain might grant clarity that you've actually modeled
a conflation of ideas. In other cases, you might just have a case
where the abstraction *is* correct, but the API serves two concerns
(read and write, query and command). In these cases, you grab for
friendship as a means of expressing physical separation of concerns of
the command and query portions of a given object. Taken further, CQRS
(command-query responsibility segregation) expresses totally
segregated models for reads and writes across a system.

> When middle names are added to the Person object,
> the HumanResourcesReport will continue to generate full names as it
> has always doneuntil someone notices a files a bug report.

This would be a misstep modeling and failure in testing, in my
opinion. Granted, again, that this is an intentionally trivial example
so the argument will by extension seem trivial.

Keep in mind, that in this example Person might represent solely the
business rules and invariants of what it means to be a Person.
HumanResourcesReport is a separation of concerns describing what a
Person looks like in the domain of human resources. They are truly
separate concerns. In this way, I would argue that simply the addition
of middle name as an invariant of Person does not imply that it would
be incorrect (or a "bug") for the report to continue generating full
name as it always had. This is an advantage of friendship, not a
failing! Can it be abused? Of course!

The tests for HumanResourcesReport should dictate when it's time to
change behaviour of that query. Imagine if, instead, Human Resources
says, "We like what we see in the report, but we're now required by
law to include middle names as part of the full printed name.". We'd
write a test for the friended class to add this behaviour and that
would influence changes that might (or might not) need to be made on
Person.

>
> Apologies again for being so negative.
>

No need to apologize! I appreciate the feedback and look forward to
continued discussion. Good stuff!

Thanks

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] Class Friendship

[Dustin Wheeler]

or
this RFC. I'll remove the additional voting choice.

>
> Well, I hope you won't get me wrong, I'm just trying to help and that's only
> suggestions. That's your RFC, your work, your decisions. Anyway, that's a
> very good work and I hope it will be approved.
>

François, I very much appreciate your suggestions and look forward to
discussing this more.

Thanks,

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] [RFC] Class Friendship

[Dustin Wheeler]

Dan,

On Thu, Jan 7, 2016 at 10:21 PM, Dan Ackroyd <dan...@basereality.com> wrote:
>
> FYI The voting RFC is reasonably clear on new syntax and the passing
> level: https://wiki.php.net/RFC/voting#voting
>
> "For these reasons, a feature affecting the language itself (new
> syntax for example) will be considered as 'accepted' if it wins a 2/3
> of the votes."
>

Thanks for clearing that up. I'll leave this part of voting choices as-is.

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] [RFC] Class Friendship

[Dustin Wheeler]

Hello everyone,

Before Winter holiday, I began a discussion on the mailing list
regarding the topic of class friendship in order to gauge interest
towards authoring and implementing an RFC for the feature. This
discussion happened at:

https://marc.info/?l=php-internals=144954699701305=2

I have drafted an RFC that describes a proposal to add this feature to
the language. I feel like this draft is at a point where it is
reasonable to invite additional perspective and begin the discussion
process. While the RFC does capture advice I received in the original
discussion, it does not capture as much of the justification /
reasoning behind the feature as I felt that the RFC should present the
facts of the proposal. Because of this, I urge you to read through the
original discussion before reviewing this RFC. It is also included as
the top reference for the RFC. If we feel this information is relevant
to the RFC document itself, I would gladly amend.

https://wiki.php.net/rfc/friend-classes

I will be submitting a pull request against `master` soon so that
progress and changes to implementation may be tracked for the duration
of RFC discussion. There are a few details I need to iron out in the
implementation that surfaced as part of initial discussions.

This is my first contribution to PHP and it is more ambitious that I
am normally comfortable with when making contributions to open-source
software. That said, I fully recognize and respect the expertise of
developers on this mailing list and welcome scrutiny as far as
technical implementation. I am 100% ready and willing to accept all
feedback to improve implementation where necessary.

Finally, as mentioned in the original discussion:

When I began this work, I found that (for a beginner) the
barrier-to-entry in contributing a new feature to PHP is fairly
substantial. While there were several good references for implementing
a feature such as this, much of it was out-of-date; considering the
changes made internally for PHP 7. I would like to contribute notes I
took while working through this project that begin to detail common
differences in how someone might accomplish a feature like what's
represented by this RFC for PHP 7. This feature was unique in that it
has a fairly simple and light-weight cross-cutting implementation that
seems like a decent example for a newcomer.

Is there a good place for me to send this information for review? Is
another RFC a good medium for review or would a separate post to the
mailing list suffice?

Thanks again for your time and I look forward to upcoming discussions!

-Dustin

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Dustin Wheeler]

Hi, chiming in from the side,

On Tue, Jan 5, 2016 at 12:45 AM, Sara Golemon <poll...@php.net> wrote:
> Forwarding a suggestion twitter/@Beryllium9:
>
> How about a global "disable error suppression" setting?  That way a
> project lead could enforce it for their codebase (and guarantee that
> devs "aren't lazy"), but PHP doesn't lose its pragmatism?
>

I think this is an excellent compromise worth discussion and can vouch
for usage of this suggestion in our environment, today. I maintain a
shared hosting environment of sorts and have many different developer
groups working in that environment. This is the sort of configuration
we would take advantage of immediately.

Thanks twitter/@Beryllium9 (wherever you are!) + Sara,

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] Wiki RFC karma request: mdwheele

[Dustin Wheeler]

Hi,

I have recently continued a discussion to implement class friendship
for PHP. I would like to suggest an implementation of this feature and
discussion has gotten to the point that regular feedback can be
applied to a draft RFC and move the conversation forward.

I am registered on the wiki with username "mdwheele". May I have
appropriate karma so that I may draft this RFC?

Thank you very much!

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

Re: [PHP-DEV] Class Friendship in PHP

[Dustin Wheeler]

 an object that has
friended another, I want it to be clear and determined; the degree to
which I have coupled that object to collaborators through friendship.
Allowing `friend __NAMESPACE__` allows this to grow somewhat
unbounded; which... isn't the end-of-the-world by any means and I can
see where it could be applied. Currently, however, I see it as a
misapplication of the tool?

Haha, I apologize. I have a hard time finding concision sometimes. I
guess what I'm saying is that I am definitely not against this idea,
but that I'm not generally for it, yet. To me, it doesn't map as
cleanly to the goal of better encapsulation of behaviour in one object
through strategic tighter-coupling to another object. I'd like to hear
more of your thoughts to gain some perspective.

Would this be something you would consider being a candidate for
future development and exploration of the feature? I am already
planning to put class friendship to methods and global functions on
the list for future work. Having explicit class friendship, period,
would be a pretty awesome win and meet 80% of the use-case (80/20
rule-ish here). Having clear and identified opportunities for
continued effort to flesh out the feature is a good idea, I believe.
It's also a trade-off of making a small step in the feature to allow
it to settle while other features in this problem-space move forward.
In this way, we can be sure to stay consistent in the "spirit of
private collaborators" (if that isn't too wishy-washy to say). I only
ask this question because I think it can be misunderstood as a
substitution for more robust namespace-visibility features and
possibly devalue efforts in those directions; namely Guilherme's. I
see value in that work and think there's a bit of strategy to consider
here for the sake of language design. This particular extension is
*definitely* in the overlapping problem-space of these two modeling
concerns!

>
> For inheritance rules, you may be interested by a small article I wrote on 
> the subject (http://tekwire.net/joomla/projects/ideas/php-friend).
>

Yes! You might be delighted to know that the current implementation
adheres to these rules, exactly. I honestly don't know how I didn't
come across your article in gathering references. Are you amenable to
me adding it to my list of references?

Thanks to both of you for your comments thus far and I will be sending
a request for RFC karma to create an RFC in Draft. I have a lot of
information attached to that already that describes the feature itself
with examples, but also includes background information on the
feature's lifecycle in C++ (not to say we compare ourselves, but to
describe lessons learned from that community as far as the
implementation, maintenance and community-usage of the feature). I am
eager to continue working with you all on this.

Thanks!

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get there."

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

[PHP-DEV] Class Friendship in PHP

[Dustin Wheeler]

 use-case
here is splitting presentation concerns from what would otherwise be a
"tell don't ask" behavioral unit. This has immediate practical applications
in a variety of scenarios. Without this feature, developers are left with a
trade-off of marking internal properties public to make them available and
sacrificing design opportunities in the future under a major revision.
Another common occurrence is the addition of getters that simply proxy
internal state and grow the public API of a unit by necessity. To be sure,
this feature is not about pulling off "access to private class properties",
but about modeling a specific relationship between two collaborators. In
fact, access to private class properties is already possible through
closure scope "juggling" or nasty use of `debug_backtrace`. Both of these
are included in references below. While it is technically possible to
execute friend-like features in user-land, I would rather be able to
concisely represent the relationship with a known and well-documented
concept supported by the language.

The syntax I have implemented is very similar to `trait`. It introduces a
new keyword `friend` followed by a name_list. Here is a simple example of
syntax:
https://gist.github.com/mdwheele/6d9b178dc25ebb829e4c#file-1sample-php-L3-L14.
It feels natural and is forwards-compatible with friend functions, should
it be discussed and implemented. That brings me to one of my leading
statements: my current un-submitted RFC is only for friend classes, but
includes future scope towards implementation of friend functions as class
methods and global functions.

I want to limit the scope of the RFC for two reasons:

1. An RFC that implements friend classes affords the benefits I've
described above immediately. The RFC vote will also either prove desire for
the feature or will put-to-rest further discussion of related features.
Supporting friend functions as class methods offers tighter control over
property access by limiting access to a single method on the friend. This
IS valuable, but pales in comparison to what friend classes offer, by
default. The testing use-case would not really leverage this quality as
each test method would presumably require access to the system under test.
Expressing that tight of control isn't really something I would personally
advise as far as modeling goes.

2. It seems with recent feature additions (return types, primarily) the
syntax around class methods needs some time to settle and prove itself
before disrupting it through the addition of additional keywords. If friend
classes were accepted or folks are interested in having productive
discussion, I am definitely willing to discuss syntax options. It's just
the value-add at the trade-off of syntax disruption isn't very favorable,
to me.

I have more examples of class friendship available in the RFC but as per
documented processes want to "test the waters" so-to-say before officially
submitting an RFC draft for review. I would like to hold those for now as I
have a hard time organizing code samples via email, but am willing to
answer questions on other properties of class friendship (non-symmetric,
non-transitive, not inherited, access inherited).

Finally, it is my opinion that implementing class friendship -- as well as
considering other features in the domain of private collaborators -- opens
up new opportunities in object modeling for the PHP community and while it
not be the "next big thing", would be a welcome addition to the lovely
language that is PHP.

Thanks for your consideration and I look forward to further discussion!

P.S.: Congratulations on PHP7!

Previous discussion / related materials:

- https://en.wikipedia.org/wiki/Friend_class
- https://bugs.php.net/bug.php?id=34044
- https://marc.info/?l=php-internals=144639394529142
-
http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/

-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get
there."

Re: [PHP-DEV] Class Friendship in PHP

[Dustin Wheeler]

Hi,

Hi,
>
> My biggest concern about supporting friend classes is the ability to
> access non-intentional to be accessed code outside of the original class's
> knowledge. This by itself is very dangerous.
>

Just to clarify, the original class explicitly declares friends of itself.
There is no opportunity for friend classes to access protected members
without the original class knowing about it. It is a specific modeling
strategy used to improve encapsulation of behavior at the cost of tight
coupling between private collaborators. In addition, other properties of
friendship protect the original class from unwarranted access. The common
expression of these properties is something like: "Just because I grant you
friendship access to me doesn’t automatically grant your kids access to me,
doesn’t automatically grant your friends access to me, and doesn’t
automatically grant me access to you." In essense, it is actually a
very-safe feature and while it can be abused, surely, I wouldn't go as far
to call it very dangerous. I have seen some pretty heinous usage of traits,
but I won't condemn the feature as dangerous! :)


> I do see however package-private classes as a possibility (I actually have
> a partially running patch for that) and allowing it to access protected
> (not private) members is a second stage of my goal, so very similar to what
> your suggested, with the exception that the original class defined what can
> be accessed.
>
> Regards,
>

I see package-private classes as a separate modeling concern in the same
domain of "private collaborators", personally. While package-private
classes may be used to implement friend-like behaviors in a programming
language, they do not clearly express the core intention of friendship as a
tight-coupling between a limited set of collaborators (which may, in fact,
be members of separate packages).

To be clear, I don't want to pit two features in this domain of private
collaborators against one another. I see them as 100% separate modeling
concerns; each having its own strengths and wouldn't want to see something
as useful as package-private classes be watered down to support friend-like
behaviors because it would mean losing expression of the intent: specific
targeted coupling of a few collaborators for better separation of concerns.

Thanks for your thoughts!
-- 
Dustin Wheeler | Software Developer
NC State University
m: mdwhe...@ncsu.edu | w: 5-9786
"If you don't know where you're going, it's easy to iteratively not get
there."