Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63354
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B526F@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local>
	<5073328D.5000002@gmail.com>
	<50735165.8010703@aaronholmes.net>
	<CAEPJdu=pRSDRD68t3o7XVbWRo-FvA07Wr+bzM_bwOXkwfiMxng@mail.gmail.com>
	<CACxA8bkF0EHDs3As=kMcg-BahRfBK6A5i7B9TdRc_SweCsv23A@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local>
	<CACxA8b=wbHN_mRomH25Jr+i9BeTzj=VTGfPe_T8igjzCsMNn_Q@mail.gmail.com>
	<760ab4f994a78a846cf86aafda71e0e2@mohiva.com>
	<CALtuQzAH-=ePssPi-yUcXghpUhO6jOH4oDhDtPEFVj9bRf1VLA@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B4EFE@MBX202.domain.local>
	<9570D903A3BECE4092E924C2985CE485612B526F@MBX202.domain.local>
Date: Thu, 11 Oct 2012 23:34:24 +0200
Message-ID: <CALtuQzCPETD1XMFZ6Xh85tMsPueRqFPUdu_=fuUxbCgwXaHOFw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b62275ec66a9904cbcf5505
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b62275ec66a9904cbcf5505
Content-Type: text/plain; charset=ISO-8859-1

2012/10/11 Clint Priest <cpriest@zerocue.com>

> Rather than go to the trouble of finding a reasonable way to hold a vote
> on these issues, is there anyone against the following changes:
>
> 1) Eliminate the ability for an accessor to be called via
> $o->__getHours(), the accessor functions will be completely unavailable for
> use except as property references ($o->Hours)
>

I don't really care, but what were the concrete objections? You can call
__construct() directly too and that is similar ... not useful ^^ Assuming,
that most developers should try to avoid "unuseful stuff", wouldn't it be
more complicated to explicitly restrict the access?


> 2) Change syntax to use public set($value) { }, public get(), etc.  (and
> along with that means no more "magic" $value)

2a) If possible, allow for Type Hinting...
> 3) Eliminate automatically implemented get; set;, no automatic backing
> field creation will occur.
> 4) read-only / write-only keywords will be eliminated
> 5) Exceptions thrown from accessors will be made more appropriate (I will
> also check debug_backtrace information, etc)...
>
> If there isn't anyone against the above changes, I will make the changes
> to the RFC and re-present for final agreement...
>
> Or... do ya'll want to vote on the aforementioned changes?
>
> > -----Original Message-----
> > From: Clint Priest [mailto:cpriest@zerocue.com]
> > Sent: Wednesday, October 10, 2012 7:36 PM
> > To: internals@lists.php.net
> > Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
> >
> > Okay, I would like this to be the last time there are revisions to this
> RFC.
> >
> > To sum up the last few days of conversations, I have these down as
> points of contention:
> >
> > 1.  Accessor functions should not be present on the object and callable
> directly, for example, $o->__getHours() should not be
> > allowed.
> > 2.  Preferred syntax for accessors should be "public set($value) { ...
> }" with no "magic" $value (with possible type hinting) 3.
> > Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing
> > most everyone.
> > 4.  read-only / write-only keywords, keep them or get rid of them?
>  There is no directly suitable replacement but I believe a private
> > final set() { } will take care of it, even though it much more verbose.
> > 5.  Error handling for thrown exceptions should be made more appropriate
> for accessors 6.  The "truth" of reflection.  Should it reveal
> > details internal to how PHP works on the inside or should it reflect the
> way PHP presents it as options?
> >
> > Did I miss anything?
> >
> >
> > I will come up with some way for people to vote on the issues at hand
> and we can cast our votes and be done with it, then I will
> > finish the project and get it out the door.
> >
> > -Clint
>



-- 
github.com/KingCrunch

--047d7b62275ec66a9904cbcf5505--