Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
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 because if I made that mistake I would want to
know about it, rather than never been notified of it.
Is there another class of error that would make more sense? Don't most
people turn off E_NOTICE errors? Perhaps emit an E_STRICT?
On 10/28/2012 8:57 PM, David Muir wrote:
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 warning/notice? */
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing
execution to stop I don't see it being a good idea to not warn the
developer that what they've attempted is not correct. Without a
getter, isset() is not a legal call (since the value cannot be
retrieved).
I agree with Pierre, isset() should never throw a warning/notice. The
primary use of isset (that I've seen in various code-bases) is to
avoid warnings/notices. Only rarely do I see it used in an expression
to control application logic. The above example should not give a
warning, and should return false. As far as an application is
concerned, $o->b doesn't exist because it can't be read.
David
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
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 warning/notice? */
I mean specifically, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
to stop I don't see it being a good idea to not warn the developer
that what they've attempted is not correct. Without a getter, isset()
is not a legal call (since the value cannot be retrieved).
I agree with Pierre, isset() should never throw a warning/notice. The
primary use of isset (that I've seen in various code-bases) is to avoid
warnings/notices. Only rarely do I see it used in an expression to
control application logic. The above example should not give a warning,
and should return false. As far as an application is concerned, $o->b
doesn't exist because it can't be read.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warning when using session_regenerate_id(TRUE) with a SessionHandler
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 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 latest stable Gentoo PHP 5.4.6 but as far as I could tell the C > code source for this part hasn't since been touched up to master. > > The following code generates a warning : > > $handler = new SessionHandler(); > session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter > > session_start(); > session_regenerate_id(TRUE); > > //session_write_close(); > --- > PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0 > > The call to session_write_close() just adds a proper backtrace. > > The problem seems to come from using the global "mod_user_is_open" in > the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c). > Any reason "session_status" isn't checked instead ? > > Can anyone confirm ? > > Thank you > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
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, >> CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a >> good idea either. > > I highly doubt code that sets CURLOPT_SSL_VERIFYHOST => true meant to > imply CURLOPT_SSL_VERIFYHOST => 1...which essentially bypasses host > verification. > > According to libcurl, CURLOPT_SSL_VERIFYHOST => 1 is "not ordinarily a > useful setting". The curl stream wrapper sets this option to 1 when using the curl_verify_ssl_host context option. I imagine that should be fixed too then? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 that they have the same external syntax,
then IMO we should make them as distinct as possible, everywhere. New
keyword, separate reflection pipeline, the works. That then means that
the implementation detail of "public $baz { get() {return 'meep'; }
causes the creation of public function __get_property_meep()" should not
be exposed, anywhere, and that method should not show up in reflection,
since it doesn't really exist, it's just an implementation detail.
It's the "depending on how you look at it, you may or may not get to see
implementation details leak" problem that I think is the worst case
scenario.
--Larry Garfield
On 10/27/2012 10:59 PM, Clint Priest wrote:
Hey Larry,
Glad you chimed in here on this. I my opinion (author of thingy),
they are separate and distinct from data members. More specifically
they are getter and setter code that is called when the property is
accessed.
Using your example:
echo $obj->baz; // executes the code "return $this->baz;"
and
$obj->baz = 4; // executes the code "$this->baz = $value;"
So from the perspective of the user of the class, they are just
"properties" but internal to the class they are implemented with
methods and code.
I think everyone would agree that your #1 is definitely not right,
however I believe there is not consensus on whether or not these *are*
different from properties. To the consumer of the class, they are no
different than properties, to the author of the class they are very
different.
On Saturday, October 27, 2012 9:48:12 PM, Larry Garfield wrote:
On 10/27/2012 09:38 PM, Larry Garfield wrote:
On 10/26/2012 05:37 AM, Clint Priest wrote:
I'm opening up several new threads to get discussion going on the
remaining "being debated" categories referenced in this 1.1 -> 1.2
change spec:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Some people are in favor of the internal functions being generated
by an accessor declaration should be invisible and non-callable
directly. Others are in favor of leaving them visible and callable.
*Type 1 ( Userland Programmer )**
*
As a userland programmer, someone who cares nothing for "how" php
works, only how their own code works. If they define an accessor
they expect to see an accessor, reflection should reflect that there
are accessors and no other "methods" they did not explicitly define.
If they were to reflect on all of the methods of their class and see
a number of __getHours() they may be confused as to why or where
this function came from. From their perspective, they have defined
an accessor and "how" that accessor works on the inside is of no
importance to them and only seeks to complicate or confuse matters
when they are exposed to these "implementation details" of the php
language its-self. If you tried to set a value such as $obj?abc = 1
through an accessor which could not be set, you would probably want
to see an error like: Warning, cannot set Class?abc, no setter
defined.
*Type 2 ( Internals Programmer )**
*
As an internals programmer, you want nothing hidden from you. If an
accessor implements special __getHours() methods to work its magic,
then you want to see them, you want to call them directly if you so
choose. In effect you want nothing hidden from you. In this case you
probably don't even want Reflection to reflect accessors as anything
different than specially formatted and called methods on the class.
This can be understandable because you want all information
available to you. You would probably not be confused if you wrote
$obj?abc = 1 and got back an error like "Fatal Error:
Class->__setAbc() function does not exist.
*Unfortunately 80 to 95% of all people who use PHP are of the first
type.**
*
Revealing these internal matters to them would only leave them
confused, possibly frustrated and likely asking about it to the
internals mailing list to answer (repeatedly).
Thoughts?
Speaking as a user-land programmer that's been following this thread,
but hasn't been able to jump in yet due to the high volume of
comments...
What's unclear to me is what my mental model should be for this new
syntax. That's important for informing how it should be exposed to me.
1) Should I have a mental model of this being some syntax candy on
top of existing properties? Vis, this is just a short-hand for
bean-style classes? By Bean style, I mean Properties that would be
public but aren't because Public Is Bad(tm), so instead we have
getX()/setX() for every property, so that we can
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 claim all languages are doing. By your
>> definition, they don't have accessors - as you define accessors as
>> hidden methods that are uncallable and unavailable and not defined as
>> regular methods. In both Ruby and Python they are callable and defined
>> as regular (or regular with some special attributes) method.
>>
>> I've brought you examples of popular languages that don't have this
>> feature at all - Java and standard C++ don't have it. I was wrong on
>> Javascript - though in Javascript, functions work differently from PHP
>> so there's no real relation to the current discussion.
>>
>>> 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 functions that are not defined as regular methods,
>> are not callable and are hidden from reflection, etc. is the situation
>> where "accessors are accessors". This is not the case in Python, Ruby,
>> MS C++, D and Delphi by your own link - in all these cases, the
>> properties are defined as regular methods (possibly with some special
>> salt added) and no special effort is taken to hide them from any of the
>> language facilities and make them not callable.
>> Of course, there are also examples of languages going the other way -
>> namely, C#, F# and VB - but by no means the claim that I would be hard
>> pressed to find example of the languages which do not implement your
>> notion of "accessors being accessors" is true. For most dynamic
>> languages, the concept of "accessors being accessors" - hidden,
>> non-callable pseudo-methods - is a foreign concept.
>>
> I see what you're talking about, I felt like you were saying these other
> languages did not support accessors (getters, setters, etc). Those other
> languages do not "hide" them, no. This was Nikita's suggestion, I will let
> her fight for it.
If I got it right now, what Stas wants is that we introduce __getFoo
and __setFoo methods that will be called whenever an undefined ->foo
property is accessed and that the "normal" property accessors syntax
is made nothing more than a fancy notation for this.
I'm okay with one of those, but I highly advise against combining
both, i.e. either __getFoo and __setFoo OR a special accessor syntax.
The reason is that both carry different and non-combinable semantics.
A few examples:
A) Inheritance:
==
class A {
public $foo;
}
class B extends A {
public $foo { get() { ... } set($value) { ... } }
}
=> With the accessors syntax there is an expectation that the accessor
declaration will override the previous plain property. At least that's
what I would expect and that's what the code looks like
class A {
public $foo;
}
class B extends A {
public function __getFoo() { ... }
public function __setFoo($value) { ... }
}
=> With the magic syntax there is the expectation that the $foo
property will not be overridden. Rather the magic functions are
expected to do nothing, because the property already exists.
B) Interfaces:
=
interface A {
public $foo;
}
class B implements A {
public $foo { get() { ... } set($value) { ... } }
}
=> Here the accessor is expected to satisfy the interface
interface A {
public $foo;
}
class B implements A {
public function __getFoo() { ... }
public function __setFoo($value) { ... }
}
=> Here the magic methods don't satisfy the interface. Actually with
the magic methods approach the whole notion of properties or accessors
in interfaces becomes obsolete.
C) API semantics
=
The main advantage that accessors offer to me is that custom property
behavior can be a *proper part of the public API*. The magic __getFoo
/ __setFoo methods do not offer this. They are just another two magic
methods. On the other hand, proper accessors really define a
*property* with a certain behavior (the fact that they are bound to a
property is important here).
__getFoo and __setFoo are really not much of an improvement over
directly using __get and __set with a switch. It's just a small code
save. "Real" accessors on the other hand take properties to being a
first class API citizen.
D) Backing property
==
Additionally __getFoo / __setFoo would not allow us to access
$this->foo as the underlying "backing property". Whether or not this
approach has merits is a different discussion point, but the magic
method approach would make this impossible right from the
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
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 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 could call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo->bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
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, there is no getter defined, therefore the result
if isset is indeterminate and while I can see it not causing execution
to stop I don't see it being a good idea to not warn the developer that
what they've attempted is not correct. Without a getter, isset() is
not a legal call (since the value cannot be retrieved).
On Sunday, October 28, 2012 4:02:23 AM, Pierre Joye wrote:
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 it.
isset is used for this exact purpose, avoid noisy scripts while
testing the existence (instance, init'ed, etc.) of a variable or
property. Raising a notice here sounds wrong, no matter in which
context.
Cheers,
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 accessors - as you define accessors as hidden methods that are uncallable and unavailable and not defined as regular methods. In both Ruby and Python they are callable and defined as regular (or regular with some special attributes) method. I've brought you examples of popular languages that don't have this feature at all - Java and standard C++ don't have it. I was wrong on Javascript - though in Javascript, functions work differently from PHP so there's no real relation to the current discussion. 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 functions that are not defined as regular methods, are not callable and are hidden from reflection, etc. is the situation where "accessors are accessors". This is not the case in Python, Ruby, MS C++, D and Delphi by your own link - in all these cases, the properties are defined as regular methods (possibly with some special salt added) and no special effort is taken to hide them from any of the language facilities and make them not callable. Of course, there are also examples of languages going the other way - namely, C#, F# and VB - but by no means the claim that I would be hard pressed to find example of the languages which do not implement your notion of "accessors being accessors" is true. For most dynamic languages, the concept of "accessors being accessors" - hidden, non-callable pseudo-methods - is a foreign concept. I see what you're talking about, I felt like you were saying these other languages did not support accessors (getters, setters, etc). Those other languages do not "hide" them, no. This was Nikita's suggestion, I will let her fight for it. -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 functions that are not defined as regular methods, are not callable and are hidden from reflection, etc. is the situation where "accessors are accessors". This is not the case in Python, Ruby, MS C++, D and Delphi by your own link - in all these cases, the properties are defined as regular methods (possibly with some special salt added) and no special effort is taken to hide them from any of the language facilities and make them not callable. While I will probably be shouted down again ... can we clarify WHAT people are trying to achieve here? __get and __set simply provide a crude means of using '$data' array to store properties in an object without having to define and load them every time. It has very limited use and in my own opinion is simply wrong anyway. But people seem to like to use it rather than simply defining their own $data array and accessing it directly? The reason it does not work for me is that I populate the data array ( in my case $mInfo ) directly from the persistent data in a database, and __get and __set simply do not work with this so never get used. I can SEE the logic behind a get and set arrangement being 'formalised', and mirroring __get and __set is obviously necessary, but part of the reason for this discussion was - I thought - a way of allowing get/set to manage access to internal data that may not be a simple mirror, but rather calculated from other internal data ( hours based on second count )? 'Internal Accessor Method Visibility' needs to provide the user with information on how a returned value was generated? Even if that is only via documentation? Debugging that the process is working is the thing that gets difficult if you can 'see' the process. The discussion has been 'split up', but I see 'Extra shorthand declaration' as another hiding of visibility such that 'public DateTime $date;' completely bypasses setting up the DateTime object and that $date will have it's own 'accessors' or rather methods for accessing and configuring the object and it's values! PHP has something no other language has - 'very flexible arrays' - and we can manage and pass data very nicely using these properly. Pass by reference allows complex data to be passed and massaged in a way that 'accessors' simply can't provide, and it's this method of working that we should be promoting rather than trying to hide things 'because the user does not need to know about them'. Everything used to be nicely visible in PHP, but that is becoming less the case and getting back to a framework where the IDE can provide all of the 'eye-candy' that is not needed when simply running the scripts should be considered as well? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warning when using session_regenerate_id(TRUE) with a SessionHandler
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 latest stable Gentoo PHP 5.4.6 but as far as I could tell the C > code source for this part hasn't since been touched up to master. > > The following code generates a warning : > > $handler = new SessionHandler(); > session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter > > session_start(); > session_regenerate_id(TRUE); > > //session_write_close(); > --- > PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0 > > The call to session_write_close() just adds a proper backtrace. > > The problem seems to come from using the global "mod_user_is_open" in > the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c). > Any reason "session_status" isn't checked instead ? > > Can anyone confirm ? > > Thank you > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
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 it. isset is used for this exact purpose, avoid noisy scripts while testing the existence (instance, init'ed, etc.) of a variable or property. Raising a notice here sounds wrong, no matter in which context. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing
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 could call or not call an accessor depending on the stack trace (provided that accessors call out to other functions - which is not frequent but can definitely happen). In case of __get it's harmless since we know $foo->bar doesn't exist anyway, but if we do allow $bar to exist in $foo it might get weird. I'd certainly appreciate some notice/E_STRICT if this happens. Maybe I'd go even as far as issuing E_STRICT on having both $bar and any of the accessors for $bar in the same class - but this of course would scream on the scenario of augmenting existing $bar with accessors - which is legit, unless it gets weird as described above. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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) Currently __get() is only checked/invoked if there is not a property already defined; ie properties shadow __get() (no performance penalty) Right. I would expect / hope for __prop_get_XXX to work exactly the same. > 2) It would dramatically reduce performance because every property access would have to create the function string, get it's hash value and . But that only applies to an "accessor shadows property" doctrine, and that is one of these complications / complexity issues which makes me prefer the "property exists means it's definite" doctrine as already deployed with __get. best regards Patrick
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
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 methods that are uncallable and unavailable and not defined as regular methods. In both Ruby and Python they are callable and defined as regular (or regular with some special attributes) method. I've brought you examples of popular languages that don't have this feature at all - Java and standard C++ don't have it. I was wrong on Javascript - though in Javascript, functions work differently from PHP so there's no real relation to the current discussion. > 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 functions that are not defined as regular methods, are not callable and are hidden from reflection, etc. is the situation where "accessors are accessors". This is not the case in Python, Ruby, MS C++, D and Delphi by your own link - in all these cases, the properties are defined as regular methods (possibly with some special salt added) and no special effort is taken to hide them from any of the language facilities and make them not callable. Of course, there are also examples of languages going the other way - namely, C#, F# and VB - but by no means the claim that I would be hard pressed to find example of the languages which do not implement your notion of "accessors being accessors" is true. For most dynamic languages, the concept of "accessors being accessors" - hidden, non-callable pseudo-methods - is a foreign concept. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
