Object properties (or members, classic ->var, not this proposed syntax)
CURRENTLY, work this way:
php -r 'class foo { public $bar; } $foo = new foo();
var_dump(isset($foo->bar));'
bool(false)
This is because you are confusing PHP's isset() with a property_exists(). Is
set. Is the variable (or
On 11/30/10 6:29 PM, presid...@basnetworks.net wrote:
That is true for PHP variables. isset is basically saying "does this
variable exist", and unset is saying to get rid of it.
Because properties (as defined in my RFC) are not a variable, but rather
a
set of methods, I do not think there would
Hi, first time on the lists, guess I'm from userlando too,
+1 for readability, all I ever really look at are "( ... ){" at the end of
the line so I personally don't think it affects readability. Also, this is
the way its done in other languages and I have always found the function
keyword unnecess
> Thanks for your reply.
>
> Fundamentally, a big +1 from my little voice on having setters/getters in
> PHP.
>
>
> The issue of documentation is probably that the documentation tools
> would have to adapt. As things stand PHPDoc doesn't support
> namespaces, so setters/getters would just be added
On 11/30/10 5:55 PM, presid...@basnetworks.net wrote:
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
Thank you!
First of all, I have generally found the Bean-style getter/setter
approach to
be a sign of poor encapsulation to begin with. You shouldn't be muc
>> That is true for PHP variables. isset is basically saying "does this
>> variable exist", and unset is saying to get rid of it.
>
> This is also true for object properties - see magic methods. I don't see
> why you shouldn't be able to unset them - you can do that with regular
> properties... So
You are missing the point in PHP in that case. Because PHP is dynamic
scripting language, public properties can be added and removed in the
object on the fly. That's why there is isset and unset that works on
object properties. Consider ActiveRecord, DataMappers, ORM, etc. They
use that 100% to th
>> That is true for PHP variables. isset is basically saying "does this
>> variable exist", and unset is saying to get rid of it.
>>
>> Because properties (as defined in my RFC) are not a variable, but rather
>> a
>> set of methods, I do not think there would be any way to "unset" them.
>> Like a
On 11/30/10 6:15 PM, presid...@basnetworks.net wrote:
public property Hours read getHours write setHours;
I actually like that, though I think we should support the whole
existing semantics, i.e. get/set/isset/unset. And probably keep the
names, so we don't call the same thing both "read"
>> public property Hours read getHours write setHours;
>
> I actually like that, though I think we should support the whole
> existing semantics, i.e. get/set/isset/unset. And probably keep the
> names, so we don't call the same thing both "read" and "get".
This doesn't make sense. To call i
> ...
>
>> /**
>> *
>> */
>> public function set name(string $name) {
>> $this->name = htmlentities($name);
>> $this->name = strip_tags($this->name);
>> }
>>
>> /**
>> *
>> */
>> public function get name($name) {
>> return $this->name;
>> }
>>
>> Greetings,
>> Christian
>>
>
> For what
> This is a very well-written and well-thought through RFC, Dennis. Nicely
> done.
Thank you!
> First of all, I have generally found the Bean-style getter/setter
approach to
> be a sign of poor encapsulation to begin with. You shouldn't be mucking
with
> internal elements of an object in the fi
Hi Benjamin,
> I have been working with Objective-c lately, and it has a very flexible
> and short way to deal with properties, which could look like this in PHP :
>
> class TimePeriod {
> protected $seconds;
> protected $minutes;
> protected $hours;
>
>
> @synthesize (rea
>> I still want to keep the performance implications in mind, as this
>> sounds like something that we'd want to use a lot but could also cost a
>> lot more than it seems at first glance if we're not careful.
>
> By making properties in memory a little bigger one might write the
> accessors in the
Richard Quadling wrote:
> (I assume the variable has to be part of the current class or one of its
> parents?)
Yes. I don't think it makes sense to have a class property actually read
a global.
If a project really need it (eg. some migration from procedural style to
classes), then
use the verbose
OS:Windows (XP and 7 tested)
PHP: 5.2.9 and 5.3.3
I created my own php sapi 1 year ago and it was only single threaded.
Now I tried to make it multi-threaded by using TSRM.
I got 1 thread starting up and shutting down the TSRM and my module and
many other threads executing requests. You
Hi, I've never participated on the lists, but this was a topic I could just
not look away from.
My take on this is that it all boils down to the statistics of the
developers and contributors, as Gwynne said, there is really no much merit
on technical aspects of the tools... but rather how the comm
Gwynne Raskind wrote:
*Googles.*
*Reads.*
Well... dang. Go Wez!!
Magic just what I was looking for as well.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquir
+1, next major version.
On Mon, Nov 29, 2010 at 5:42 PM, Jonah H. Harris wrote:
--
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
On Tue, Nov 30, 2010 at 8:22 AM, Ilia Alshanetsky wrote:
> -1
>
> I don't think this is necessary.
>
It's certainly not necessary; it's a nice to have. Given the small amount
of code required to implement the functionality, I believe it's worthwhile
to add the notation as an option for develope
On 30 November 2010 12:48, wrote:
> Hi Richard,
>
>
>
>> I'd really like this feature to be part of PHP.
>>
>> I don't particularly like the use of what looks like a closure for the
>> set/get.
>
> While it looks like a closure, it may not necessarily be one. What I have
> presented in my RFC is
Hi!
That is true for PHP variables. isset is basically saying "does this
variable exist", and unset is saying to get rid of it.
This is also true for object properties - see magic methods. I don't see
why you shouldn't be able to unset them - you can do that with regular
properties... So wh
On Tue, 2010-11-30 at 09:15 -0500, presid...@basnetworks.net wrote:
> That is true for PHP variables. isset is basically saying "does this
> variable exist", and unset is saying to get rid of it.
>
> Because properties (as defined in my RFC) are not a variable, but rather a
> set of methods, I do
Hello Stas,
>> I do not think that properties should make use of a trait-like syntax,
>> as
>> that is not what a property is about. A property is basically a layer
>> of
>> syntactic sugar over a pair of methods. The majority of the time when
>> writing properties, you will not want to re-use t
2010/11/29 Ángel González :
> Richard Quadling wrote:
>> As for reading $seconds directly ...
>>
>> Well.
>>
>> If you think of the element that follows read as $this->, then if
>> the parser can handle both ...
>>
>> read $seconds
>> read getSeconds
>>
>> then yes for both.
>>
>> If not, then
Hi!
I do not think that properties should make use of a trait-like syntax, as
that is not what a property is about. A property is basically a layer of
syntactic sugar over a pair of methods. The majority of the time when
writing properties, you will not want to re-use them, so I have a hard
ti
Hi:
On 30 Nov 2010, at 14:42, presid...@basnetworks.net wrote:
> However, it does make sense to be able to define a property as part of a
> trait, as again, it is basically just a pair of methods. When I get some
> time, I will try to add a syntax for traits to the RFC.
The only thing really nec
Hello,
>> Hi!
>>
>> > Nice RFC, just an idea for an alternative syntax (added to the RFC
>> > as
>> #2):
>> >
>> > property Hours {
>> >get { return $this->seconds / 3600; }
>> >set { $this->seconds = $value * 3600; } // The variable $value
>> holds
>> > the incoming value to be "set"
>> >
-1
I don't think this is necessary.
On Wed, Nov 10, 2010 at 4:31 PM, Jonah H. Harris wrote:
> Hey all,
>
> I was recently working on some code which made use of bit arrays and I came
> across feature request 50648: Format for binary numbers. While it's just
> more syntactic sugar (0b1011010
On 2010-11-30, Andrey Hristov wrote:
> Zend/zend_compile.h:508:1: warning: C++ style comments are not allowed
> in ISO C90
> Zend/zend_compile.h:508:1: warning: (this will be reported only once per
> input file)
>
> Lines 508 and 509
>
> Someone with Zend karma, please, fix this. Compiled in tru
Hi Richard,
> I'd really like this feature to be part of PHP.
>
> I don't particularly like the use of what looks like a closure for the
> set/get.
While it looks like a closure, it may not necessarily be one. What I have
presented in my RFC is a syntax, but I make little assumption about how
Zend/zend_compile.h:508:1: warning: C++ style comments are not allowed
in ISO C90
Zend/zend_compile.h:508:1: warning: (this will be reported only once per
input file)
Lines 508 and 509
Someone with Zend karma, please, fix this. Compiled in trunk.
Thanks,
Andrey
--
PHP Internals - PHP Runtime
On Nov 30, 2010, at 5:10 AM, Ferenc Kovacs wrote:
>> I just wish I didn't have to also admit that Trac is a really great project
>> management system. Unless things have changed drastically since I was last
>> active, PHP still needs one. ^^;
> just a little comment on the last statement:
> do you
Hi
2010/11/30 Patrick ALLAERT :
> With this patch, something looks inconsistent to me:
> Both properties and methods have a visibility
> (public|protected|private) and a keyword: "var" (T_VAR) and "function"
> (T_FUNCTION) respectively.
> However "private var $foo;" generates a fatal error but "pr
On Tue, Nov 30, 2010 at 10:49 AM, Gwynne Raskind wrote:
> On Nov 29, 2010, at 4:19 AM, Lester Caine wrote:
> >>> I've not used git or hg much at all, but bzr has always satisfied my
> >>> needs for DVCS, and has recently gotten much faster and more space
> >>> efficient than it was in the past.
>
2010/11/27 Johannes Schlüter :
> Hi,
>
> every now and then while writing classes I forget to add the "function"
> keyword between my visibility modifier and the method name in a class
> declaration. I don't think it is required for readability and it is not
> needed by the parser to prevent confli
2010/11/27 Johannes Schlüter
>
> Hi,
>
> every now and then while writing classes I forget to add the "function"
> keyword between my visibility modifier and the method name in a class
> declaration. I don't think it is required for readability and it is not
> needed by the parser to prevent confl
On Nov 30, 2010, at 4:24 AM, Arvids Godjuks wrote:
> Personally, as a user-land developer, I'm against it, so -1.
> function keyword is the only sane way to quickly find a function
> definition in lots of code. Not always IDE's are able to fully
> understand the interconnections in frameworks and p
On Nov 29, 2010, at 4:19 AM, Lester Caine wrote:
>>> I've not used git or hg much at all, but bzr has always satisfied my
>>> needs for DVCS, and has recently gotten much faster and more space
>>> efficient than it was in the past.
>> Sorry, but I think bzr is not a good fit. It's numerous changes
Personally, as a user-land developer, I'm against it, so -1.
function keyword is the only sane way to quickly find a function
definition in lots of code. Not always IDE's are able to fully
understand the interconnections in frameworks and point by CTRL +
Click me to the function definition, not to
On 11/26/2010 08:36 PM, Felipe Pena wrote:
Hi all,
...
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
+1
Finally.
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
On 11/27/2010 06:40 PM, Johannes Schlüter wrote:
Hi,
...
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johann
On 11/29/2010 05:42 PM, Jonah H. Harris wrote:
I've posted a replacement of the 5.3 patch with one against trunk.
+1
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi.
it was rejected for inclusion that time, but maybe it could be a good idea
to try to propose it again.
this kind of discussion should be taken place on internals@lists.php.net ,
I've just cc'ed it.
for writing an RFC, you should register on the wiki:
http://wiki.php.net/
and ask karma for the
I guess serialize mechanism cant use any char that can be part of a
PHP variable. And "_" can. As property names respect binary
compatibility, the only char that can be used to mark private
properties is actually the NULL byte. Ping me if I'm wrong.
But I'm +1 for improving the serialize() speed,
45 matches
Mail list logo
