Hi!
> Stas, you should probably do some research before posting such non-sense:
Which part is "non-sense"? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have accessors - as you define accessors as
hidden metho
Am 28.10.2012 02:42 schrieb "Clint Priest" :
>
> Sounds like you're implying that the mere existence of a properly named
function such as __prop_get_hours() would cause it to be called instead of
returning the property.
Only when the property does not exist, just like it is with __get
> 1) Curren
Hi!
> Sorry I guess I should have been more clear. The recursion would
> prevent the accessor from being called which would allow the ordinary
> property code to execute, thus accessing the property directly. I
This could lead to weird scenarios where the same $foo->bar in random
function co
hi Clint,
On Sat, Oct 27, 2012 at 7:39 PM, Clint Priest wrote:
> That's basically what #2 is getting at, my only question is, emit a warning
> or notice or not?
>
> Technically returning false on an invalid isset() call could be misleading
> without emitting some kind of notice or warning about i
Hey:
could you please open a bug at bugs.php.net for that?
thanks
On Sun, Oct 28, 2012 at 11:05 AM, dabo wrote:
> Hi folks,
>
> I believe there's an issue with the SessionHandler implementation and
> the way the destroy handler is invoked when using
> session_regenerate_id(TRUE)
>
> Using lat
Stas Malyshev wrote:
By accessors I am simply referring to getters, setters (and in the case
>of php, issetter and unsetter).
I wish it was so, but it was mentioned many times in this discussion
that "accessors should be accessors" and that only the situation where
accessors are special function
On 10/28/2012 2:04 AM, Stas Malyshev wrote:
Hi!
Stas, you should probably do some research before posting such non-sense:
Which part is "non-sense"? I've brought you examples of Python and Ruby
not doing exactly what you claim all languages are doing. By your
definition, they don't have access
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of warning/notice? */
I mean specifically,
Well I guess this and many of the other issues from other threads are
the reasons I had it written the way that it is currently (basically an
extension of __get()) but numerous other proposals have muddied the
situation.
On Sunday, October 28, 2012 2:17:47 AM, Stas Malyshev wrote:
Hi!
Sorry
On Sun, Oct 28, 2012 at 4:50 PM, Clint Priest wrote:
> On 10/28/2012 2:04 AM, Stas Malyshev wrote:
>>
>> Hi!
>>
>>> Stas, you should probably do some research before posting such non-sense:
>>
>> Which part is "non-sense"? I've brought you examples of Python and Ruby
>> not doing exactly what you
See, I'm not convinced that "everyone would agree that #1 [just some
syntax candy] is definitely not right". From the discussion here, it
seems like some are still thinking of it that way.
If they are supposed to be a 3rd thingie, and the only relation to data
members as we've known them is t
On Wed, Oct 24, 2012 at 10:46 PM, JJ wrote:
> On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
> wrote:
>> I understand there are people out there that don't read the
>> documentation and aren't aware of the difference between
>> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch,
>
Done :
https://bugs.php.net/bug.php?id=63379
- Mail original -
De : Laruence
À : dabo
Cc : "internals@lists.php.net" ; Arpad Ray
Envoyé le : Dimanche 28 octobre 2012 11h24
Objet : Re: [PHP-DEV] Warning when using session_regenerate_id(TRUE) with a
SessionHandler
Hey:
could you
On 29/10/12 03:02, Clint Priest wrote:
So... to be explicit here, you think in this situation:
class a {
public $b {
set($x) { $this->b = $x; }
}
}
$o = new a();
if(!isset($o->b)) {
/* delete files */
}
echo (int)isset($o->b); /* This should return false and not emit any
sort of w
That's pretty fair, that last statement... As far as an application is
concerned $o->b doesn't exist because it can't be read.
Seems as though some developers are going to want to know when they've
tried to violate it though... I dunno. Personally I would consider it
error or warning worthy b
15 matches
Mail list logo
