Hello Stanislav,
On May 17, 2006, at 5:25 PM, Stanislav Malyshev wrote:
JM>>individual properties, just as you can in Java, C#, Ruby, Delphi,
JM>>Python, Visual Basic, Objective C, Smalltalk, and sometimes C++.
(To
JM>>the best of my knowledge.) Read only is a special case of this
JM>>capab
Jeff Moore wrote:
On May 16, 2006, at 7:28 PM, D. Dante Lorenso wrote:
I'm not familiar with this OOP concept from any other language.
Perhaps it exists, but if it doesn't, is there a reason why?
Its hard to find a major OO language that does not have
property/accessor method support.
It's n
Its hard to find a major OO language that does not have
property/accessor method support.
Fine. Go use one of those.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Just to be complete ;)
D:
int hidden_name;
public int the_var_name() { return hidden_name; }
private void the_var_name(int s_value) { hidden_name = s_value; }
ref: http://www.digitalmars.com/d/archives/56.html
Regards
Alan
Jeff Moore wrote:
On May 16, 2006, at 7:28 PM, D. Dante Lorenso w
On May 17, 2006, at 2:25 PM, Stanislav Malyshev wrote:
This would be, however, yet another level of complexity added to the
language...
OOP is already a level of complexity. If you're going to have OOP in
the language, it needs to support at least the standard needs that
developers have w
Stanislav Malyshev wrote:
This would be, however, yet another level of complexity added to the
language...
I think that for the end user it becomes less complicated ...
Try to explain a newbie how to properly use getters or setters or even
explain him the magic method (using __get and __set
JM>>1. __get/__set are too cumbersome for simple use cases. (Hence this
JM>>thread)
This thread is in no way "simple use case".
JM>>2. __get/__set is slow. (In the best case: about 10x slower than simple
JM>>property, 3x slower than an accessor method call)
Slow as opposed to calling differe
On May 16, 2006, at 7:28 PM, D. Dante Lorenso wrote:
I'm not familiar with this OOP concept from any other language.
Perhaps it exists, but if it doesn't, is there a reason why?
Hello,
Its hard to find a major OO language that does not have
property/accessor method support.
C#:
private
Hello Stanislav,
Wednesday, May 17, 2006, 12:30:35 PM, you wrote:
JG>>> private readable $abc;
JG>>> - doesn't make sense.
JG>>>
JG>>> protected readable $abc;
JG>>> - sub-class can read, not write
JG>>> - not visible outside class
JG>>>
JG>>> public readable $abc;
JG>>> - sub-class can
Hello Sebastian,
it simply means that derived classes cannot write that variable.
Other languages already allow that and it is actually very convenent.
One of the things i really liked about Borland C++. In contrast
"protected readbale" means that dervied classes may also write that
thing in que
Hello Jason,
so i forget about the other. Once you have tests we can fit them into the
source tree so that they go here: http://gcov.php.net
best regards
marcus
Wednesday, May 17, 2006, 4:54:28 PM, you wrote:
> Hello Hannes,
> Nothing is wrong, I presume. Ignorance on my part.
> Thanks
Hello Hannes,
Nothing is wrong, I presume. Ignorance on my part.
Thanks.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Wednesday, May 17, 2006, 7:50:47 AM, you wrote:
HM> Hi Jason
>> I've put together a simple test framework and a 18 test cases to
HM> Wha
TVW>>To me it seems this is going to lead to: (unwanted)
TVW>>
TVW>>readonly public, readonly protected, readonly private
TVW>>writeonly public, writeonly protected, writeonly private
TVW>>readwrite (or regular) public, protected and private
Why one would need writeonly? I see no use for it.
--
S
Hi Jason
I've put together a simple test framework and a 18 test cases to
Whats wrong with 'run-tests.php' ? http://qa.php.net/write-test.php
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2006-05-17, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> JG>> private readable $abc;
> JG>> - doesn't make sense.
> JG>>
> JG>> protected readable $abc;
> JG>> - sub-class can read, not write
> JG>> - not visible outside class
> JG>>
> JG>> public readable $abc;
> JG>> - sub-class ca
JG>> private readable $abc;
JG>> - doesn't make sense.
JG>>
JG>> protected readable $abc;
JG>> - sub-class can read, not write
JG>> - not visible outside class
JG>>
JG>> public readable $abc;
JG>> - sub-class can read, and write
JG>> - outside class can read, not write
For me such setup
AG>>Probably because private variables do often have getters and setters,
AG>>whereas something which is marked as read-only (like a harddrive)
AG>>tends to be read-only always.
I think that by itself returning writable reference to such variable
voluntarily is undesirable, but not fatal - i.e.
Andi Gutmans wrote:
> All I meant was that the implementation is one step (and a very
> necessary step) but that having a patch doesn't always mean it should
> be applied right away. I just want to make sure we all think it through
> and discuss the different cases.
IMHO, it is very cumbersome t
Marcus Boerger wrote:
>private readable $abc;
>- class itself can read and write
>- public for everybody when reading, inside & outside of the class
This means that a private attribute becomes part of the public interface
of a class. I am not sure if this really is desirable.
--
Se
Ron Korving wrote:
I'm a big fan of this keyword. No "", and this is in fact clearer and
better than the readonly keyword I advocated. Great idea :)
Just a quick question because I wasn't able to test any implementation
yet: Does the new keyword conflict with functions/methods/properties o
Marcus,
I'm a big fan of this keyword. No "", and this is in fact clearer and
better than the readonly keyword I advocated. Great idea :)
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Hello Jason,
>
> i changed from readonly to readable, which means
Hello Marcus,
I've put together a simple test framework and a 18 test cases to
start with. It's a stand-alone system that should work correctly
on PHP 5 installs. Both CLI mode and Web Server mode work fine.
NOTE: The tests I wrote are only testing standard functionality. We
need to a
Hello D.,
Wednesday, May 17, 2006, 1:28:26 AM, you wrote:
> Jason Garber wrote:
>> CS> Does anyone apart from me wonder why we need to bloat the language for
>> CS> an obscure feature like this? Please take a step back, take a deep
>> CS> breath, count to 10 and that's *really* what the PHP comm
Jason Garber wrote:
CS> Does anyone apart from me wonder why we need to bloat the language for
CS> an obscure feature like this? Please take a step back, take a deep
CS> breath, count to 10 and that's *really* what the PHP community has been
CS> waiting for.
Please consider that not everyone d
Hello Christian,
CS> Does anyone apart from me wonder why we need to bloat the language for
CS> an obscure feature like this? Please take a step back, take a deep
CS> breath, count to 10 and that's *really* what the PHP community has been
CS> waiting for.
Please consider that not everyone does t
Marcus Boerger wrote:
i changed from readonly to readable, which means the new keyword makes it
public for any read access, that is:
So much for "readable" being obvious (i.e. you have to explain it).
private readable $abc;
- class itself can read and write
- public for everybody w
Hello Andi,
Tuesday, May 16, 2006, 11:09:51 PM, you wrote:
> Hi Marcus,
> I don't see why everything is always personal for you.
Na. Don't get me wrong here. I am just trying to express that what we did
in the past didn't really work out. The conservative behavior of adding
new features late if
Hello Jason,
i changed from readonly to readable, which means the new keyword makes it
public for any read access, that is:
private readable $abc;
- class itself can read and write
- public for everybody when reading, inside & outside of the class
protected readable $abc;
- clas
Hello Marcus,
Is this correct?
private readable $abc;
- doesn't make sense.
protected readable $abc;
- sub-class can read, not write
- not visible outside class
public readable $abc;
- sub-class can read, and write
- outside class can read, not write
If not, please cl
Hello Jason,
write testcase, write in a way that they capture any usage you can
think of. Parameter parsing, reference handling returning, inheritance,
trying to circumvent the whole stuff, checking all error messages are
in place, overloading internal objects that have special handlers just
to
Yeah you can take a look at internal functions/classes that operate
on objects and see whether the readonly semantics might need to work
in some of those cases.
Thanks for the offer!
At 02:59 PM 5/16/2006, Jason Garber wrote:
Hello Andi,
Your request for edge condition research is an excel
Hello Andi,
Your request for edge condition research is an excellent one. We've
just been through a hellish couple weeks of QA failures (at my
company) which just *underscore* your point. The last thing any of
us needs is a broken PHP.
That being said, is there anything I can do to he
Hello Andi,
nothing else needs to be fixed. The patch considers a reference as a write
operation as well as anything else that doesn't identify itself as a read
operation. And the enforcement itself just means that whatever you define
besides readable is being ignored for read operations.
best
Where would readable be enforced? Would it try and prevent getting
references to it? Are there any internal functions/classes which need
fixing to honor readable?
I think these answers would really be helpful.
Thanks.
Andi
At 02:37 PM 5/16/2006, Marcus Boerger wrote:
Hello Andi,
that is
Hello Zeev,
Tuesday, May 16, 2006, 11:08:57 PM, you wrote:
>> Anyway it adds complexity to what you
>>have to learn about PHP. In fact seeing two visibility keywords separated
>>by a colon should be easy enough to understand for everybody.
> I'll be blunt as it's late here, but that's just
Hello Andi,
that is why most here already switched to "public readable".
best regards
marcus
Tuesday, May 16, 2006, 11:31:14 PM, you wrote:
> I can't quite explain it but for me the ability to work-around
> private with methods which are able to access the private variable,
> is different t
I can't quite explain it but for me the ability to work-around
private with methods which are able to access the private variable,
is different than marking a property as read-only but it not being
read-only in all semantics. Probably because private variables do
often have getters and setters,
Hi Marcus,
I don't see why everything is always personal for you. As I mentioned
numerous times in the past, having an in-depth discussion about
features, both their implementation, affect on language semantics,
and relevance to PHP is very beneficial for all. All I meant was that
the impleme
At 21:33 16/05/2006, Marcus Boerger wrote:
Hello Andi, hello List,
this patch does not introduce a new keywors and thus comes with a whole
set of problems canceled out already.
I think that it's absolutely horrible syntax wise :) private:public $foo?
Anyway it adds complexity to what you
Hello Andi,
however the past has tought of something. Nobody will test a patch.
That said there won't be any feedback until it gets into at least head
and people feel confident they should experiment with it. As it stands
now you could just take it as a decision against it and be done.
best reg
On Tue, May 16, 2006 3:44 am, Ron Korving wrote:
> Like you, I don't see why a 'readable' keyword should make things any
> more
> complicated for beginners, because indeed, it is optional and
> beginners will
> simply not use it. To me, this only shows the strength of PHP:
> suitable for
> beginner
I suggest to wait for a response about the edge cases question I sent
out (i.e. returning a writable reference of this readonly property).
I for one haven't quite understood what the semantics will be in all
the edge case situations. Although I think the concept is interesting
(and somewhat ben
Marcus Boerger wrote:
btw, i wonder where the people are that usually complain about my patches?
Is this finally something most people like?
Maybe you built a nuclear power plant.
Dante
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Hello Andi, hello List,
this patch does not introduce a new keywors and thus comes with a whole
set of problems canceled out already. Anyway it adds complexity to what you
have to learn about PHP. In fact seeing two visibility keywords separated
by a colon should be easy enough to understand for
Sebastian Bergmann wrote:
Stefan Walk wrote:
I'm against visible private variables. If they are visible, they are
part of the interface of the class, which means changing the
implementation means a BC break.
This is a valid point against readonly, indeed.
no, it is a valid point against im
Stefan Walk wrote:
> I'm against visible private variables. If they are visible, they are
> part of the interface of the class, which means changing the
> implementation means a BC break.
This is a valid point against readonly, indeed.
--
Sebastian Bergmann http://www.sebas
That's a good point. It was just an idea really, hoping to provide an easy
way out for the whole discussion ;)
Ron
""Stefan Walk"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
On 5/16/06, Ron Korving <[EMAIL PROTECTED]> wrote:
>
> class Foo
> {
> private $bar = 5;
> }
>
> $
On 5/16/06, Ron Korving <[EMAIL PROTECTED]> wrote:
bar; // prints 5
$foo->bar = 4; // error
?>
I'm against visible private variables. If they are visible, they are
part of the interface of the class, which means changing the
implementation means a BC break. If this functionality is going in
"Zeev Suraski" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> ...
> Regarding whether it's an access level or a modifier, I think that an
> access level is better since you don't have to explain a matrix of 6
> different behaviors (including one that doesn't make sense, but stil
Ron,
As I've said numerous times in the past, it's not about what
beginners use or not, it's about whether it's in the language or not.
Additional keywords and structures make the language more
complicated. It's an axiom. Look at PHP 5 books vs. PHP 4 books,
including books for beginners.
Ron Korving wrote:
Like you, I don't see why a 'readable' keyword should make things any more
complicated for beginners, because indeed, it is optional and beginners will
simply not use it. To me, this only shows the strength of PHP: suitable for
beginners and suitable for the enterprise.
Lea
This is absolutely true. Besides, adding a new access level automatically
implies that you'll probably never be able to extend it to protected as
well, because you'd need yet another access level and I really doubt people
are going to want to do that. But at that point, it would be too late to
Would a method be able to return a writable reference of this
readonly property? If not it'd actually be PITA to prevent this. This
is one of those questions which can turn a two second patch by
Marcus, to an ongoing patch where we continue to fix various places
and continue to bloat the langua
Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
hm ... this was not supposed to get out as i had seen your reply
to yourself ...
--
Hartmut Holzgraefe, Senior Suppo
Hello Zeev,
In the same way that public readonly properties would be useful
from the global scope, protected readonly properties would be just
as useful to those of us who spend their php-lives writing base
classes (like me) for others to extend and use.
I would imagine that the Zend Fr
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Zeev Suraski wrote:
> I have to say that in second thought (after realizing what you really
> meant) it sounds like a very useful feature.
[snip]
> In order to push complexity down I'd avoid making this yet another
> modifier, and in fact make thi
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/tra
I have to say that in second thought (after realizing what you really
meant) it sounds like a very useful feature.
The main thing that worries me is the complexity to the end user,
which is already in a pretty bad shape as it is today, and many
people here care very little about it, because th
Strike that, I was smoking something strong :) Class constants are
not really relevant for this use case.
At 20:57 15/05/2006, Zeev Suraski wrote:
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrot
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrote:
I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code
size h
Hello internals,
sorry the patch got lost somehow, here it is :-)
regards
marcus
Sunday, May 14, 2006, 10:12:12 PM, you wrote:
> Hello guys,
> after some incantations i came to the attached improved patch that
> allows to give properties any visibility plus mark them as public
> readable.
Hello guys,
after some incantations i came to the attached improved patch that
allows to give properties any visibility plus mark them as public
readable. The patch also implements the PHP 6.0 todo item 'readonly
for overloaded objects'.
The code now looks like:
x);
?>
Note, that this adheres
Hello Jason,
Sunday, May 14, 2006, 4:34:03 AM, you wrote:
> Hello Marcus,
> class x
> {
> public readonly $xyz;
> protected readonly $abc;
> }
> Definitions:
> - public readonly- outside class can only read, not write.
> - protected readonly - subclass can only read, n
Hello Marcus,
class x
{
public readonly $xyz;
protected readonly $abc;
}
Definitions:
- public readonly- outside class can only read, not write.
- protected readonly - subclass can only read, not write.
- private readonly - does not make sense - do not support.
Ho
Definatly would love to see readonly, It would remove 1000's of lines of
useless code from 100's of projects - which might make a few more public
PHP projects readable ;)
It replaces pointless giberish with something explicit clean and elegant..
Looks alot tidier than getters, or __get kludges.
Hello Sara,
while all what you wrote is doable i'd suggest a slightly different
approach. If the name of the variable is prefixed with "r_" and written
from outside the class an error will be issued.
There's only one thing to be considered. The proposal cannot work for
overloaded internal objec
Hello Etienne,
Friday, May 12, 2006, 2:11:38 PM, you wrote:
> Hi,
> my 2c:
> 1) it shouldn't replace the visibility definition: we could also have
> protected readonly properties.
same here visibility and read/write control are two seperate things.
> 3) how would you check if the property if
Jason Garber wrote:
> Would it be possible to create a new object property attribute:
> readonly
Why not make it a little more generic? Say, make readonly an attribute that
applies to the ppp tags as opposed to making it a new access class.
Eg. if a member is 'public readonly' then it's r
Jason Garber wrote:
There are a lot of casual users of PHP. There are also the people
out there who are buying the Zend products, buying the MySQL support
contracts, using PHP at Yahoo! -- the people who have chosen to use
PHP OVER Java/.NET/Perl, because it is a great language -- the
Andi Gutmans wrote:
I can take any feature in PHP and add features :)
Is that an offer ;-)? I've got a couple you can add, lol.
Dante
At 01:44 PM 5/12/2006, Jason Garber wrote:
Hello,
PHP implements many features, and skips many features. I think the
rule of thumb needs to be that if
Etienne Kneuss wrote:
Yes, I also consider the visibility as a candy functionality.
Etienne Kneuss wrote:
2) It only requires a bit of discipline, not to edit the properties you
want to be readonly.
well, then we don't need private/protected/public at all,
as it only requires a
Yes, I also consider the visibility as a candy functionality.
> Etienne Kneuss wrote:
>> 2) It only requires a bit of discipline, not to edit the properties you
>> want to be readonly.
>
> well, then we don't need private/protected/public at all,
> as it only requires a bit of discipline not to a
I can take any feature in PHP and add features :)
At 01:44 PM 5/12/2006, Jason Garber wrote:
Hello,
PHP implements many features, and skips many features. I think the
rule of thumb needs to be that if a feature is implemented, finish
it.
For example, if you provide __get() and __set()
Hello,
PHP implements many features, and skips many features. I think the
rule of thumb needs to be that if a feature is implemented, finish
it.
For example, if you provide __get() and __set(), provide an
efficient way of handling the normal use case.
If you start triggering an E_NO
It seems to me this would be a great option to add. How difficult would it
be? Would it take significant editing of the source code? I don't see the
issue in adding it - seems like it would have plenty of places to be used.
Though, if it is added, the name 'readonly' seems a little misleading. It
Bastian Grupe wrote:
Blame my recent use of Java here ;-)
Well, I think the whole point of ppp is to having to use setters and
getters consistently.
i'm going to blame your use of Java for this one, ppp is way older
than the setter/getter fashion and as far as i remember the main
reason to in
Hartmut Holzgraefe wrote:
Bastian Grupe wrote:
You didn't want to return $bar in your example, you wanted
to return $this->bar so you already ran into one of the
issues here ;)
Blame my recent use of Java here ;-)
Well, I think the whole point of ppp is to having to use setters and
getters
Bastian Grupe wrote:
Uhh... how about using private and only using a "regular"
getter (the Java-style) and no setter?
class xx
{
private $bar;
public getBar() { return $bar; }
}
i think you're missing the point, the idea is to *not*
have to write that extra getter line ..
Etienne Kneuss wrote:
2) It only requires a bit of discipline, not to edit the properties you
want to be readonly.
well, then we don't need private/protected/public at all,
as it only requires a bit of discipline not to access the
properties you want to be visible to the class or its
children o
__get() and __set() are great, but 90% of the time, I find myself
using them to create public readonly properties.
I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code size has
already made it harder to m
Jason Garber wrote:
Would it be possible to create a new object property attribute:
readonly
class xx
{
readonly $bar;
}
$o = new xx();
$o->bar = 10;
>>> FATAL ERROR
This way, PHP would allow reading (as if it were public), but only
allow writing from within th
I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code size
has already made it harder to maintain and it has the potential to
make PHP far more complicated than what it should be.
At 04:35 PM 5/11/2006, Jason
Hi,
my 2c:
1) it shouldn't replace the visibility definition: we could also have
protected readonly properties.
2) It only requires a bit of discipline, not to edit the properties you
want to be readonly.
3) how would you check if the property if readonly ? Trying it could
result to a Fatal err
Hello internals,
__get() and __set() are great, but 90% of the time, I find myself
using them to create public readonly properties.
The only problem with this is it is horridly inefficient, consuming
at least 1 function call and one switch statement (or equiv) per
property read.
Woul
84 matches
Mail list logo
