Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Date: Tue, 16 Oct 2012 12:01:04 -0400
Message-ID: <CAAyV7nE1ggsa+EXVxuoChNWtvE_rTzFdYd3+P-1DWxm+qEiaFQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e0cb4efe301cdfdfbf04cc2f427d
Subject: Lester's Comment (was Property Accessors v1.1)
From: ircmaxell@gmail.com (Anthony Ferrara)

--e0cb4efe301cdfdfbf04cc2f427d
Content-Type: text/plain; charset=ISO-8859-1

Lester,

But a vote NOT to include it should still be one of the options!
>

No it should not.

Comments like this are not helpful, and are quite destructive. Please stop
running that circle.

As far as the particular implementation goes, I'd vote against it right
now. Not because it's bad, but because it's immature. The best way to get
the idea mature is constructive conversation and implementations. That's
what's going on here. And that's what should be happening.

Your comment does nobody any good. To be honest, neither do the rest of
your comments. Please realize that we should be constructively encouraging
conversation. Let the conversation generate a concrete proposal, then
discuss that for inclusion. But your post and position is not constructive.
Please stop.


I'm sorry if people are spending a lot of time trying to make something
> work, but that is their choice, and should not be a reason to include
> something.
> I still don't see how this improves anything when all we need to be doing
> is managing the existing variables, arrays and objects stored in the
> object. __get and __set aren't needed either but that is another matter.
> Does anybody actually use them, or are they waiting for the 'better
> alternative'?
>
> Is there any real reason not simply to be using $obj->var ? It is the
> fastest way of doing it anyway ...


If you don't understand the problems with $obj->var, then perhaps you
shouldn't contribute to a conversation that's this early. The RFC hasn't
been proposed. It's still evolving. Save those questions until the
proposers feel it's ready. And to be fair, if you don't understand the
problems with public variables, then you really don't have much room to be
commenting (or voting) on OOP design decisions.

I'm sorry if this seems to be attacking you, but it really is. Your
presence lately has been very damaging and demoralizing. Not once have you
proposed or commented in a constructive way. Everything with you "is a
problem". So please, either be constructive, or simply don't post. This
list has a bad enough history of destructive criticism...

Anthony

--e0cb4efe301cdfdfbf04cc2f427d--