Re: [PHP-DEV] reference caller object
W liście Chris Trahey z dnia sobota 19 września 2009:
I guess what I'm really getting at is another access modifier:
private, protected, public...
And now adding something like trusted.
trusted function myMethod() callable trustedInterface {}
In a case like this, caller would always be available, but not always
type-checked.
Or maybe just add friend classes or, since we have namespaces, something akin
default (namespace-level) accessibility?
Personally I'd be against functions behaving differnetly when called from
different contexts, it just breaks encapsulation. Also, PHP model is not
message passing (as in eg. Erlang), we have just plain function/method calls.
Also, what would be the sender/caller when executed from non-method (eg top-
level script or plain function)?
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
W liście Jonathan Bond-Caron z dnia wtorek 09 grudnia 2008: Unix timestamps are simpler since you know they are always in UTC. Just thought I'd raise that there's nothing wrong with storing all dates as ISO in a given timezone. It takes a little more work but if your consistent, it can managed. If I'm wrong, please let me know :) It's not really feasible to store dates in specific timezone, as most national/local timezones support DST - and that is a pain to support, as eg. sorting breaks when some timestamps get repeated. That's why it's usually better to store datetimes as either UTC datetime or plain unix timestamp. I usually go with the former - using database datetime type. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fatal error: Call to a member function on a non-object
W liście Christopher Vogt z dnia poniedziałek 17 listopada 2008: I have a good understanding of OOP. This is not a start for me. I am just refactoring existing PHP code to be object-oriented. You say there are plenty of reasons for a Fatal error, so please tell me a few, so I understand the reasons. You're calling a method. This requires code execution, but the code isn't there. If you were accessing a property of non-existing object (that is, if you were doing $user-fullname;) then you'd get a warning and NULL. It's not so for functions, as they're request for code execution, not for value (remember, not all functions return values as they most important effect - it's not Haskell). Calling non-existing function returns in fatal error in PHP; it's the same for: $object-iHaveNoSuchMethod(); $null-method(); nosuchfunction(); -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constants in double-quoted strings
W liście Arvids Godjuks z dnia środa 29 października 2008:
People, when you will start to learn that such approach is a mess?
First, use ' ' instead of and format your SQL better and you woun't
have any problems:
?php
define ('STATUS_ACTIVE', 1);
define ('NUM_PER_PAGE', 25);
$q = 'SELECT
ID, Name
FROM Projects
WHERE StatusID = '.STATUS_ACTIVE.'
LIMIT '.NUM_PER_PAGE.', '.$offset;
$res = mysql_query ($q);
?
It's almost the same as original poster's version (except for $offset).
a). It's more readable without syntax highlighting
b). It's just faster.
c). It's a good style.
d). I think if that is easy to do, it would be implemented a long time ago.
With regard to a and c - this is just your opinion, others might find it less
readable (or indifferent). And for b - speed difference between ' and
should be negligable (esp. with opcode caches).
I only worry it could break BC - people might have used {SOMETEXT} in
strings and not expect it to be interpolated (I've done so myself).
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: my last attempt at sanity with namespaces
W liście Ryan Panning z dnia piątek 17 października 2008: Request Autoload Gets Type --- A::B:C A::B:C Class A::B:func() A::B Namespace A::B:C::CONST A::B:C Class A::B::C:D::method() A::B::C:D Class A::B::C::D:CONST A::B::C::D Namespace I'm just a mere user, but if we go for other namespace separator (be it ::: or : or anything else), then I'd rather see it used both between namespace and class/function/constant name *and* between namespace parts. To be clear - for the examples above I'd rather have them written as: A:B:C A:B:func() A:B:C::CONST A:B:C:D::method() or A:::B:::C, A:::B:::func, A:::B:::C::CONST. That way :: is just operator for static class access (static methods and properties), while : or ::: is just namespace access operator, so we can always assume that anything on the left side of ::: or : is a namespace. In Ryan's version :: is sometimes static class access operator, sometimes namespace segment separator, depending on position. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations Request
W liście Volodymyr Iatsyshyn z dnia czwartek 21 sierpnia 2008:
Now I use emulation of Java Annotations. I wrote simple class, that uses
PHPDoc block, gets annotations declarations and their arguments, uses
eval() to convert arguments string to array, then I create instance of
class and assigns parameters. This solution is fine just now, but it
will be very cool to have annotations as language feature. I'm pretty
sure that lots of frameworks would like this feature :-)
I understand, as I'm simulating those myself (although in a different way).
But we'd love annotations for situations such as the one I presented before,
as well as WSDL generation etc.
Instead of using annotations we use something like that:
class X {
public static myMethod_methods = array('POST', 'GET');
public static myMethod_access = 'any';
public function myMethod() {}
}
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotations Request
W liście Marcus Boerger z dnia środa, 20 sierpnia 2008:
Hello Volodymyr,
Basically there is no need for annotations in PHP unlike there is in Python
for instance. However, while the following work:
php -r 'class T { const C=42; var $p=T::C; } var_dump(new T);'
php -r 'class T { const C=42; const D=T::C; } var_dump(new T);
the next two do not:
php -r 'class T { const C=42; var $p=T::C + 1; } var_dump(new T);'
php -r 'class T { const C=42; const D=T::C + 1; } var_dump(new T);
So you might want to have full support for evaluated consts/default values.
I don't really get your point. Annotations are not about constant values, but
about adding arbitrary attributes to classes and methods/functions.
A simple use case (in pseudocode):
class MyController extends BaseController {
// www.example.com/index
@allow('any')
@method('get')
public function index() {
}
// www.example.com/comment
@allow('any')
@method('post')
public function comment() {
}
// www.example.com/admin
@allow('admin')
@method('get')
public function admin() {
}
}
class BaseController {
public function _execute() {
$action = $this-parseTheUrl();
$method = new ReflectionMethod($this, $action);
if ($method-annotations('method') != $_SERVER['REQUEST_METHOD']) {
return $this-methodNotAllowed();
} elseif (!
$this-currentUser-hasPrivilege($method-annotations('allow')) {
return $this-forbidden();
} else {
return $this-$action();
}
}
}
Python does not need annotations, as functions can have arbitrary attribute
set:
def a():
pass
a.x = 5
It also has very powerful mechanism of decorators, which are basically
higher-order functions applied to functions on their definition, but I don't
think Volodymyr asks for so much.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
W liście Rasmus Lerdorf z dnia poniedziałek, 21 lipca 2008: It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') Only if comparing to a static string, but not for this case: if (substr($path, -strlen($extension)) == $extension) Readability would also increase. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Using Network functions.
W liście Mangol Smith z dnia czwartek 26 czerwca 2008: But, doesn't this make my extension depend on Curl or any PEAR extension you are talking about? That is what I wan't to avoid. Are you sure you even need to write your own extension? If you just want to do HTTP requests, then curl or HTTP extension should be sufficient. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
W liście Stefan Esser z dnia wtorek 24 czerwca 2008: The problem here is that newer Asian systems will use UTF-8 (except those nations using characters not possible in utf-8) and therefore the customers of the PHP developers (on this list) will not need that support. UTF-8 can express all characters in the Unicode. Do you mean that unicode still lacks some characters for asian languages used today? -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
W liście Stanislav Malyshev z dnia czwartek 03 stycznia 2008:
type-hinting is asserting.
checking of types is needed only on interface-border points (where
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
foo($bar);
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would be
the way to go, without the need for the mess you posted. And if you know that
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
The only problem with the cast is that (integer)'abc' is 0, but it has been so
for a long time and there is no need to change it. is_numeric check solves
the problem.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Optional scalar type hinting
W liście Stanislav Malyshev z dnia piątek 04 stycznia 2008:
This code is just a good argument *FOR* type hints. When foo is:
function foo(int $bar) {...}
and you want the code to die if $bar is not integer, then foo($bar) would
be
Why would you want it? I wouldn't want my code to die, I would want it
to work.
You wrote:
With strict checking, that means instead of calling:
foo($bar);
you'd have now to do:
if(is_integer($bar)) {
// stupid foo() call would blow up if passed not integer, so I have
to manually handle it
// oh wait, actually I don't have any way to handle it - I need
foo() to be called to proceed
// so let's just
die(can't call foo() because \$bar is not integer);
}
This shows that you explicitly die() if $bar is not integer. But with strict
type hinting this is unneccessary - the script would automatically die if
$bar was not integer. In other words, with strict scalar type hinting the
above would behave just like
foo($bar)
with the only difference being the error message (in your version you've got
your own error message, automatic script failure would raise some built-in
error - which IMO should be E_RECOVERABLE_ERROR, as E_FATAL gives blano
output on production sites where display_error is 0).
Not that I care if scalar type hinting is implemented or not, I just wanted to
point out that your example is just plain wrong.
you have either an int or string representing an integer in $bar, then
foo((integer)$bar) would work just well.
And then how exactly strict typing helps you?
Here it doesn't help, but is easy to work around if you are sure you know what
you're doing. This is the same workaround that is needed if someone used
if (! is_integer($bar)) {die()}
inside of the foo method.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Just checking something before posting a bug report
Martin Alterisio wrote
?php
class Foo {
static public $foo;
function __toString() {
self::$foo = $this;
return 'foo';
}
}
$foo = (string) new Foo();
var_dump(Foo::$foo);
?
Got even stranger result here:
string(3) foo
ALERT - canary mismatch on efree() - heap overflow detected
(attacker 'REMOTE_ADDR not set', file 'unknown')
So I confirm your problem (var_dump should report object, not string).
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : Namespaces and __autoload()
W liście LAUPRETRE François z dnia środa, 12 września 2007 12:38:
What do you mean by try both? Could you explain a bit more on that?
Yes. PHK's autoload handler is not filename-based. It works as a (poor
man's :) runtime linker, with a symbol map. In this map, interfaces and
classes have different symbol types. Today, when this handler receives a
request, it cannot know if it should look for an interface or a class. So,
it has to search both in turn.
Please consider that filename-based autoload handlers are just a primitive
implementation. If you consider only this family of handlers, that's right:
getting the symbol type is not very important. But, with smarter map-based
autoload handlers, it becomes very interesting to extend the feature to
functions and, there, providing the symbol type along with the requested
value becomes mandatory.
But how can interpreter know if it's looking for class or interface? There are
obvious cases (class X implements Y, class A extends B, interface A extends
B), but what with following language construct:
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's looking for
interface or class. Both are possible.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : Namespaces and __autoload()
W liście Stut z dnia środa, 12 września 2007 15:59: LAUPRETRE François (P) wrote: From: Stut [mailto:[EMAIL PROTECTED] This would need to come from the user implementation of __autoload through naming conventions or a lookup table. PHP does not get involved with resolving a type to a filename, and rightly so. The question is not to have PHP get involved in the symbol to filename correspondance. I have a lookup table, but the requested type must come from the interpreter context and, if the autoload handler does not get it, it cannot know what type to look for in its lookup table. Unfortunately, even if not very common, a function and a class can have the same name. In this case, there will be two entries in the lookup table. If I don't know which type is requested, I can only search all known types. Maybe it would be enough but it wouldn't be elegant nor efficient, especially if we extend the mechanism to functions and constants. I agree that if the autoload mechanism were extended to functions and constants (which I am opposed to, not that anyone will care) there would need to be a type provided to __autoload so it knew what it was looking for. However, this surely doesn't apply to classes and interfaces since the interpreter has no way of knowing and no reason to care what a particular symbol is since the two are interchangeable. But is that flag really needed? If the code has some naming rules, then those can be used to determine what we're looking for - for example: something - a function SOMETHING - a constant Something - a class ISomething - an interface (although distinguishing between classes and interfaces is not strictly necessary as those are quite similar). So if such distinction is necessary, it can be coded for specific project, using such rules as a hint or as strict rule, depending on needs. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : Namespaces and __autoload()
W liście Stanislav Malyshev z dnia środa, 12 września 2007:
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's looking
Actually, in this case (and in any case where type of existing object is
checked) autoloading is unnecessary (and it's a bug if it happens) since
if the type Service is not loaded, there can be no objects of this type,
thus we can decide the question of is object s of type Service without
loading anything - the answer would be no.
All right, seems it was fixed in the meantime -
http://bugs.php.net/bug.php?id=39003
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref
W liście David Wang z dnia wtorek, 4 września 2007 16:24: http://zoo.cs.yale.edu/~yw226/macros.diff.txt Comments? +#define always_inline inlinue Shouldn't that be +#define always_inline inline ? (in zend.h) -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about Namespace patch
Stanislav Malyshev wrote: working with a large library and have to import a lot of classes, the way this works is nothing but a pain. We would be better off not using namespaces at all, in this case. Thus, the problem has not been solved. Once more, you DO NOT have to import a lot of classes. Please do read what I write. You SHOULD NOT import classes in global space. Namespaces are NOT the way to bring all classes in global space, and it should not be done. OK, so suppose I want to have four namespaces for my project: MyApp for some shared code, MyApp::Model MyApp::Controller MyApp::View Now in many places in my code in Model I'd use some ORM library - let's assume it's similar to python's SQLAlchemy. Now is there any way for me to have access **in Model namespace** to all classes from SQLAlchemy namespace without using import SQLAlchemy::Column import SQLAlchemy::Table import SQLAlchemy::Join import SQLAlchemy::ForeignKey import SQLAlchemy::Session import SQLAlchemy::Transaction and tens of other classes? I know your patch makes it possible to use fully qualified names everywhere. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about Namespace patch
Brian Moon wrote import SQLAlchemy::Column import SQLAlchemy::Table import SQLAlchemy::Join import SQLAlchemy::ForeignKey import SQLAlchemy::Session import SQLAlchemy::Transaction Why use namespaces if you are going to do this? You are just bringing your classes into the global name space. The nice thing about namespaces IMO, is that I don't have to have a class named SQLAlchemy_Transaction. I can just have a class named Transaction in the SQLAlchemy namespace. I can then create a new object using $obj = new SQLAlchemy::Transaction. Because I just want those names directly available in one part of my application - the one which uses a lot of SQL. As far as I see this is not possibl with the proposed implementation - I can't do a local (file-scope or namespace-scope) import. All other languages I know that have namespaces (Java, python, C++) allow programmers to import other namespaces locally - usually for a single file. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recursive classes ... possible bug?
[EMAIL PROTECTED] wrote:
Dear internals,
I stumbled upon the following odd error message from PHP which I was not
expecting.
function test(){
echo $this == $this-c1-c2?'equals':'not equals'; // Somehow this
Use === (shallow test - returns true iff the variables refer to the same
instance) instead of == (deep comparision - member-by-member).
AFAIK this behaviour was introduced in 5.2 or 5.1 - well, just another BC
break.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function overriding and class inheritance
Emil Ivanov wrote:
class C1 {}
class C2 extends C1 {}
abstract class Work1 {
public function f1(C1 $c);
}
class Work2 extends Work1 {
public function f1(C2 $c);
}
Strange thing is I don't get any error message here, although there definitely
should be one.
PHP 5.2.2-pl1-gentoo (cli) (built: May 21 2007 12:36:57)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
And regarding your code - it should work the other way round - you can only
loose preconditions and tighten postconditions, which is a result of
substituion rule already mentioned by Stanislav.
--
Paweł Stradomski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in PHP 5.2.1
Derick Rethans wrote: On Tue, 24 Apr 2007, David Lindstrom wrote: Still, PHP should never segfault? Almost never... stack overflows are okay. regards, Derick I' ve run into PHP segfaulting (infinte loop of two constructors) recently and I think it should not happen in any case - no matter if the PHP script running is buggy or not. I makes debugging difficult and brings unpredicatble results. Besides - it is not documented at all. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Object-Caching and Reference Counting
On 21 jan 2007 Lars Schultz wrote: Perhaps you could use your own reference counting? Keep your real objects in private array and instead of returning them return a simple object which would forward all methods and properties by __get/__set/__call. The constructor would increase your internal refcount by one, destructor would decrease it. I use those objects quite often as they are used to access the database to manipulate or search for related data. It wouldn't perform well and is actually not at all practicable because there are so many classes for which I'd would have to copy the interface. I don't see any place where you'd have to change the interface - except for the class which contains that private array; you can use the name of your current class (MyObject)as the name of this new forwarding class and make a new name for the class which would be a copy of your current class (eg. MyObject_private). Therefore in all function definitions required class specification doesn't need to change. Well, perhaps you would have to change some factory class if you use one, but that should be a one place - if you kept your code clean. I think this solution is better, as you don't have to rely on internal refcounts, which can be implemented in another way (or dropped altogether) in future releases. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Object-Caching and Reference Counting
Lars Schultz wrote: I know that a lot of you may say: Why do need to do that?...and I'd have to think for 3 days and then write for 4 days and would give up. It seems like a nice solution to me and if any of you have an idea as to how I could implement this differently, please feel free to point it out to me. Perhaps you could use your own reference counting? Keep your real objects in private array and instead of returning them return a simple object which would forward all methods and properties by __get/__set/__call. The constructor would increase your internal refcount by one, destructor would decrease it. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
W liście Andi Gutmans z dnia czwartek, 11 stycznia 2007 20:53: Stefan, do you truly believe that other languages allow for secure shared hosting without using a setuid or chroot solution? I mean take Ruby, Python, Java, C/C++. It wasn't me who's been asked, but at least for Java, the answer is yes. You can declare privileges for the code based on where it is located (in the filesystem tree). That should be sufficient, if used properly. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
W liście Andi Gutmans z dnia czwartek, 11 stycznia 2007 21:48: How familiar are you with Java in shared hosting environments? Been hacking one mayor Java app to make it work with JSM. Not much, but I believe Sun took much care to make sure JSM works as advertised. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
