Greg Beaver wrote:
By definition, if you're accessing it from another class, then perhaps
it isn't "private" at all.
in C++ "friend" gives access to both "private" and "protected" ...
This can be more easily and intuitively
solved by using protected and CoderTest extends Coder,
given that
Derick Rethans schrieb:
> A second solution is:
> http://derickrethans.nl/private_properties_exposed.php
The mechanism above is emplyed by PHPUnit 3.0 to allow testing private
and protected properties.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB8
Antony Dovgal wrote:
> On 10.01.2006 19:13, Thiago Silva wrote:
>
>> Hi,
>> can anyone review this?
>>
>> It's a one-line patch for the silent operator (@), wich currently
>> supress fatal error messages (undesirable for "@include" pehaps, wich
>> makes difficult for debugging scripts).
>
>
> Wi
On Wed, 11 Jan 2006, Tim Starling wrote:
> Suppression of fatals is an irritating misfeature. There's nothing worse
> than trying to work out where in tens of thousands of lines of code some
> idiot developer put an @ before a function invocation where the function is
> only available on some syst
I think we should avoid complicating an already complex OO
functionality. Borrowing concepts from other languages is fine, but to a
degree.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
I think we should avoid complicating an already complex OO
functionality. Borrowing concepts from other languages is fine, but to a
degree.
I think the PHP real world (not the guys porting Java APIs to PHP)
requires support binary only:
"public API"
"my break at any ti
Yep, I agree with that. And coming from years of writing C++ I barely
used friends and it always seemed kind of hackish to me.
At 06:21 AM 1/11/2006, Ilia Alshanetsky wrote:
I think we should avoid complicating an already complex OO
functionality. Borrowing concepts from other languages is fine
On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
As useful functions tend to increase in complexity over time, often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of the parameters being required
Andrei Zmievski wrote:
On Jan 9, 2006, at 4:09 AM, Aidan Lister wrote:
As useful functions tend to increase in complexity over time, often so
does the number of parameters.
It soon gets to the point where function calls look like:
foo(true, false, false, false, false, true)
The rest of the pa
Hello Aidan,
I think named parameters would be a useful feature... I'll leave it
at that.
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
{
is_null($text) && $text = SOME DEFAULT VALUE;
i
Andrei Zmievski wrote:
If you get to the point where your function has a dozen parameters, I
would suggest re-thinking the purpose and design of such a function,
because you are likely trying to make it do too much.
Obviously for most methods you should not require more than say 5
parameters
11 matches
Mail list logo
