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
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
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 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,
>
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 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
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
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,
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
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
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
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
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
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!
> 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
15 matches
Mail list logo
