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 5/17/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1 for E_RECOVERABLE_
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
Bonsoir
Ilia Alshanetsky wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-0
I don't like it , but we can easily get over.
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
We rarely use it, and I think alan's way is ok for those using it massively.
So
Bonsoir
Pierre wrote:
Why don't you ask for an access to the wiki and update this list there?
-- Pierre
You need access to that ?
--
toggg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 internals,
i already admitted that i had an oversight in my tons of patches while
going down the PHP 5.2 TODO list. Now i am really overwhelmed by the fact
that indeed people were pointing me to decisions. WOW, that must be a first.
I hope i can point others to decisions as well. Look at t
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 Sebastian,
there is a technical issue besides slowdown. We have to work around the
fact that suddenly a function might get $this as a normal variable (remember
the examples give on this list included that). Right now $this is handled by
a special zval not stored in the local or global symo
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
Translating the documentation to Hungarian
Dokumentáció magyarra fordÃÂtása
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
> Let's keep this number of lists to the minimum. Thanks to Lukas, we
> already have a wiki with all this information, lets keep using it, the
> release process is complex enough already without having to scramble
> around looking for information on dozens of websites.
Spea
Let's keep this number of lists to the minimum. Thanks to Lukas, we
already have a wiki with all this information, lets keep using it,
the release process is complex enough already without having to
scramble around looking for information on dozens of websites.
On 17-May-06, at 12:19 PM, P
On Wed, 17 May 2006 17:19:06 +0100
[EMAIL PROTECTED] (Phil Driscoll) wrote:
> On Wednesday 17 May 2006 16:47, Martin Jansen wrote:
> > OS X, preferably both on the Intel- and the PowerPC-platform.
> added to
> http://www.dialsolutions.com/phil/php/primarytesters.html
> :)
Why don't you ask for an
On Wednesday 17 May 2006 16:47, Martin Jansen wrote:
> OS X, preferably both on the Intel- and the PowerPC-platform.
added to
http://www.dialsolutions.com/phil/php/primarytesters.html
:)
--
Phil Driscoll
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
OS X, preferably both on the Intel- and the PowerPC-platform.
Oh yes. I need to be able to develop on my MacBook Pro.
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
At 04:26 PM 5/16/2006, Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic st
On Tue May 16, 2006 at 09:5439PM +0100, Phil Driscoll wrote:
> I guess as well as a software list, we need an important platform list so we
> know that an RC has been exercised on at least:
> Linux X86 Apache module
> Linux X86_64 Apache module
> BSD Apache module
> Solaris Apache module
> Windows
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
Phil Driscoll wrote:
To move this process forward, is there any chance that you could make a few
changes to http://oss.backendmedia.com/ReleaseChecklist?
I have added a link to your post as a comment in the page. Since I am
not an RM I will leave it to Ilia and Derick to incorporate these ide
> There are 2 PHP 5.2 changes there has been a lot of back and
> forth flaming going around and we need to finally come to a
> decision about.
>
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
> Addition of support for dynamic statics ala: class foo {}
> fo
So -1, and some rethinking needed about the way E_STRICT is used ('this is
the way you should do it' vs 'this is the way you will have to do it in
future')
Going on from there - if E_STRICT is now being touted as 'deprecated stuff
only', would it be a good idea to have something like E_DEVEL f
Bonjour,
Greg Beaver wrote:
Sebastian Bergmann wrote:
Ilia Alshanetsky wrote:
For every RC we already send an e-mail to about 12 projects asking them
to test their code against the release and let us know of any issues
that come up.
Sadly, this does not seem to work. Maybe because nobody
On 17-May-06, at 2:10 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I do
Sebastian Bergmann wrote:
> Ilia Alshanetsky wrote:
>
>>For every RC we already send an e-mail to about 12 projects asking them
>>to test their code against the release and let us know of any issues
>>that come up.
>
>
> Sadly, this does not seem to work. Maybe because nobody from the
> projec
Jasper Bryant-Greene wrote:
I'm not necessarily suggesting that a release be delayed because *my*
application doesn't work, I'm just offering to test RCs against it and
report any bugs that it turns up. If the bug is found to be with PHP and
is sufficiently serious, then perhaps the release will
Lukas
To move this process forward, is there any chance that you could make a few
changes to http://oss.backendmedia.com/ReleaseChecklist?
First add an extra item to 'Getting the Release Candidate out there' saying:
Email [EMAIL PROTECTED] to notify the primary testers to get
testing. An example
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
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
E_RECOVERABLE_ERROR's apparently going in anyway.
E_STRICT, I'd be all for including into E_ALL now if it weren't for the
'semi-statics' issue (complex) and the dist
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
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
I am not glad with E_RECOVERABLE_ERROR at all, but if it went into 5.2 it
should be included into E_ALL, becouse in most cases it substitute E_ERROR
messages.
E_STRICT +0
E_RECOVERABLE_ERROR +1
> Addition of support for dynamic statics
Ilia Alshanetsky wrote:
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
-1
--
Etienne Kneuss
http://www.colder.ch/
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Ilia Alshanetsky wrote:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Changing the behavior of error reporting can have some implications on
servers where it is intended to not show errors at least with E_STRICT
errors.
Addition of support for dynamic statics ala: class foo {}
At 02:26 17/05/2006, Ilia Alshanetsky wrote:
There are 2 PHP 5.2 changes there has been a lot of back and forth
flaming going around and we need to finally come to a decision about.
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1
Addition of support for dynam
Robin Ericsson wrote:
> The big whohoo would be a complete PHPUnit test framework for PHP with
> code coverage that replaces the old test framework.
As long as PHPUnit cannot run each test in a new PHP interpreter
process this would make no sense. And even then, why would we want to
replace run
On 5/17/06, Sebastian Bergmann <[EMAIL PROTECTED]> wrote:
I have brought this up before. Sebastian Nohn has taken up this idea and
set up a box that checks out PHP from CVS, builds it, and then runs
"make test" as well as the unit tests of projects like PHPUnit and the
Zend Framework.
The b
Markus Fischer wrote:
> Is there any software out there which uses PHPUnit(2)? So those
> automatic suites could be used as well.
I have brought this up before. Sebastian Nohn has taken up this idea and
set up a box that checks out PHP from CVS, builds it, and then runs
"make test" as well as t
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.
Ilia Alshanetsky wrote:
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
-1/+1
E_RECOVERABLE_ERROR has to be in as it's taken over some previously E_ERROR
situations.
It's probably too soon for E_STRICT right now, although it should be enabled in
some 5.x.0 rel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phil Driscoll wrote:
> On Tuesday 16 May 2006 21:35, Richard Lynch wrote:
>> Would it be worth having a checklist of "must-have" software?
>>
>> It's easy to see something big getting missed just because "Joe" is on
>> vacation or too busy to test, and
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
Am Mi, den 17.05.2006 schrieb Ilia Alshanetsky um 1:26:
-1 for E_STRICT in 5.x
/Georg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
Sebastian Bergmann wrote:
>> Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
>
> -1
Apparently I had the wrong context when I read a posting by Marcus on
technical issues (slowdown).
If there are no technical issues with implementing this, then I am -0
on this.
--
On Wednesday 17 May 2006 02:26, Ilia Alshanetsky wrote:
> There are 2 PHP 5.2 changes there has been a lot of back and forth
> flaming going around and we need to finally come to a decision about.
>
> The two topics are:
>
> Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1
> Addition o
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
Ilia Alshanetsky wrote:
The two topics are:
Inclusion of E_STRICT and E_RECOVERABLE_ERROR into E_ALL
+1 for E_RECOVERABLE_ERROR as it's been E_ERROR before
-1 for E_STRICT, though
Addition of support for dynamic statics ala: class foo {} foo::$bar = 1;
+1, half-heartedly
Regards,
--
Mich
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
54 matches
Mail list logo
