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 a
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
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 th
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 '
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 fu
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.
espec
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 absolute
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 n
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
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 s
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:
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 m
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 chang
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
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
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
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 int
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://w
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 fol
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 hi
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, yo
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 <=> PH
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
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 c
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
re
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
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
co
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
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 f
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 unsub
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
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
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 i
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:
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://w
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 mi
se 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 +
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 ca
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 t
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
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.
Um
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'
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 c
Am 10.05.2011 09:44, schrieb Ferenc Kovacs:
On Tue, May 10, 2011 at 9:01 AM, Chad Fulton wrote:
On Mon, May 9, 2011 at 10:46 PM, Lester Caine 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'
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, readab
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 Birke
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{
pu
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
versi
+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
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 ag
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, visi
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
$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 Ma
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 ca
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
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 especiall
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
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 po
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
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.ph
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 "abs
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.
I
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'
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
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
;-)).
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 immediate
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 woul
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. Specifical
68 matches
Mail list logo
