Re: [PHP-DEV] [VOTE] Alternative typehinting syntax for accessors
Am 22.01.2013 09:07, schrieb Nikita Popov:
It's not just about the lines of code. It's about having a more readable
and more intuitive syntax. Am I the only one who thinks that public $date
{ get; set(DateTime $date); } looks pretty ugly/unclear compared to
public DateTime $date;?
FWIW: I agree;) If accessors get through, I'd rather have this alternate
syntax. The other looks like a typo. I don't get to vote though...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Am 08.01.2013 08:56, schrieb Christian Stoller:
But the way 'nullable' properties are defined is not very intuitive and
unclean, in my opinion. Stas has already mentioned that.
`public DateTime $date = NULL;` // this looks like the property is initialized
with null, but it does not show that the property is 'nullable'
To me this makes perfect sense. It takes up the syntax php has been
using for method-definitions. A syntax we would be using to create a
classic setter method if there wasn't a fancy new one.
public function setDate(DateTime $date = NULL) {
$this-date = $date;
}
Anything other than this would result in an inconsistency. Having
accepted that syntax previously and now introducing yet another one,
would be confusing and unnecessary.
Although, as Stas has pointed out, *not* allowing NULL for a property
will not prevent it from being NULL...depending on wether it has been
initalized.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Am 08.01.2013 10:03, schrieb Lazare Inepologlou:
The fact is that the existing syntax for nullable type hinting has its own
problems. For example, this is not possible:
function foo( Bar $bar = null , $mandatory ) { ... }
Sure it's possible;) I did not get a syntax error for that...I even use
that case many times in my code exactly for that purpose, to allow $bar
to be null but require $mandatory to be defined explicitly.
I would love to have the question mark syntax for both properties and
argument type hinting.
Introducing a BC-Break and/or yet another syntax? Is that worth it?
This does not apply in all cases. Here is an example of a property that is
guaranteed not to be null:
class Foo {
private $_date;
public DateTime $date {
get {
return is_null($date) ? new DateTime() : $this-date;
}
set {
$this-date = $value;
}
}
}
The property is still null;) Only the return value of the getter will
not be null. But that's not the issue, is it? I am not arguing the case
of NOT allowing null, Stas wanted to always allow null because of this
reason and not have a special syntax to declare this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Official Userland Library (was: removing an item from an array)
Am 22.08.2012 09:45, schrieb Lester Caine: Personally I'm looking for a 'Official Userland Library' that provides EXAMPLES of how to do operations rather than yet another downloadable library. Something I can cut and past from into my own code when I need a widget and which provides a much more 'PHP approved' style to the code I'm using now. Putting this into PEAR is most definitely not what I need. I need to be able to see the code on-line. I guess as always, the deployment of this userland-library depends on the php-users personal preference. I agree with Lester in that I'd rather have it available online as a proven example of how to solve a very specific problem instead of loading yet another bunch of functions I might not even need, just for the sake of having them. But I guess we could have both. I am not sure we should have a hefty namespace attached to those functions though...it would of course make the situation of naming clashes less dire, but that could also be solved manually by copy/pasting and then renaming according to taste. This is the beauty of it all. Wether you want to make the functions available globally, grouped as a static class or using namespaces is left to the user. Making the Library available for download as a complete package or using PEAR/Composer could be a second project, no? Lets focus on how it could fit into the manual (or not) and then go on to how it could be served as a package? I'd really like some comments/thoughts from a php-dev on this...and maybe someone from docs? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Official Userland Library (was: removing an item from an array)
Am 20.08.2012 23:13, schrieb Lester Caine: Boilerplates on how to do more complex operations sounds a very good idea to me. It's exactly the sort of thing I've been asking for ... I am glad you like the idea!;) although boilerplate does seem to leave a metallic aftertaste in my mouth. especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in the Are you referring to Rasmus Schultz from the removing an item from an array thread? As far as I understood, Rasmus is arguing in favor of having more functionality built into core, while I am arguing, that a lot of functionality should go into the documentation first, as a userland implementation. I am not sure I understand what you're getting at. last hour, and while trying to sort my own mysqlnd compile problem, the number of totally out of data results from google just re-enforce that situation. You mean that when you're googling you get bad results, because of the whitespread use of php? I know what you mean. If good and proven examples of common problems would be within the official documentation, no googling would be necessary. Even PEAR is little use as a good example of coding style since it needs to be updated to be strict compliant in a tidy way - rather than just fire fighting error messages. Personally I have never used PEAR, so I can't say anything about the situation there, but I can imagine that maintaining such a large codebase has it's disadvantages. This could probably happen to my idea as well...causing lots of necessary maintenance-work, I mean. But since its userland code, lots of people can work on the problem. Also the kind of code I'd like to see there is very concise and bare-bones, so it probably won't need much adjustment to new php-versions. Using them as a replacement for tidying up core functions may be a little controversial, but it does seem the ideal idea for archiving the excellent examples that have been presented on the various lists? If they then form the base for an update to a core function, then the boilerplates just get updated to be current. That's something I thought of too. If some functionality becomes very popular (difficult to measure, I guess) it could go into core, AFTER it's proven its worth in real-world applications. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Official Userland Library (was: removing an item from an array)
Am 20.08.2012 22:51, schrieb Andrew Faulds: On 20/08/12 21:43, Lars Schultz wrote: It's a ridiculous argument, IMO. Nothing you could add to core couldn't be implemented in userland code somehow. (yes, that's hyperbole, but there is very often a userland solution. Most functions are for convenience) I don't think it's ridiculous because every core functionality to be implemented and maintained causes some php-dev to invest time on something, which is not absolutely necessary because it could be done, with some additional work, in userland. There is a lot of functionality, that can not be reasonably well implemented in userland, and php-dev time should be used on such cases, no? With my suggestion, any php-user could suggest a functionality he feels is missing to go not into core but into the documentation, with a suggestion of how to solve the problem. Therefore the bar, which decides wether something is worthy of going into core could stay as high as it is, but it could be lower for something that goes into the documentation as an example. Adding functions is important for convenience as well as functionality. Sure, it would be nice to have a small set of functions, but those lead to overly verbose code and waste the time of developers. Yes, many of them can be easily implemented in userland, but consider this: what if half (say) of the array or string functions didn't exist and you had to manually implement each? A little code can quickly become a lot to do a lot of simple things. Therein lies the crux of it all...how much is too much or too little. Who's to say? It's a matter of personal preference, I believe. That's why such features will always trigger those discussions. Because it depends on one's programming style...of which there are various, various good ones, even if not always compatible. That said, not every possible function has a compelling case for addition, simply because it does something too obscure or is impractical. Sometimes that is obvious and then the discussion will be short or not even starts. But mostly it's not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Official Userland Library (was: removing an item from an array)
Am 20.08.2012 19:43, schrieb Sebastian Krebs: What I don't understand is, why should every function goes directly into the core, if you can achieve exactly the same without core changes? This comment from Sebastian got me thinking. It's true. Every-someone has his own views on what is absolutely necessary and should be available to every-one. Depending on ones coding style, it probably is absolutely necessary. Whenever a userland implementation is viable, it becomes a strong argument against embedding it within the core. But those suggestions keep coming up and some create more than a little controversy among the contributors to the list and even among the core-developers. That said: Why dont we embed a library of userland code right there in the documentation, next to the core code, where a php-user would expect or look for the functionality. They'd have to be properly highlighted as userland implementations of course but would still be there to be found in the documentation. This would at least solve the problem of: - horrible implementations, replaced by neatly formed official userland solutions. - performance (because they would be as efficient as possible) - correctness (because discussed on the internals (or docs) list, almost as if it'd go into the core) - skill (because everyone can provide a solution, even if he's not able to write c-code) - availability (because with a simple copy/paste-action I can use the provided (currently) official solution immediately. It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a source for a userland implementation of, say, array_remove or print_r_html. Also its alot more accessible and available than PECL, because it is after all just PHP code. I am not sure wether this is a good idea, but it struck me as a better solution than just saying: it's so simple, do it yourself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Sorry for creating more noise... Am 18.08.2012 06:59, schrieb Sherif Ramadan: Further more, your assumption here that the result is incorrect (or improperly indexed) is completely baseless and moot. You are making a bold assumption that I both care about the keys and that I expect them to be numeric and sequential (why can't I have string keys?). This would also entail that I depend on keys for order (which is not a requirement for a PHP Array since all PHP Arrays are ordered-hashmaps). I don't assume anything. I only stated a use-case where unset() will not work. I neatly listed some solutions and pointed out their merits...mostly to show that there are less than ideal solutions out there that will either perform badly or worse, not work properly at all. The order of the elements in the array has not been affected by the keys that index them or the use of unset() in the least. So your argument holds no merit. If you are depending on the sequence of the keys to determine the order of your elements you made a huge mistake, because the array was already designed to store elements in order regardless of whether you provide a key or not. So you're solving the wrong problem here. Rest assured, I do know how PHP arrays work. I don't see what the ordering has to do with wanting to keep an array sequentially-indexed. I never said it was redundant or fussy. I am going to stop here, for the sake of noiselessness. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Am 16.08.2012 07:55, schrieb Sherif Ramadan: Now your array is something completely different from what you wanted. The solution stated earlier is the most sane one (just using array_keys() with a search value). the array_keys solution is slower (although barely) than my suggested array_slice solution but comes up short when looking at the result closely. The resulting array won't be properly indexed anymore, but will be a numbered hashmap. I am not sure wether PHP keeps an internal state on wether an array is a map or a classic array, but when you require indizes to be sequential (without gaps) then unset() just won't do. Thus it's not always a simple problem. I don't wish to degrade anyone's contributions to this thread, but this really is the perfect example of making a lot of fuss over nothing on the mailing list and an example of the kinds of discussion we should be avoiding when there are so many other important problems we can solve. Rasmus' suggestion was very concise and unfussy. I've been wondering the same thing for some time. It would make the array-functionset more complete and code more explicit. Why should we only talk about major changes and additions? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Am 15.08.2012 22:22, schrieb Stas Malyshev:
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
One thing that should be noted in this case and any solution that relies
on unset() is that even though its simple and fast, it will not result
in a properly indexed array. The same goes for any array_diff based
solution.
I tried and compared the following solutions and ordered them according
to their performance. The fastest (and with a correct result) solution
is based on array_slice. Why this is the case I can not say...I am not
arguing for another array-function (as there are so many already)...but
I certainly have my own array_remove implementation, since it's such a
common use-case.
function array_remove_slice($haystack,$needle){
while ( true ) {
$pos = array_search($needle,$haystack,true);
if ( $pos === false ) return;
$haystack = array_merge(
array_slice($haystack,0,$pos) ,
array_slice($haystack,$pos+1)
);
}
}
/* ~1.5 times slower than slice */
function array_remove_unset($haystack,$needle){
while ( true ) {
$pos = array_search($needle,$haystack,true);
if ( $pos === false ) break;
unset($haystack[$pos]);
}
}
/* ~2.3 times slower than slice */
function array_remove_loop($haystack,$needle){
$result = array();
foreach( $haystack as $value ) {
if ( $needle == $value ) continue;
$result[] = $value;
}
$haystack = $result;
}
/* ~3.5 times slower than slice */
function array_remove_diff($haystack,$needle){
$haystack = array_diff($haystack,array($needle));
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 03.09.2011 13:56, schrieb Etienne Kneuss: Indeed, I planned to implement that as well, I haven't had the time to do it yet though. It should happen in the following weeks. Not to keep you from doing this...but couldn't that easily be solved by using a simple associative php array like this: $pseudoWeakMap = array(); $pseudoWeakMap[spl_object_hash($obj)] = new WeakReference($obj); or did I misunderstand the concept? I hope I'll have a chance to use WeakReferences soon in my project;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 09.08.2011 14:22, schrieb Arvids Godjuks: I have mixed feelings about this proposal - from one point it's quite neat - ability to mark circular references for the memory manager so it can free them sounds very delicious, especially for some cases. I had run into my own bunch of problems with memory in PHP in the past and right now I'm running a daemon written in PHP in production on 5.3.6. Careful construction and knowledge that circular references actually do harm I did add safeguards that actually clean up the objects in recursive manner (and objects have internal flags that cleanup has been initiated - that way I make sure I cleanup the same object only once). That sort of planing at the design stage makes it far more friendly with memory, so it doesn't mean that PHP should have soft references. Exactly what I did;) My opinion is that if this can be done without using significant resources and will not have major issues while implementing - it can be added, otherwise just skip it - better off fixing bugs and optimizing :) Of course. I am not saying that its a must have...just wanted to defend it from being marked as useless. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 06.08.2011 02:14, schrieb Hannes Landeholm: Yeah I think there's a lot of misunderstandings going on with weak/soft references and how the garbage collector works. Weak/soft references is not some kind of solution to the cyclic reference problem. The GC takes care of that already. You can use whatever OOP patterns with whatever reference graphs you like Lars, the GC will free the entire structure as soon as the cyclic collector runs after you are not referencing it anymore. You might have become a bit confused with my last post where I explained how one could theoretically hack together a soft reference implementation by using weak references and some properties of cyclic collection. Also property access performance is off-topic. I did not misunderstand how weak/soft-references or php's new GC works. Having a GC collect circular references is neat, but if I remember correctly, collecting them (which is why there are other, faster methods but which require more memory) is neither simple nor fast (whatever that means) so...if I can assist the GC by clearly stating that my child-objects may be collected as soon as they and their parent are not referenced from userland anymore thus not requiring the GC and thus freeing memory as soon as possible,...seems like an optimization worth thinking of. Especially if I tend to have vast structures with hundreds of objects. In 5.2 (we can't move our project to 5.3 yet because of a BC issue) i had to manually clear those cycles before dropping the last userland reference to the tree of objects because otherwise I'd run into memory problems when processing alot of those trees. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 06.08.2011 14:09, schrieb pierre@gmail.com: Out of curiosity, which bc issue blocks the move? The fact that after 5.2.6 we can't set mbstring.func_overload PHP_INI_PERDIR anymore, but need to set it for the whole installation (PHP_INI_SYSTEM). Which wasn't even mentioned in the changelog...btw. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 23:19, schrieb Chris Stockton: I myself oppose WeakReference in java and I do not see my opinion changing for PHP ... unfortunately I think WeakReference's are even nastier in PHP because of it's error handling. You see it is very common when weak references are used in java too follow one of two paradigms, fall through with NPE's, or state/null checks. With PHP, you may not test the validity of a weak reference simply by accessing it, you will get a uncatchable fatal error. So in PHP your only option when consumers are obtaining weak reference handles, is to check their validity before use, whether that is a call into some registry, or a null check of the reference itself, whatever.. it still leads to checks to make sure that reference wasn't collected. This added complexity in the WeakReference consumer makes me unable see any purpose through the inconvenience and unpredictability they bring. Though I have never used java, I believe Weak- and SoftReferences would tremendously simplify certain, very specific applications. * WeakReferences for implementing the observer pattern aka. keeping a list of handlers for certain events. * SoftReferences for caching aka. keeping a list of objects to be returned or created by a factory If used this way, there is no danger of null-fatal-errors, because the event-trigger is aware of the volatile nature of its handlers and the factory knows that it's cached objects might be discarded. In fact, I'd say that Weak-/Soft-References are a better fit in PHP than in Java, because the -get() methods return type is non-specific (has to be cast in java?)...which matches PHPs untyped approach. I use ticks to do this in a CLI daemon I wrote, worked out pretty well. Not saying a specialized function isn't needed but I think ticks aren't to far from convenient to require such. Could you explain ticks?...to me a tick is a nasty little creature that bites and gives you infections;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 05.08.2011 08:07, schrieb Rasmus Lerdorf: Ticks have been in PHP forever. See http://www.php.net/manual/en/control-structures.declare.php#control-structures.declare.ticks woha! interesting read. thanks:) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 05.08.2011 14:58, schrieb John LeSueur: Are there other advantages I'm missing? If I may, I'll respond to your questions with 3 examples. A) Naive, straight forward approach (this will run out of memory if objects are heavy) http://pastie.org/2325252 B) Previous approach taking memory into consideration: http://pastie.org/2325317 C) Clean, memory efficient approach using SoftReferences http://pastie.org/2325254 The Problem with B) is that depending on how I use the objects, I am dropping objects from cache (to free memory) that are still in use. If I then re-add them to the cache, my singleton-pattern will be broken. NB: In the simple example I used, this is not a problem because I do not keep references to more than one object. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 05.08.2011 19:46, schrieb Jezz Goodwin: As Chris Stockton points out http://news.php.net/php.internals/54391 there is always going to be additional code that has to check to see if the reference is still valid. But don't you see that in exchange for one little IF you get so much more...what's an NPE compared to an OOME;) If the only concern here is running out of memory, surely you could design a framework that could reduce it's memory usage without having to get rid of it's objects. It's not about a framework, it's about making use of what is available (memory processing power) and balancing those twoand PHP is not very efficient with its objects...I might be wrong here, but I think that because PHP supports dynamic assigning of properties, it addresses them by name and not as in a c++ object by memory-offset, but I am out of my depth here, having deduced this without looking at the source-code. For example, your ORM objects will have a store of data. You could run a process every now and again that deletes the data from the objects (everything except the ID of the table). And then write it in to the framework so that if you start using the object again it goes and gets it's data back? Actually my use-case is single-threaded and linear, so I can't really run a second process...but if this is your solution compared to SoftReferences with one IF, then I am not sure I like yours better. Also WeakReferences and SoftReferences are used in completely different situations. The two concepts are related but not its applications. I just remembered something I encountered in an AS3 project I made...it's a perfect example for WeakReferences. (you might not like AS3 but you may appreciate the fact that it also uses this concept) http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/EventDispatcher.html#addEventListener%28%29 public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void If you no longer need an event listener, remove it by calling removeEventListener(), or memory problems could result. Event listeners are not automatically removed from memory because the garbage collector does not remove the listener as long as the dispatching object exists (unless the useWeakReference parameter is set to true). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 05.08.2011 18:29, schrieb Hannes Landeholm: It's interesting to think about though. I'd definitely find a use for them;) I might just patch our installations to provide me with the zval-refcount and go with that for now...I have been warned, but I have to burn myself before I believe that boiling water is hot;) I just thought of another design-pattern which could make use of WeakReferences...The composite design pattern. http://en.wikipedia.org/wiki/Composite_pattern A parent references its childs and each child references its parent. circular-reference nightmare...with WeakReferences I could use a weakReference for storing the parent...so that if the parents last real reference is discarded the childs will cleaned out as well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 02:32, schrieb Stas Malyshev: I'm not sure I understand why you need week refs there - can't you just always use $prodDb-getProduct(1) and when you don't need it anymore just do $prodDb-drop(1)? Or let it drop it whenever it wants to? My Project requires lots of DB-Record = PHP-Object mapping, as the objects get used quite dynamically I can't know when and how often an object will be used. To make sure there's only one instance of an Object in Memory per Session, I cache them in an associative-array, the key being the record-id (actually a PHP-Object consists of many records). Then I am using the Singleton-Pattern like Library::getObject($id) which returns a new (fetched freshly from the DB) or an already used object (from the cache). This works very well and keeps me from expensively reconstructing objects from the DB. What it does not work well with is Garbage collection, since the an object will always be referenced at least once (by the cache). The longer a script is running, the higher the chance that it will run out of memory (fast). I do want to keep those objects for as long as possible, but not if the price is an out of memory fatal error. My solution to this was neither nice nor correct, but I could not think of anything else: Whenever I'd create a fresh object I'd check memory against its limit and if it runs close, I will discard the oldest objects from the cache, always running the risk that my singleton is suddenly not so single anymore, because a discarded object was still referenced somewhere else. So either I get to know if the object is actually in use somewhere else than just the cache (using the zval-refcount method) or PHP provides me with something like WeakReference or even better: SoftReference, which would give me more control as to when it would be collected. I am open to any suggestions how I could solve my problem without WeakReference or zval-refcount (short of keeping a ref-count in userland). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 09:17, schrieb Stas Malyshev: I'm sorry but you putting forth contradictory requirements here - you want to keep the objects (to avoid expensively reconstructing them) and you don't want to keep them (memory problems). You'll have to give up one of these requirements. As I see, you gave up the caching requirement and you clean up objects when memory is tight. As long as you don't need more objects than you have memory you should be fine. As long as memory is infinite I'd be fine. It's not contradictory at all. I have to balance performance gain (keeping objects in memory) and memory usage (keeping too many objects out of memory). You should control your code so that somewhere else does not keep extra references. As well as you'd have to control you code if you use weak refs, otherwise extra references would still keep objects alive - or you'd have to rewrite your code and control it so that is always uses weak refs and always checks that the ref is alive. Not true. With WeakReferences, objects would be cleaned from memory as soon as my cache-list is the only place left still referencing it and the GC is run. Even better would be SoftReferences, which would only be cleaned when there is no memory left. Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. This is like saying: do not use objects at all and use the DB for storage. verbosity and slowness is something I'd like to prevent. I did not mean to defend WeakReferences, I just meant to give a valid use case. Your saying that I shouldn't do it doesn't help much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 18:35, schrieb Stas Malyshev: No, it's not even remotely like that. Using one intermediary function and doing the DB call is orders of magnitude apart. You asked how you can solve the problem, I showed you how. You can claim you don't like the solution, that's fine, everybody has his own taste. But you can't claim there's no other solution. Right. I don't like doing design-stuff how they do it in java either, but a little bit of it hasn't hurt anybody, and it's conciseness helps readability alot. I am sure you understand the problem quite well but it's not one of yours, obviously. That's fine too. But you can't claim the use-case is not valid. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 03.08.2011 09:35, schrieb Lester Caine: I think this is were I am sitting at the moment ... If a script needs to tidy up memory because something has gone wrong, then in my book the script is faulty? The example of why it is needed does not make sense to me, probably because I don't understand it, firing an action on the database end and trying to then simply tidy up the the php end cache without a clean reload just seems wrong? How do you know what the stored procedure/trigger/business logic has done to the underlying data? But I've never used MySQL :) I think you might have misunderstood the use case Hannes mentioned. It is a valid problem and weak references are a neat and indeed the only clean solution (so far) to it. I ran into similar Problems and it costs a lot of code and bugfixing to work around the problem, both with the observer-pattern and object-mapper-cache. Do not ridicule his strategy just because you've never run into the problem. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can I use strings with some unicode characters as array keys?
Hi Andre,
You could've just tried it yourself;)
$list = array(
'a'='string key',
utf8_encode('ä')='unicode key', //will be treated as an ascii-string
10='int key',
2.2='float key', //will be cast to an int(2)
null='null key', //will be cast to a string(0)
true='boolean key', //will be cast to an int(1)
);
class B { }
$f = fopen('/tmp/x','r');
$list[$f] = 'resource key'; //$f will be cast as an int(x)
$list[new B()] = 'object key'; //yields an illegal offset type notice
foreach( $list as $key = $value ) {
echo $value .': ';
var_dump($key);
}
Am 31.07.2011 04:18, schrieb Andre:
Question to someone who's familiar with how arrays are implemented in PHP.
I've tried asking this on stackoverflow.com, but it looks like I need
to ask this one
to people familiar with PHP source.
PHP manual says that one should only use strings or integers as array keys.
Also I know that PHP doesn't speak unicode yet.
So - I was just wondering - when unicode characteres are used in
array key - does PHP strips them or affects them in any way?
or does iPHP simply treats keys as binary string, the end of the story?
Thank you!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Am 16.07.2011 13:23, schrieb Ferenc Kovacs: we have debug_zval_dump but it is hard to use correctly Well, it's not a simple problem then is it? It wouldn't be too hard if you understood the source of the problem... with weak references, you wouldn't need to worry about keeping a count of the refcount only check the valid() method. yeah...a magic bullet is cool, but you could, to quote a contributor to this list, shoot yourself in the foot;) for your last paragraph: that's totally unrelated to weak references, but you could achive what you want through memory_get_usage() + You're right. It's related to one of the usecases of weak-references though...and your proposition wouldn't works ince I'd have to check my memory-usage all the time...that's what events are for. btw. if I remember correctly, somebody requested a non-fatal callback when memory limit is reached callback functionality, I have to look that up. By then it's probably too late since I don't have any memory left to run my cleanup code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Am 17.07.2011 17:40, schrieb Hannes Landeholm: If you are writing code that caches objects/relations and that caching has a significant impact on memory usage, you need to care about memory allocation/management per definition. Right. That's what I am talking about...a callback on high-memory consumption and a way to check which objects I could liberate from my cache. So then you have to learn how OOP memory managment works (which should be obligatory anyway if you want to call yourself a OOP-developer IMO). I do call myself an OOP-developer but maybe I shouldn't, because I've never heard of OOP Memory Management. Would you care to explain in private? A common argument to why programmers should not start with a garbage collected language is that it prevents them from understanding memory allocation concepts. The other argument being that if you're not using a gc-language, it might prevent you from starting at all. It would probably be simple to implement such functionality. However this would be bad design since it would violate responsibility isolation. PHP should expose as little internal stuff to the userland as possible - unless there are a clear use case for it, and even then it might be a bad idea because it could cause BC breaks in future updates. I agree with you that it's not an ideal solution. But my solution would not introduce a completely new concept to the language, but would allow advanced PHP-users to write their own custom bred solution. = give the language a rest If you write code that depend on reference counts or memory usage - you're doing something wrong. Why?...because it's not discrete? I am only taking advantage of what is already there... The only scenario I could imagine where you could free memory spontaneously on demand (when the arbitrary OOM limit is reached) - is if that would be cached data. Exactly the case I wanted to cover. Caching is a very complicated subject that is not directly related to weak references. Start a separate thread about it and present clear use cases if you have anything special in mind. I know but WeakReferences (or SoftReferences) would be a solution to this, right? It's not unrelated. For example, I need weak references to store a table of back references between objects for later reference (depends on how you use the objects). If A references B i also need a weak reference from B to A so if B should be replaced with a C object I need the weak reference from B to A to know that A should be updated to point to C instead (if A still exists). This is not related to caching. I am looking forward to the RFCs usecases...this sounds interesting. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Am 18.07.2011 09:33, schrieb Hannes Landeholm: Lars: Please don't break up my sentences and take them out of context before you reply to them. (Hint: If a sentence begins with so it's not a good idea to just reply to that sentence.) Sorry for misquoting you. I intended to make it clear to which passage I was replying. If you are caching stuff you would rather want to use a strong reference since the objects should be retained between usages _per definition_. You might exploit weak references + destructor resurrection to achieve some kind of on-demand, unorthodox caching mechanism but that would not be a primary use cache for weak references, nor what you suggested (deallocate objects when OOM is reached). I have also given an example of how weak references is not necessarily used for caching, therefore not directly related to it. If you want to continue to discuss on demand deallocation, I suggest that you start a separate thread. Why unorthodox? and isn't caching mostly done on-demand? Also SoftReferences would be perfect for caching since that data would be freed if memory consumption is high...but here I am, arguing your case. I hope this will be more clear once the RFC is complete. I will then start a separate thread for official discussion. All I wanted was to point out that introducing such a thing might overly complicate things for users not familiar with the concept...as the java guy pointed out in his intro, even java-people don't know about the feature, even though it's been around for 10 years (http://weblogs.java.net/blog/2006/05/04/understanding-weak-references). I'll be happy to read your RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Am 18.07.2011 10:15, schrieb Ferenc Kovacs: I think that having to know and care about refcounts and zvals are more complicated than having an Spl class, which can hold a reference for a variable what can be destroyed to free memory. and there is a chance that people are familiar with the Weak references from other languages, while the zval approach only familiar for those that knows about php internals. so I think that from the userland POV, weak references are easier to grasp. You're right for users who indeed have this problem. But I am worried about those users, which do not have the problem, but still have to know what WeakReferences are...but I should wait for the RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
I too would welcome a solution to this problem, I've run into it several times already and always had to use a semi-satisfactory solution. I hadn't heard about weak-references before, and I generally like the concept. What I am not so sure is wether this makes everything alot more complicated for users who do not know/care about the problem or the solution. Of course the impact on those users depends on the actual solution. I came at the problem from a different angle and came to a different solution: If I could get the refcount on a certain object, and kept the object stored centrally in one list, I'd know that if the refcount is down to 1 (or some other constant) that the object ist not in use anymore. I believe that this would be quite a simple PHP addition...a simple function called: get_ref_count() or something and as I remember, that value is always stored in the zval... The only other thing that would help would be a callback (or callable) which is triggered by PHP reaching a certain memory-limit, absolute or relative. Then I could clean up memory according to my own business-logic... This way, PHP would not feature something totally new, but one could still solve the problem with some work. Do I make any sense at all? Am I missing the point? Anyway, this is an interesting problem. Cheers. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
Am 22.06.2011 15:40, schrieb Reindl Harald: and why this will not return true if $str is ISO-8859-1? If you RTFM (in your jargon) you would know. http://ch.php.net/manual/en/function.htmlspecialchars.php (Return value Section) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting a list of registered namespaces.
Am 16.06.2011 20:12, schrieb Stas Malyshev: Well, we could - you could actually do it right now with list of classes and some simple regexp-ing. The question is a value of it. I think get_declared_classes works as well, if you create a script that loads all your classes you could then extract all namespaces...(btw. I love the way the autoloader plays in concert with the /-Separator, thanks for that;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Am 06.06.2011 12:46, schrieb Pierre Joye: There is no reason not to update, absolutely none. There is: http://bugs.php.net/bug.php?id=49189 Which fixes the issue by removing a feature and introducing a BC-Break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Am 06.06.2011 13:41, schrieb Pierre Joye: You cannot say that any kind of bugs prevent the waste majority to update from a dead cow to the current stable branch. And I'm not sure if it is actually a bug or a badly documented setting. Its not the bug that prevents moving forward but the fix of it! [2009-08-07 07:40 UTC] j...@php.net Obviously the documentation is wrong, it's PHP_INI_SYSTEM in sources since fix of bug #43227 for PHP 5.2.7. The fix of bug #43227 changed the setting from PHP_INI_PERDIR to PHP_INI_SYSTEM, which is not a fix but a workaround for something (ereg), which will probably be removed in the future and already is deprecated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: BC-BREAK at 5.2.7
I didn't get any feedback on this. Does that mean I am on the wrong list or that no one cares?;) NB: It its not a documentation issue! Patch for Bug #49238 changed the behaviour. Am 27.05.2011 11:25, schrieb Lars Schultz: Hi internals, Jani told me to ask the list about this. I tried commenting on the bug but I guess since it's closed, no one cares about it anymore. http://bugs.php.net/bug.php?id=49189 This Change prevents us to move to anything beyond this bugfix with our codebase and I don't believe that we're the only one having this problem, as comments on Bug #49238 are suggesting. http://bugs.php.net/bug.php?id=49238 Could you please tell me wether there is any chance that this will be changeable PER_DIR again in the future of PHP or not? cheers. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BC-BREAK at 5.2.7
Hi internals, Jani told me to ask the list about this. I tried commenting on the bug but I guess since it's closed, no one cares about it anymore. http://bugs.php.net/bug.php?id=49189 This Change prevents us to move to anything beyond this bugfix with our codebase and I don't believe that we're the only one having this problem, as comments on Bug #49238 are suggesting. http://bugs.php.net/bug.php?id=49238 Could you please tell me wether there is any chance that this will be changeable PER_DIR again in the future of PHP or not? cheers. Lars -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THE TOOLPARK CORPORATION AG Lars Schultz Senior Software Developer Bühlstrasse 1, Postfach, CH-8125 Zollikerberg-Zürich Telefon +41 44 396 26 44, Fax +41 44 391 22 60 lars.schu...@toolpark.com, http://www.toolpark.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Diese Nachricht kann vertrauliche oder rechtlich geschützte Informationen enthalten, deren Verbreitung ohne unsere ausdrückliche Erlaubnis untersagt ist. Falls Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte umgehend den Absender, vernichten diese Nachricht und unterlassen unbedingt das Veröffentlichen, Vervielfältigen oder Verbreiten sämtlicher Inhalte und Anlagen. Bitte beachten Sie, dass wir uns das Recht vorbehalten, alle ein- und ausgehenden Nachrichten zu überwachen und aufzuzeichnen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: - Entities with knowledge about its persistence information That must be something I simply have no knowledge about. But isn't it just a theoretical difference, because in practice, the code being annotations or PHP-Code is kept within the class, therefore the entity is not separated from its persistence information...but then I don't really understand the problem in the first place;) - Resources being wasted Now you sound like Rasmus when he talks about his assembly-history. Do you really expect Annotations to perform better than hard-wired php-code? - You rely on an instance to grab information. Or you use a slow approach of having a static method This must be something else I do not know. Why is that slower? Also, there are much more things than you can actually think of related to this. The code is not bloated. Since you don't have a pre-processor for class metadatas, you have to build all definitions manually. This is why you have to set inheritance type, for example. It seems to me that with good default-behaviour, the coded needed could be stripped down to what i wrote, since it contains as much information as your annotated code. FYI, Doctrine took an year of planning an another year of careful implementation of each feature. Well it's hard to argue with that without stepping on those peoples toes, isn't it?;) Is their reasoning process public knowledge? Maybe that'd help me understand. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 16:53, schrieb Martin Scotta:
Annotations are not required, you add them if you want to.
Yes. sure. But I am sure that certain Annotations must be combined to
unleash their purpose, no? There is no validation for that, correct?
Also they can be used not only with classes. You can annotate methods,
members, parameters (I'm not sure about the RFC scope)
With the interface approach you can annotate classes, methods, members
and parameters, depending on how you build it, no? Annotating functions
by themselves...is that really an issue? Since they're mostly stateless
why would they need meta-data?
with extends you inherit implementation
with traits you inherit code
With annotations you inherit behavior.
inheriting behaviour is just a special case of inheriting code as in
traits, no?
you cannot do this with interfaces
Annotation(param=Value) class Class { }
interface Annotation { function getParam(); }
and how do you apply an interface to a method?
Deprecated function getSomething() { }
interface Annotation {
function getMethodAnnotation($method){
switch( $method ) {
case 'getSomething': return array('deprecated');
}
}
}
All the framework/library boiler-plate should be reduced to minimum.
I can't argue with that.
What I just noticed is that simple examples (key=value or even just
keywords) are indeed concise and I could imagine using it this way. But
for that we have docblocs. But as soon as you go into more complex
structures, more than key=value which guilherme keeps arguing is so
essential to the Annotations and is also why we can't use docblocks, it
gets unreadable and especially for maintaining state within meta-data,
I'd always use PHP-Interfaces over Annotations.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 11.05.2011 09:35, schrieb dukeofgaming: Que?. Are you aware that you cannot implement interface methods?. Sorry. my bad. I mixed implementation with specification, but it would work, no? I really think the dilemma of whether annotations are useful or not is moot. What an argument. I'm not saying they are not useful. I am saying they can be done with what we already have. I've got tons of code which could run faster if the core-devs finally decided to take my aproach over theirs...;) Also citings of .NET and Java makes me wanna scream, because I don't want those languages. I want PHP, which has been my faithful servant for over 12 years! -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THE TOOLPARK CORPORATION AG Lars Schultz Software Entwickler Bühlstrasse 1, Postfach, CH-8125 Zollikerberg-Zürich Telefon +41 44 396 26 44, Fax +41 44 391 22 60 lars.schu...@toolpark.com, http://www.toolpark.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Diese Nachricht kann vertrauliche oder rechtlich geschützte Informationen enthalten, deren Verbreitung ohne unsere ausdrückliche Erlaubnis untersagt ist. Falls Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte umgehend den Absender, vernichten diese Nachricht und unterlassen unbedingt das Veröffentlichen, Vervielfältigen oder Verbreiten sämtlicher Inhalte und Anlagen. Bitte beachten Sie, dass wir uns das Recht vorbehalten, alle ein- und ausgehenden Nachrichten zu überwachen und aufzuzeichnen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 11.05.2011 10:11, schrieb dukeofgaming: Eh, well, in a weird and complex way I'd guess =P. I am saying that using interfaces in situations where you need more than key = value annotations or state (is that correct?) are of similar complexity and already available. Also, and if I'm not mistaken, PHP has already taken from Java's example with exceptions and the interfaces you love =P. Don't get me wrong. I don't love interfaces, I find them useful in very specific situations, especially when code needs to be reusable as in a library or framework. With 800 classes in my main project I am using 10 interfaces. Almost always in a Describing/Metadata-way. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 09:44, schrieb Ferenc Kovacs:
On Tue, May 10, 2011 at 9:01 AM, Chad Fultonchadful...@gmail.com wrote:
On Mon, May 9, 2011 at 10:46 PM, Lester Caineles...@lsces.co.uk wrote:
*IS* it clear by now that the majority of users want this?
For what it's worth, I still oppose Annotations.
And the argument
that 'You don't have to use it' does not wash either since once it has
been
pushed in, some of the libraries we are using are going to start
requiring
it simply because those developers do like the idea, but it does not
necessarily mean that THE CURRENT PROPOSAL is the right way of doing it?
I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=value syntax.
that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.
I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?
nobody is forcing you to use annotations, it won't replace the docblocks.
My main question is: Why do we need more than key=value? When you say
that everyone supports annotations (if that is true), are you sure
they actually want more than key=value?
at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.
for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or
http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column
Discussion of this does not seem to appear in your Why do we need
Class Metadata? section.
I also think that it would be a good idea to link or describe annotations in
general, because it seems that nobody bothers to read that up without
joining the conversation...
Tyrael
From the user-end perspective, what I don't understand is this:
What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?
Why can't this be PHP code? Why should I have to learn a whole new kind
of syntax? We already have a common syntax (PHP interface) for this as
well as an interface (static Class-functions/Object-methods).
To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having passive annotations
over active PHP Code.
Entity(users)
class User
{
Column(integer)
Id
GeneratedValue(AUTO)
protected $id;
// ...
ManyToMany(Phonenumber)
protected $Phonenumbers;
}
*** Example ***
class User implements EntityAnnotation {
protected $id;
protected $Phonenumbers;
public function getEntityAnnotation(){
return new User_EntityAnnotation();
}
}
class User_EntityAnnotation {
public function getEntityName(){
return 'users';
}
public function getColumnInfo($property){
switch( $property ) {
case 'id': return array(
'column'='integer',
'isPrimary'=true,
'autoIncrement'=true
);
case 'Phonenumbers': return array(
'manytomany'='Phonenumber'
);
}
}
}
***
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 10:10, schrieb Jordi Boggiano: I think the main reasons are standardization of the syntax and performance of the parsing. At the moment everyone has to cache the stuff because hitting the tokenizer every time is quite expensive. If implemented within PHP the existing opcode-caches could work wonders on this. Annotations are not code, but more like metadata to tell the surrounding libraries how to work best with a piece of code. What is code?;) What's the Problem with having meta-data within PHP-Code? I think your example shows very well why annotations are good, it's much more concise. But my example is much more verbose (which is good in my view), uses common syntax and is very flexible! It gives you the whole power of PHP instead of a semi-language (no offense). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 14:28, schrieb Martin Scotta: The editor argument is out of place do you really think that the engine should we built around what IDE supports? At least the much quoted user-base would welcome syntax-support for this feature, wouldn't you agree? If support is already there, that's a big plus! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 14:47, schrieb Martin Scotta:
Annotated code integrates best with library/frameworks without the need to
extends or implements.
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.
Umm. Is there any way with the Annotation-proposal to validate a class
to have all the necessary annotations to work with a certain framework?
Is there an annotation-Schema or DTD which I can apply against my
classes and validate them? Because that's what you get when using
interfaces. Which means less shooting in the foot.
As for writing less code...If there is any shared code, we now have
traits!;) hurray!
With annotation your classes are unaware of the other components, which
implies:
* shorter, concise code = less bugs
* no extra dependencies = easy to test
class UserFoo extends LibraryFoo { }
I can see that extending does not really work when using frameworks. But
when using interfaces and traits in conjunction, this is not necessary
anymore.
class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}
I don't get what the problem with writing methods is. They are readable
by any PHP5 developer and you get all kind of support in writing them.
With annotations classes are free to live on you own herarchy
The same holds true for interfaces.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 17:07, schrieb guilhermebla...@gmail.com: Is that still simple? You bloated the php example unnecessarily. This contains the same information as your Annotations example, which to me, is very similar. http://pastie.org/1886774 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Am 12.04.2011 13:33, schrieb Richard Quadling: Notice: Undefined variable Notice: Undefined index To me, these two notices are totally different in severity, but that may be because of how i write my code. I'd like to be able to get rid of the Undefined index Notice in a nice, clean, readable way, because that does not bother me (in my style of code). I do wanna be notified if i am using an undefined variable, as that implies something wrong on a more basic level. $x = isset($x)?$x:'default x'; I don't want a construct for this, because I was either lazy or made a mistake when I did not define $x initially. -1 $x = isset($_GET['x'])?$_GET['x']:'default x'; I can see the use for an alternative construct for this though, but it's not really a pressing matter to me. +0.5 But that is just me and my code. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
I just love substr() and I think all other languages got it wrong;) Seriously...it behaves the same as implementations in other languages as long as values are positive, right? how is that counter-intuitive? How do other languages handle negative values? Am 30.03.2011 08:06, schrieb Dan Birken: My apologizes if I am bringing up a topic that has been discussed before, this is my first time wading into the PHP developers lists and I couldn't find anything particularly relevant with the search. Here is a bug I submitted over the weekend ( http://bugs.php.net/bug.php?id=54387) with an attached patch that adds a str_slice() function into PHP. This function is just a very simple string slicing function, with the logical interface of str_slice(string, start, [end]). It is of course meant to replace substr() as an interface for string slicing. I detailed the reasons I submitted the patch in the bug a little bit, but the main reason is that I think the substr() function is really overly confusing and just not an intuitive method of string slicing, which is exceedingly common functionality. I realize we don't want to go around adding lots of random little functions into the language that don't offer much, but the problem with that is that if we have a function like substr() with an unusual and unintuitive interface, it becomes unchangeable due to legacy issues and then you can never improve. I think this particular functionality is important enough to offer an updated interface. In the bug I also pointed to two related bugs that would be essentially fixed with this patch. -Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
is there any benefit in removing those features? I can see that Code
using these features is probably designed badly or unconventionally, but
php has never been a designers-language...right? It's always been about
being easy to use.
Even without globals you can still use:
Class GLOBALS{
public static $foo;
}
GLOBALS::$foo = 'x';
so...you can't keep people from hurting themselves...right?
-1
Cheers,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
Hi, I certainly don't have PHP-Karma (Does meritocracy really refer to that?), but simply I can't believe that you're talking about this, again. I think Annotation-Supporters have made their point, but shouldn't they let the PHP 5.4 Developers get on with it and let them roll out a new version instead of forcing them to reply to lengthy emails about the same topic over and over again. One could almost believe that you're hoping to drown their voices by frustrating them into not replying anymore, therefore winning your vote. cheers. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
+1 for adding APIs to parse doc blocks -1 for introducing a new Annotations concept and associated syntax Am 16.09.2010 18:36, schrieb Wim Godden: I'm going to say exactly the same thing : -1 for introducing a new Annotations concept and associated syntax +1 for adding APIs to parse doc blocks Zeev Suraski wrote: At 16:34 16/09/2010, Guilherme Blanco wrote: So the question to be answered is: Should PHP support Annotations? -1 for introducing a new Annotations concept and associated syntax +1 for adding APIs to parse doc blocks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
listen to this man;) I think he's on to something. I don't see any problem with that aproach and both parties would be satisfied, no? Am 15.09.2010 10:45, schrieb Benjamin Eberlei: Hi Zeev and Stas, I wouldnt mind extending doc block metadata support instead of adding a new syntax. I agree with you that PHP Docs allow metadata and they can be used for that (and some people do, including me), however what the annotation patch + rfc tries to achieve is something going beyong $refl-getDocComment() returning a string only. The string only return leads to hunderets of different approaches for annotating metadata in all the different frameworks and libraries. A single unified syntax would be benefitial. That is why I don't know if it will even be possible to extend the doc blocks in a generic way that does not break half the applications out there. When extending doc-blocks there is probably new method required $refl-getParsedDocComment() which then returns an array of metadata for that particular refl instance. Now here the syntax would be a problem, can we find something that does not break for all the different usages of docblocks out there? Since the method/parsing would be nested, on request only it wouldnt break any application that does not use parsed doc comments. However for applications that do, a syntax needs to be found that: 1. does not break for various type hinting doc syntaxes 2. does not break for various commenting styles Can someone come up with additional pitfalls? greetings, Benjamin On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraskiz...@zend.com wrote: At 08:09 15/09/2010, Stas Malyshev wrote: Phpdocs aren't user documentation only, not for a long time (I mean the concept, not the particular application called phpDocumentor, of course). They are being used as metadata in many places. You could argue that's misguided but you can't ignore the fact that's what people do. The goals and usages of those tags are exactly metadata - and regardless of the annotations, I'd be happy if Reflection recognized it finally (by integrating some kind of phpdoc tag parser). I second that word for word. FWIW, I don't see it as misguided at all. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
Am 13.09.2010 20:35, schrieb Benjamin Eberlei: Developers are clearly not using doc blocks for their static configuration needs currently, even though the possibility exists. It just feels wrong. incidentally, I do;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
for example: $foo = 0; $foo += (int)'123abc'; // no error $foo += '123abc'; // E_TYPE Exactly. And to make sure we're on the same page: $foo += '123'; // no error +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Array Dereferencing
$result = new ResultMaker()-getIt(); I know that this is not much of an argument, but it works the same way in Javascript too, which is very convenient. The intended behaviour is obvious...even though it could be (mis-)interpreted by php. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi, I have only recently started listening in on this list and I usually find it quite interesting. This one especially so. But I think it's going nowhere...forgive me for saying so. I believe that those of you, who'll have a say in this decision, have already made their minds up and they can't come up with arguments to convince the other party... Maybe it'd help to summarize those arguments in a few concise words instead of lengthy paragraphs, if that's even possible. Also it'd be nice to know the exact goals of this new syntax, be it strict- or autocast- types. Goal of typed scalar function parameters: + Type-Safety within function (granted by both) + Self-documenting Code (granted by both) + ... Pro strict-type-enforcing: + Precise Errors/Warnings + Prevents data-dependent errors + ... Pro autocast-type-hinting: + Code-readability/compactness + Convenient + The PHP-way + ... Feel free to add any arguments to the list...;) Cheers Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named Parameters
Hi,
I was only loosely following the discussion about this topic, so please
flame me if I got this wrong;)
I tend use the array-alternative alot which fits my purposes nicely
except for default-values. If named-parameters are introduced in this
proposed way, I don't see any advantages other than that it's official
syntax.
As I understood it wouldn't be more efficient, since it would actually
be just like an optional array parameter, automatically added.
Also if I have to use func_get_args to access those values, and they
will be mixed with the non optional args I don't think I'd actually
adopt this new syntax.
As I am using it now:
function foo($x,$y,$options=array()){
if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
/* 1 */
}
foo(1,2);
foo(1,2,array('opt1'='no-foo'));
Proposed new syntax of this case:
function foo($x,$y){
$options = func_get_args();
if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
/* 1 */
}
foo(1,2);
foo(1,2,'opt1'='no-foo');
This does not provide anything new to me as a programmer and even
introduces a non-selfdocumenting behaviour ($options is not in the
function-header) so the user has to *know* about the possibility of
passing any options.
What would really assist me in a self-documenting manner would be the
possibility to specify default values for those options in the function
header, which could also act as a filter.
something like:
function foo($x,$y,$options=(
'opt1'='foo',
'opt2'='bar'
)){
/* 1 */
}
foo(1,2);
foo(1,2,'opt1'='no-foo','opt3'='unspecified-option'); //opt3 will not
be within $options.
This would provide me with something which implicitly handles
default-values, defines which options can be passed and filters out
options which are not allowed. $options could be an array or a stdObject.
Personally I'd prefer a wrapping of any given optional parameters like:
foo(1,2,('opt1'='no-foo'));
This would even allow for multiple optional-parameter-lists.
foo(1,2,('opt1'='no-foo'),('other'='some'));
The advantage of such a mechanism shows wehn the second list is passed
on to a second function.
function foo($x,y,$options=(
'opt1'='foo',
'opt2'='bar'
),$more=(
'other'='ok',
'more'='x',
)){
/* 1 */
bar($more);
}
function bar($options=(
'other'='ok',
'more'='x',
)){
/* 2 */
}
Although I have to admit that the filtering would hamper the
extendability becaues foo() would filter out valid options for bar().
This could be mitigated by introducing the ... syntax. (ex. $more=...)
No offense. Just my (probably naive) thinking while reading this thread.
Cheers!
Lars
PS: Also, what do you guys think of an additional (optional) possibility:
function myFunc($a, $b, ...$options) // sort of like Java
and this way $options can be filled, so people don't have to keep
using func_get_args to get all the arguments.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistency redesign
I love empty, because its fast and compact. checking an array for a boolean value when a key does not exist, like here: A: if ( empty($foo['x']) ) echo 'no x'; this does not throw a notice that 'x' does not exist and is the fastest variant compared to these two, even if 'x' exists. I especially like the lack of ! to negate the condition. B: if ( !$foo['x'] ) echo 'no x'; this is simple but not faster in any case and throws a notice if it is not set. C: if ( !isset($foo['x']) || !$foo['x'] ) echo 'no x'; this is very correct but clumsy and slower than empty() in any case as far as consistency is concerned I think that it behaves the same as B C...but I may be wrong:) PHP always had a canny behaviour when converting any value to a boolean, but when I got used to it and escaped the common pitfalls, I started liking it for it's compactness and it's naturalness. of course, an empty string is empty(), an empty array is empty() and zero is empty()...naturally. The atypical behaviour that it throws a fatal error when using it like this: if ( empty(bar()) ) probably stems from the fact that it's really fast;) it's not very bad though... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Strange phenomenon
Hi, I posted this problem to the suhosin forum because I thought that this patch might be responsible, but I am not so sure now...(just because someone, said so;) http://forum.hardened-php.net/viewtopic.php?pid=1650 Would you mind reading it and pointing the finger at someone else?;) Thanks alot. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
Not quite. It creates a hash of an object, so two objects with the same data yield the same hashes: var_dump(spl_object_hash(new stdClass()), spl_object_hash(new stdClass())); I don't believe that it's data dependent. Rather in your example the same memory-space is used for those two objects because they don't exist in parallel. The first is cleared before the second is instantiated. ? $x = new stdClass(); $y = new stdClass(); var_dump(spl_object_hash($x), spl_object_hash($y)); ? This yields a difference. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
Oh, that clears everything, please ignore my previous post. Still, don't you think this is a bit misleading? IMHO, new object should always have the unique id(or hash in terms of spl)... I don't like it either;) But it does exactly what Stanislav Malyshev described: it hashes the tuple of C pointer. Misleading in this case is that this is only unique as long as the compared objects exist at the same time...then they can't inhabit the same memory-space. But because php clears and reuses memory as soon as no pointers to the object exist (reference counting). In this case php uses the exact same tuple of C pointer for the next object as the for the previous one. At least...that's my interpretation of this behaviour;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
What I actually need, not the object hash but simply its unique id.
And in this case object(Foo)#1 would be just fine. How can I get it?
That was my original Question too;) It's been stated that the automatic
cast into a string even if it does not implement the __toString()
function was absolute nonsense...but it really helped alot when you
needed to check for errors quickly and easily. Why make something harder
than it has to be.
Why not allow the old behaviour as long as the __toString is not
implemented? Or rather something like a default implementation which is
used autmatically for every class which doesn't implement it itself?
public function __toString(){
return 'Object '. get_class($this) .'('. get_object_id($this) .')';
}
That'd be nice and no code breakage would result. Isn't that an approach
that fits into the PHP philosophy? The new behaviour reminds me of
Java's the more userland-code, the better.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
The problem is that there is no such unique id in the current engine. Okay!;) That's a very good reason, I guess;) Explains a lot. Why not use spl_object_hash instead of the old default behaviour? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] toString() and Object #ID
Hi there I just tried to switch from 5.1 to 5.2.3 and got thrown off right away by: Object of class MyObject could not be converted to string I googled a bit and also read any Messages in the internals list but couldn't find a decisive answer as to wether this will stay this way or not. In the PHP 5 Bug Summary Report I found Bug # 40799 change string conversion behaviour for objects not implementing __toString() which is still open. I don't want to complain or anything but I'd like to know wether it's feasible to wait for a change in this current, modified, behaviour or if it's going to stay this way. I used the previous behaviour mostly for debugging purposes where I wanted to get a visual (string) handle for any given object, which helps ALOT when trying to figure out wether one has a copy or the original and wether to references point to the same object(obj1 === obj2 is not always helpful). Is there any other way than casting an object to a string to get an objects #ID? Thanks for your time. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
Hi. Our 'newbie' at least has a good chance of figuring out $a = [1,2,3] vs.$a = array(1,2,3) is different than $a = foobar(1,2,3) I am probably out of my depth here...but I actually find the argument about wether to introduce this syntax or not, very entertaining...it's a classic example of human individuality. great really;) The argument against introducing the new syntax, that says, that it's less searchable,...well...why not improve the search functionality of the php-documentation? it would help with all the other operators (and magic functions and language constructs) if the search-function would try to match the search-input against operators and constructs, no? I know that google won't show anything worthwhile when queried about php [] or the like...but...the php-documentation is very good and maybe we could improve access to it...a newbie could then query all he wants in the php-doc page. No good? Lars -- 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
That's correct. However, it is not guaranteed that your unset would
delete last reference - there can be references on stack, in temp
variables in current expressions being calculated (function call could
happen in mid-expression), etc. Of course, it might be that your code
is very controlled so you know it never happens, but as general case
you can't rely on it.
Ok. I got your point. You are right that it's hard to predict where
references could be found.
Also, if you check only zval refcount, you might unset objects that
actually are referenced from other places but by different zvals,
since one object could be referenced by a number of zvals.
I am not familiar with the term: zval...My understanding of php comes
from extensive usage...Can you give me a specific example?
$foo = new MyObject(); //ref count to Object #1 is 1
$bar = $foo;//ref count to Object #1 is 2
if ( ($zapp = $bar)-doIt() ) {...} //ref count is 3 or 4? but it
doesn't matter really...
I also believe that my reasons for this feature only require that there
are not any less references than are returned by ref_count()...I am
aware that the usage is for quite an advanced concept...but why
shouldn't PHP also be used for this.
The one argument against this feature that carries the most weight, for
me, is that PHP might change the behaviour of its memory management and
then keeping count of references would be an unecessary overhead, which
might lead to my code not working anymore if the feature were to be
dropped. Are there likely to be any changes in the future?...and is
there an other solution to this concept? I find it rather neat...;)
Especially if you couple it with the magic function __wake() where the
objects re-register themselves in the cache-list...
?
class MyObject {
...
public function __wake(){
self::$instances[$this-id] = $this;
}
...
}
?
In this case all objects not referenced by any variable in the $_SESSION
array (or it's descendants), would be destructed at the end of the
script. This way the objects remain unique even across sessions and some
kind of cleaning up is done by the serialization process. The trouble is
that this only works at the end of the script where of course even the
current stack is not used anymore. So I can't use this principle in a
function-call. Or does anyone of you have a different solution?;)
--
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
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. -- 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
Note that the engine does not guarantee you any particular value of the refcount. Passing parameters around, accessing variables, etc. may change the refcount. One thing the engine guarantees you is that once no links to the variable exist it would be destroyed (which may not happen immediately after you do unset, for example, but probably would happen soon). So actually figuring out if the object is referenced by any other place could prove non-trivial, depending on the application structure. I don't understand the problem really, because I am aware that even a parameter counts as a reference (why not?)...it wouldn't matter in my case because I am in total control of the last two references...so if there are more, I keep it. Tracking the references manually is not really an option because it's such a large project. I don't understand the part about the engine not guaranteeing the destruction immediately. Because as soon as the ref-count decreases to zero it can be removed from memory...it's different in java and other languages which don't use ref-count but more complex algorithms like mark-and-sweep and such, they only are run once in a while and may not be triggered manually...so, I'd understand it in that case. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP Object-Caching and Reference Counting
Andreas Korthaus wrote: Some time ago I created a patch to implement a ref_count() function which works the way you suggested. But I'm not sure if it's OK/complete... and I'm not sure if something like that is really needed in the core (and I'm definetly not the person to decide on that ;-)). Wow! This is great news...though I have no idea what to do with the patch and how to apply it to the php-source-code. The trouble is that I have to use the default php-engine because it should be runnable on any host...with some extensions. I don't guess it'd be possible to pack the functionality into en extension which could then be loaded more easily into the engine? Anyway, I attatched a simple patch against current 5_2 branch to this mail, perhaps it helps. Thanks anyway! It was an interesting read though my c and c++ knowledge is far from complete so i don't understand the workings, really...Maybe, if I feel restless, I'll have a look at the sources, though I wouldn't know where to start. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Object-Caching and Reference Counting
Hello there...
I am making my debut appearance here hoping that I am not giving offense
to anyones well honed php-instincts or programming practices with my
feature-request. This is what it comes down to, I guess. A Feature
Request for some meta-info on the instantiated PHP-Objects. Specifically
I want to know how many references are currently pointing to any one
object. Since PHP's Memory Management is based on Reference-Counting
this information should already be available somewhere. Not knowing
any php-source-code internals, I can't even guess at the problems which
prohibit the implementation of such a feature. Nevertheless I'd like to
point out an advantage to the community if the reference-count were
available.
I have been working on a large project for 6 years now and I got to a
point where I'd like to cache certain objects singleton-like. To better
explain my problem I provide this small example which surely is
error-prone but should get the basic idea across.
?
class MyObject {
private static $instances = array();
protected $id;
private function __constructor($id){
$this-id = $id;
}
/**
* Returns an instance of the class.
* If no object was instantiated with the given $id before,
* it will instantiate a new object which will be associated
with the given $id.
*
* It will also check the current memory-usage and if its used
up for more than
* 80% it will call the collect() method.
*
* @param int $id
* @return MyObject
*/
public static function getInstance($id){
if ( !isset(self::$instances[$id]) ) {
//check the used up memory wether to collect unused
objects or not
if ( memory_get_usage() ini_get('memory limit')*0.8 )
self::collect();
self::$instances[$id] = new MyObject($id);
}
return self::$instances[$id];
}
/**
* Removes any object from the cache-list which is not
referenced anymore.
* (safe for the list and the local-reference to it)
*/
public static function collect(){
foreach( self::$instances as $id = $instance ) {
if ( reference_count($instance) 3 )
unset(self::$instances[$id]);
}
}
}
?
As you can see I boldly used the function reference_count(Object) even
though it doesn't exist. This is exactly what I'd need to allow my
concept to work. I keep thinking of any other solutions, but up until
now, I didn't find any better solution for this problem. Of course I can
always ignore the memory usage and hope that it wont hit the limit...but
hoping is a rather ethereal and mystic idea which doesn't go well with
my preferred down-to-earth 1 plus 1 equals 2 programming.
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.
Thanks for reading this far.
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
