Wow, I'm surprised by all the talk about this RFC this time around. I posted
this numerous times in the past trying to elicit feedback and got little to
none, so I took the time to write it as I thought it should be written. Some
of these things will take considerable effort to fix/correct/cha
On 09/10/12 19:20, Jazzer Dane wrote:
- "If we ever get return type hinting/checks then we needn't consider how
the syntax has to look" From what I know, this isn't planned for PHP 5.5
and any proposals for it have been largely ignored. Return type hinting
won't help when setting either, although
I think Leigh brings up some important flaws to in the current RFC. What
Leigh is asking for does not appear to be possible, and in my opinion, it
should be.
I also agree with Rasmus, to a certain extent.
By putting only a getter/setter, the developer essentially sets the
property as read or write
On Mon, 2012-10-08 at 11:52 +, Clint Priest wrote:
> It's been a while since I posted any updates about this, a few individuals
> have been asking about it privately and wanting me to get it out the door for
> PHP 5.5 release. It's come a long way since the last time I posted about it.
>
>
This looks great, and essentially has everything I had hoped for!
My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other lang
> RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
public $property {
set { $this->property = ($this->property*2)+$value }
get;
}
How do I reference the property being set from within the function? The way
I have done it in the example will cause recursion? How can I ass
Is there a reason why we cannot implement this using PHP's already widely used
function syntax:
class TimePeriod {
private $Seconds = 3600;
public $Hours {
public function get() { return $this->Seconds / 3600; }
private function set($value) { $this->Seconds = $value; }
> What concerns me with the current implementation is that it leaks many
> implementation details, in particular the fact that the accessors are
> implemented as *real* __getXYZ methods and automatic implementations
> also use *real* $__XYZ properties.
Further to this, take the following example.
Hi,
On Tue, Oct 9, 2012 at 3:01 PM, Nikita Popov wrote:
> On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest wrote:
>> It's been a while since I posted any updates about this, a few individuals
>> have been asking about it privately and wanting me to get it out the door
>> for PHP 5.5 release. It'
On Mon, Oct 8, 2012 at 1:52 PM, Clint Priest wrote:
> It's been a while since I posted any updates about this, a few individuals
> have been asking about it privately and wanting me to get it out the door for
> PHP 5.5 release. It's come a long way since the last time I posted about it.
>
> RFC
On Tue, 9 Oct 2012, Nikita Popov wrote:
> On Thu, Oct 4, 2012 at 9:45 AM, Derick Rethans wrote:
> > On Sun, 30 Sep 2012, Stas Malyshev wrote:
> >
> >> I was looking into generators topic and I couldn't find answer to
> >> this question: how generators are supposed to interact with PHP
> >> tool
On Thu, Oct 4, 2012 at 9:45 AM, Derick Rethans wrote:
> On Sun, 30 Sep 2012, Stas Malyshev wrote:
>
>> I was looking into generators topic and I couldn't find answer to this
>> question: how generators are supposed to interact with PHP tools, such
>> as debuggers, profilers, etc.? Specifically, ho
Hi!
Just read the comments for Bug #47584: WSDL error in soapClient causes
Fatal Error.
If a SoapClient is created and the WSDL can not be found, an Exception
is thrown:
1 ) );
}
catch ( Exception $e )
{
echo $e->faultstring;
}
echo "ok\n";
$error = error_get_last();
print_r( $error );
?>
On Tue, Oct 9, 2012 at 5:10 AM, Tjerk Anne Meesters wrote:
> Hi,
>
> I've managed to pinpoint the issue inside the code itself and attached a
> patch for 5.4.4 (I can make one for trunk as well, but at the time of
> writing I worked with what I had).
>
> The bug manifests itself when delimiter siz
Hi,
I've managed to pinpoint the issue inside the code itself and attached a
patch for 5.4.4 (I can make one for trunk as well, but at the time of
writing I worked with what I had).
The bug manifests itself when delimiter size > 1 AND the file pointer falls
in between a delimiter after filling th
On Tue, Oct 9, 2012 at 12:59 AM, Tjerk Anne Meesters wrote:
> On Tue, Oct 9, 2012 at 12:14 AM, Nicolai Scheer wrote:
>
>> Hi!
>>
>> We switched from php 5.3.10 to 5.3.17 this weekend and stumbled upon a
>> behaviour of stream_get_line that is most likely a bug and breaks a
>> lot of our file proce
Christian, I think a majority of your concerns are all for none.
>From top to bottom:
- Extra indention: This is definitely a bias and is only moderately
relevant while documenting this feature.
- You *can* declare a public getter and private setter, or vice versa, or
whatever you want. This is i
2012/10/9 Christian Kaps
> Hi,
>
> typehinting should definitely be available for this feature. But I have
> another question. Why not go more consistent with the rest of the language?
> I have mentioned this previously as the first proposal comes up on the
> list. In my opinion the AS3 getter an
Hi,
typehinting should definitely be available for this feature. But I have
another question. Why not go more consistent with the rest of the
language? I have mentioned this previously as the first proposal comes
up on the list. In my opinion the AS3 getter and setter
syntax(http://help.adobe
19 matches
Mail list logo
