On May 6, 2008, at 12:21 PM, Lars Strojny wrote:
I think this is too unspecific. At least the visibility, setter and/or
getter and type-hint (assuming we will have type hints) should be
defined. Otherwise defining properties in interfaces become useless as
it does not tell somebody more except
On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
public $property {
__get = getProperty;
__set = setProperty;
}
string public function getProperty() {
return $this-_property;
}
string protected function setProperty(string $value) {}
Hi Marcus,
I prefer this approach.
One advantage is
Hi Marcus,
I think this is really specifying implementation details in an
interface:
interface Coordinate {
public $coord = __get = getCoord, __set = setCoord,
__isset = hasCoord, __unset = delCoord;
public getCoord();
public setCoord($val);
public hasCoord();
public
On Apr 29, 2008, at 3:15 AM, Sebastian Bergmann wrote:
John Carter -X (johncart - PolicyApp Ltd at Cisco) schrieb:
could you explain why Interfaces can't have properties
Because interfaces are implemented which makes no sense for
attributes.
Sebastian,
This is true for the data
On Apr 4, 2008, at 4:18 AM, Derick Rethans wrote:
http://youngbloods.org/essays/argument_for_goto.html has an IMO good
example. It's java code, but it shows how goto can help you get rid of
nesting hell.
Hi Derick,
The code in that example looks more like an argument for try ...
finally
Hello,
Reading the prior discussion, I think either $_SCOPE['x'] or the
lexical $x syntax is fine for accessing local variables in the
enclosing scope. But closures also should also support $this and
static:: when the closure is defined in a method.
I think a solution for closures
On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
I'm assuming that making the function above GC-able would be a
herculean task
at this point, based on previous comments, but I do not actually
know myself.
Hi Larry,
Let me use a different example than yours.
function getAdder($x) {
Hello Ralph,
I don't think properties are the appropriate level to specify
namespace based access modifiers. I do think that a coarse-grained
access restriction on a class by class basis might be.
public class Foo {} // Default
private class Foo {}
(protected is meaningless because there
Hi,
May I suggest renaming get_called_class() to get_static_class() to
correspond with the use of the static:: keyword for late binding.
parent:: and get_parent_class() [no parameters] should also correspond
when used in a static method context.
My preference is that parent:: be late
On Jul 11, 2007, at 4:43 PM, David Wang wrote:
On the Template test, maxmium memory usage with unmodified PHP was 1.5
GB with an execution time of 30 seconds.
On the Template test, maxmium memory usage with gc was 67.3 MB with an
execution time of 1 minute.
...
As you can see,
there is the
David,
On Jul 14, 2007, at 1:55 PM, Rasmus Lerdorf wrote:
It is still extremely rare for code to have cyclic references. So
while
GC could prevent swapping in the case of a malicious user, or in the
case of a coding mistake, I don't think the general case of typical
code
running under
Hi,
Sorry, I'm coming to this discussion a bit late and perhaps I don't
understand the all issues, but I think the scope of creating an ORM
for PHP is probably too large. Let me suggest a smaller project that
could lead to better ORM.
PHP has several methods of serializing and
On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote:
Bottom line is that does not, there are plenty of Perl application
supposedly safe from XSS due to tainting while in reality are
trivially exploitable via XSS due to the fact validation regex which
does the un-tainting of data is sub-par.
On Dec 15, 2006, at 7:47 PM, Andi Gutmans wrote:
Time to turn it off in php.ini-dist in addition to php.ini-recommended?
Time to rename php.ini-dist and a php.ini-recommended to more clearly
represent specific usage profiles, like development and production?
Perhaps the production or
On Dec 16, 2006, at 11:54 AM, Derick Rethans wrote:
On Fri, 15 Dec 2006, Andi Gutmans wrote:
Time to turn it off in php.ini-dist in addition to
php.ini-recommended?
I would instead change them to php.ini-development and
php.ini-production. In development you'd want to have this stuff on..
On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are
common
which is true for PHP. Actually in PHP static methods are inherited as
any
other method (also true for a lot of other languages). Now given Liskov
rules you can as
On Aug 4, 2006, at 3:23 AM, Derick Rethans wrote:
- Add a new flag to methods (at the implementation level) that will
allow to flag them as 'strict'
Hello,
Would exposing this flag to the user at method level get a bit verbose
for those who want to use it? Perhaps a class level flag for
On Jul 15, 2006, at 11:29 PM, Sara Golemon wrote:
One minor thought I'd offer up is an option INI setting to disable
creation of the opcode. This allows the #line directives to be used
in dev/debug environments without causing an impact for production
servers during execution. It's not a
On Jul 12, 2006, at 11:56 AM, Lukas Smith wrote:
Therefore my proposal would be to simply add a defined header to all
E_STRICT messages that contains the PHP version in which this E_STRICT
message was added.
Hi Lukas,
An alternative might be to implement numerical error code identifiers
Hello Stanislav,
On May 17, 2006, at 5:25 PM, Stanislav Malyshev wrote:
JMindividual properties, just as you can in Java, C#, Ruby, Delphi,
JMPython, Visual Basic, Objective C, Smalltalk, and sometimes C++.
(To
JMthe best of my knowledge.) Read only is a special case of this
JMcapability.
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#:
On May 13, 2006, at 7:18 PM, Marcus Boerger wrote:
hehe, maybe confused with delphi or borlands c++ additons? Speaking
of
which before we add 'readonly' we should go for full property support
but
on the other hand that might be a little bit too much until php is used
with code generators
On Mar 1, 2006, at 9:50 PM, Andi Gutmans wrote:
Yeah static is very confusing and I think it's a bad idea.
I'm trying to think what a non-confusing way would be. Some ideas
would be:
a) using class e.g. class::method()
b) change behavior of self:: to always be virtual and have people
use
On Mar 2, 2006, at 11:33 AM, Mike Lively wrote:
Hi Mike,
In regards to naming: 'static' wasn't my first choice either. In fact I
was originally using 'this::' due to me misreading the notes from the
PDM.
Does 'this' work ok? I like that one. this:: and $this would both be
late binding
On Mar 2, 2006, at 2:23 PM, Andi Gutmans wrote:
Do you expect significant BC breakage?
Hello Andi,
Here is an example where changing self to late binding would change
behavior:
class A {
static $a = hello world;
static function getA() {
return self::$a;
On Mar 1, 2006, at 9:37 AM, Dmitry Stogov wrote:
1) I would very like to see some real example where static is
necessary?
Some use cases for late static binding, tested using self on 5.1.2:
1. What class am I really?
class A {
static function myclass() {
return get_class();
On Mar 1, 2006, at 3:45 PM, Jeff Moore wrote:
static protected function configure($obj) {
$obj = 'A';
}
Oops. That should be $obj-iprop = 'A'.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 23, 2006, at 5:06 PM, Mike Lively wrote:
I also added a new function get_caller_class() which returns the name
of
the class that static:: would represent.
I find get_caller_class() a bit confusing because it introduces new
terminology (caller). May I suggest adding:
On Feb 27, 2006, at 12:49 PM, Mike Naberezny wrote:
The code below echoes it works on PHP_5_1 and HEAD but raises a
notice on the other branches.
excellent! It seems this can be closed then?
http://bugs.php.net/bug.php?id=29070
Regards,
Jeff
--
PHP Internals - PHP Runtime Development
On Feb 25, 2006, at 4:47 AM, Michael Vergoz wrote:
You see function what need a prevention ? contact me
[EMAIL PROTECTED]
Hello,
How about one that needs less prevention? Would this patch (or another
like it) allow for the elimination of the current recursion guard for
__get, etc?
On Jan 28, 2006, at 4:08 PM, Kevin Waterson wrote:
To give SplObjectStorage a better name. My best suggestion is
SplUniqueObjectContainer. There may be a better choice.
Why not just call it Betty.
Why not? Betty is only slightly more vague than Storage. A vague
name is nobody's
On Jan 30, 2006, at 1:33 PM, Johannes Schlueter wrote:
SplObjectStorage is some thing which stores objects, that can be
read out of
the name so it at least gives an idea and compared to your
SplUniqueObjectContainer it's quite short.
There are many ways to store objects. Arrays can store
concept? Is
there a reason to limit this class to object members?
Best Regards,
Jeff Moore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi, Marcus,
On Jan 27, 2006, at 1:10 PM, Marcus Boerger wrote:
yes, it is a conainer and not a set.
So why not call it a container instead of storage?
And it cannot take anything other
than php objects. That's why.
SplObjectContainer?
But, then, it has that uniqueness constraint.
On Jan 27, 2006, at 10:26 PM, Marcus Boerger wrote:
what the hell do you want?
To give SplObjectStorage a better name. My best suggestion is
SplUniqueObjectContainer. There may be a better choice.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To
On Jan 21, 2006, at 11:05 AM, Lukas Smith wrote:
Maybe we should try to come up with a common approach here for
unserialize() as well?
Along with mysql_fetch_object and its cousins? I haven't yet looked at
the __set_state magic method from var_export, but isn't another side of
the same
Which is also true of OS X 10.3.9:
http://bugs.php.net/bug.php?id=34844
Compiling PHP 5.1 on 10.3.9 requires installing libxml because of a
missing parser.h in the version provided by the OS.
On Jan 6, 2006, at 4:22 PM, Jani Taskinen wrote:
This file is supposed to be wherever
On Jan 7, 2006, at 11:54 PM, Steph Fox wrote:
Jani's right. If the OS is missing a file, how's that a PHP issue?
Its not, except where people assume their os is fine and think its a
problem with PHP.
I was wrong in my previous message. Its xmlsave.h that is missing, not
parser.h. I
for an explanation of why
$this-ref = $this
is a valid usage while
$ref = $this;
is not.
Thanks,
Jeff Moore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sep 13, 2005, at 1:35 AM, Sebastian Bergmann wrote:
You can extend the interfaces ...
and adapt them to your needs while retaining the possibility to use
them
with other code that only knows about the original Subject and
Observer
interfaces.
Actually you can't and still be
release and address some of the things that people commonly want to do
with the observer pattern:
Additional notification information (push style).
A observer that can receive more than one kind of notification.
A subject that can send more than one kind of notification.
Regards,
Jeff Moore
--
PHP
of the observer pattern, but I don't see
them as generally useful enough to have as part of the language.
Regards,
Jeff Moore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 26, 2005, at 5:55 AM, Derick Rethans wrote:
I'm just arguing that the current way that setters and getters are
implemented is broken. Instead of keeping a broken behavior I would
like
to see it fixed.
Derick,
It is not broken its incomplete. PHP doesn't really have an
On Aug 25, 2005, at 8:01 AM, Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
#1)
It seems to me that after declaring the property with the property
keyword, the property isn't so virtual
On Aug 2, 2005, at 9:05 AM, Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of
the existing
documentation tools (such as phpdoc and doxygen)
This sounds like a tool problem, not a language problem.
2. There is no way how the magic
On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
This is a sweet carrot to drive adoption despite a few minor BC issues.
--
PHP Internals - PHP Runtime
On Apr 3, 2005, at 6:05 AM, Zeev Suraski wrote:
What I'd like to suggest is a change in the behavior of __autoload(),
so that multiple __autoload()'s could be defined. Essentially,
declaring __autoload() would in fact add the function to the list of
functions that are called in case a missing
On Mar 10, 2005, at 9:59 PM, l0t3k wrote:
In about a month or so, i'll start work on an extension implementing a
file
format which allows for bundling all resources related to a app
(including
PHP source, localized strings, gifs, byte-code from BCompiler etc). the
format has an heirarchical
On Mar 15, 2005, at 7:41 PM, cshmoove wrote:
read my reply to Christian. as i mentioned, i'm working on another
project which already has infrastucture for dealing with similar
issues. i simply noticed that it could be adapted for the PAR/PHAR
idea. IOW, the extension will be written whether
On Feb 2, 2005, at 3:53 PM, Rasmus Lerdorf wrote:
We have seen definitively that many application writers do not know
how to properly validate data. And yes, it is another ini thing to
worry about, and yes it will be painful, but I don't think we can
continue to ignore this. I also think that
On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can
enable in their ini file. This will strip out any XSS, quotes,
braces, etc.
I hate to see more ini options. They make it more difficult to write
programs that work under a
On Oct 25, 2004, at 8:48 AM, Lukas Smith wrote:
D Kingma wrote:
I just took a view at some PDO examples on the net and it looks
promissing. The
one thing that I would to see is that the fetch method accepts a
class name as
optional second parameter (when using PDO_FETCH_OBJ or
PDO_FETCH_LAZY)
On Jul 29, 2004, at 6:30 PM, Ilia Alshanetsky wrote:
Here are some more programming languages you may wish to discredit for
their
goto support.
C#,
The C# goto is limited: goto statements can transfer control within
blocks and out of blocks, but never into blocks. Does the PHP goto
On Jul 30, 2004, at 10:35 AM, Shaun Thomas wrote:
Paul G wrote:
function pseudocode()
{
$a=allocate_resource_z();
$b=allocate_resource_y();
$res=do_stuff();
if(!$res)
goto err_out;
$c=allocate_resource_x();
$res=do_more_stuff();
if(!$res)
goto err_out;
On Jul 30, 2004, at 4:33 PM, Edin Kadribasic wrote:
Jeff Moore wrote:
Where did the if statements go? do_stuff(), do_more_stuff(), and
do_even_more_stuff() should throw exceptions rather than return
boolean error indicators.
Now imagine do_stuff() and friends were native PHP functions ;)
You
I've been doing some thinking about how to write error handling code
that can run in both PHP 4 and PHP 5. Under the current situation, it
looks like you have to resort to the lowest common denominator of PHP 4
to make error handling code that works under both versions.
Here is a proposal for
On Thursday, June 26, 2003, at 04:09 AM, Sebastian Bergmann wrote:
I started working on a PHP Micro-Benchmark-Suite [1] to track
changes in performance between PHP releases.
Great idea.
I was reading this article this morning:
http://www.macdevcenter.com/pub/a/mac/2003/06/24/wwdc_2003.html
I remember a discussion about system calls here earlier. What is the
status of that?
I've been doing some tests and have found that this code runs about 2.5
times slower under 4.3.2 than it did on 4.1.2 on the same machine
(running OS X):
?php
$filename = 'file.html';
$fd = fopen($filename,
On Wednesday, June 4, 2003, at 12:21 PM, Rasmus Lerdorf wrote:
Uh, the number of open() calls really shouldn't change. Are you sure
you
are comparing the same code?
Yes. I am sure.
And how are you testing?
I attach fs_usage to the running httpd process and hit the script a
single time.
59 matches
Mail list logo
