Hi Ivan,
> php://memory/
> php://temp//maxmemory:
It's not that hard to write such an function in php.
(http://www.php.net/manual/en/function.stream-wrapper-register.php).
I even once wrote an handler like "string://data-right-here" which
allows to read (only) the "data-right-here" as a
> So why not avoiding this by adding it as methods of the scalar variable
> instead, aka autoboxing.
> This would allow the new api to be closer to what people are used to from
> other languages, needs far less typing and IDE autocomplete of available
> functions pr type with "->".
I would also
> JSON and serialize() are (inherently) different serialization formats with
> different use-cases [...]
Yes, and json requires that all strings (including the keys) has to be
valid utf-8, and I'm sure that's not always the case (serialize can
use binary data in both places).
--
PHP Internals -
> I imagine the implementation could be something along the lines of checking
> for the '__struct' key when somebody attempts to use method-call syntax on
> an array, invoking the appropriate method with $this referencing the array
> you were using.
>
> The rest of the time, a struct, for all inten
HI,
I also really don't like it.
if you have a try/catch within a for, will it continue the try or for?
(or have I to use "continue 2" to reach the for) At least use another
keyword to make it more clear that you don't want to continue a loop
at the beginning but a catch statement after the excep
what about patch preg_replace to accept callbacks?
example:
preg_replace(array(
"/pattern1(.*)/",
"/pattern2(.*)/"
),
array(
function ($pat) { ... } ,
"replace"
)
, ... );
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
> There are some weird questions that come up with that. For example, if an
> array item is an object that implements both __invoke() and __toString(),
> which should be fired? Is it a string? Or a callback? What if I pass a
> literal string "strlen", is that a callback, or a replacement?
You're r
Just an idea: why not also use ^ (or another operator) to access the
value? (maybe as an additional way to get/setValue)
$foo = ^$user->name;
echo 'Hello '.^$foo;
^$foo = 'Bob';
(using the same operator will conflict when you are accessing a
property of an object which is a PropertyReference)
-
On Mon Sep 9 03:18 PM, Nikita Popov wrote:
>
> I created an RFC and preliminary implementation for named parameters:
>
> https://wiki.php.net/rfc/named_params
I really like the idea!
On Wed, Sep 11, 2013 at 2:16 PM, jbo...@openmv.com wrote:
>
> My preference would be to only support named pa
Maybe it would be good to talk to the developers of that package? They
might have some valuable input on how to design a built-in `enum`
feature.
It might also help them plan out a migration path.
On Mon, Jun 15, 2020 at 11:18 AM Ilija Tovilo wrote:
>
> Hi Marco
>
> >> I created a new RFC for r
feel each one should really "carry its weight". But if
this one does, that is fine.)
Alex
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> Why is there a 15 byte limit in the first place?
Presumably it might be so that multi-megabyte strings are not dumped
to the console when printing out a stack trace. (Disclaimer: I have
not touched the relevant code and am just guessing.)
--
PHP Internals - PHP Runtime Development Mailing List
hem. This may break a few
users' code, but in a way which will be easier for them to debug than
if the old methods were kept but subtly changed in behavior.
Code to implement this change is here:
https://github.com/php/php-src/pull/5384/files
Your comments will be appreciated,
Alex Dowad
-
Dear Levi, I will add a test case to the PR to ensure that things work
properly in the described situation.
On Fri, Jun 26, 2020 at 3:57 PM Levi Morrison
wrote:
>
> On Fri, Jun 26, 2020 at 12:45 AM Alex wrote:
> >
> > Dear PHP Internals,
> >
> > I would like to pr
Dear Levi Morrison, please see this added test case:
https://github.com/php/php-src/pull/5384/files#diff-dc4d304baf106b4a30432f80dae1a538
The iteration behavior of the modified SplFixedArray is quite humane
even in the face of changing array size.
--
PHP Internals - PHP Runtime Development Maili
I guess the first question is: Why is it so slow? I don't think that using
shared memory to store data is inherently slower than storing it anywhere
else.
It might be that spending an hour or two profiling and optimizing could
slash this time right down.
On Wed, Aug 26, 2020 at 9:37 AM Nikita Pop
rting from scratch.
- If you are still struggling, run your test under gdb so you can get a
stack trace when it segfaults. It's as simple as "gdb --args ". Make sure that both the PHP embed SAPI and your own test
code were compiled with debug info enabled.
Alex
On Wed, Aug 26,
I like it!
What is the $use_flags parameter for?
On Sat, Aug 29, 2020 at 10:24 PM tyson andre
wrote:
> Hi internals,
>
> The primitives any() and all() are a common part of many programming
> languages and help in avoiding verbosity or unnecessary abstractions.
>
> -
> https://hackage.haskell.o
d of one unique counter for ALL fields.
3rd. Last but not least... This is a feature only implemented in Sybase library
functions, so when creating cross-db applications, it is much
more difficult to implement generic code.
I would appreciate hearing from the PHP Team about this.
Thanks in
This email is just to gauge the response for some syntactic sugar to be
added to PHP in regard to slicing an array.
My proposal is something similar to Pythons slice, in PHP this would look
like:
$slided = $array[1:4]
This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
igno
I've had a quick scan of the list at https://wiki.php.net/rfc but cannot
seem to find anything. I'll read more carefully through, or is there a
different list elsewhere which I should look at?
On 19 March 2015 at 21:03, Larry Garfield wrote:
> On 3/19/15 3:49 PM, Alex Bowers wro
On 19 March 2015 at 21:11, Larry Garfield wrote:
> On 3/19/15 4:06 PM, Alex Bowers wrote:
>
>> I've had a quick scan of the list at https://wiki.php.net/rfc but cannot
>> seem to find anything. I'll read more carefully through, or is there a
>> different lis
On 19 March 2015 at 23:23, Rowan Collins wrote:
> On 19/03/2015 20:49, Alex Bowers wrote:
>
>> My proposal is something similar to Pythons slice, in PHP this would look
>> like:
>>
>> $slided = $array[1:4]
>>
>> This will get the elements in
>
> I'm not sure why it would duplicate the item like that. My interpretation
> of $array[$start:$end] would be "an array containing all those elements of
> $array with a position more than or equal to $start, but less than or equal
> to $end" ($position >= $start && $position <= $end).
>
I agree
>
> The @ symbol in my examples is not a special marker that is meaningful on
> its own; the parser wouldn't even see it as a separate token. The syntax
> for key access is $array[$key], the syntax for positional access would be
> $array[@$position]; chosen to look similar, but one is not a special
>
> I've tried implementing python style slice on both strings and arrays in
the past (I don't seem to have an existing branch with it in any more
> though it seems). The biggest problems I hit were regarding the syntax, the
> functionality itself worked.
If you've got a link to your messaging t
>
> That said, I'm a little older and wiser than I was then, I'd still be
> interested in looking at this. I'll try and come up with _something_ that
> works over the weekend.
I started on the code last night, but didn't get very far. I got it to
match the T_COLON, but no logic or parsing has bee
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist, or
should it be a parse error?
>
> If your branch is available on github let me know, more than happy work on
> it with you.
I'll publish it tonight (GMT), I'm at work at the moment.
Thanks!
On 20 March 2015 at 13:04, Rowan Collins wrote:
> $version{4:} = '7!';
I'm sure this is a slight oversight on your end, but just to check. The
change of using {} instead of [] is not because its a string, and is just a
typo / example correct?
t by index) which should be a separate RFC thread, assuming this one
gets accepted to be expanded upon.
On 20 March 2015 at 13:04, Rowan Collins wrote:
> Alex Bowers wrote on 20/03/2015 12:32:
>
>> We also need to consider then the possibility of setting data by position.
>>
&
>
> It's an alternative syntax
Learn something new every day.
I guess this RFC will need to support both then for consistency reasons; so
it will be down to the end user to determine how they want to separate them
if they choose to. But I don't think we should only match {} for strings
and [] fo
mentation pages provided
and clear naming for the differences between them.
On 20 March 2015 at 13:21, Rowan Collins wrote:
> Alex Bowers wrote on 20/03/2015 13:10:
>
> $array['x':'z'] = []; // Remove all elements with keys between 'x' and
>> 'z&#
Thanks,
Alex.
>
> Certainly it breaks BC (and would presumably have to wait until PHP 8), but
> if we were starting from scratch today, why would it make sense to have two
> syntaxes that do exactly the same thing?
Maybe you misunderstand me, I am against using two syntaxes for different
things.
re order dependant
whilst using the associated keys isn't correct in my view.
On 20 March 2015 at 14:41, Rowan Collins wrote:
> Alex Bowers wrote on 20/03/2015 13:40:
>
>> Still not sure how we can implement a range of strings. But since thats
>> for a different feature, I&#x
>
> IMHO, stick to offsets in the first instance, this is a slice notation,
> first order of business is to make it behave like array_slice (+on
> strings). Assoc key based slicing feels pretty wrong to me at this point.
I have to agree, we are getting ahead of ourselves.
A quick summary of what
>
> I'd be tempted to introduce the ability to get a single element by
> position as well
Absolutely agree.
Can we agree on a symbol do you think, or should the RFC continue for the
symbol discussion?
RFC.
On 20 March 2015 at 16:17, Leigh wrote:
>
> On Mar 20, 2015 4:00 PM, "Alex Bowers" wrote:
> >>
> >> IMHO, stick to offsets in the first instance, this is a slice notation,
> first order of business is to make it behave like array_slice (+on
> string
On 20 March 2015 at 16:17, Leigh wrote:
> $thing[-1:] is in scope for arrays though
How would this work for slicing?
Since doing [@-1:] would mean get the last element to the end.
And doing [@1:-1] is the exact same as doing [@1:] since -1 and blank both
mean the end.
on initial reading. But variable names and so on should be used to help
distinguish from array or strings anyway.
On 20 Mar 2015 17:02, "Vik Hudec" wrote:
> Hi Alex,
>
> On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
>
> > But I don't think we should only match
>
> Yes, I'm very conscious of the substantial BC break, which is why I would
target PHP 8 (or even 9, following a deprecation cycle).
I would guess PHP 8, since you can deprecate things at 7.x
Either way, if you make this a separate thread so we don't get off topic,
and i'm sure you'll get man
>
> That's why I propose a new syntax such as $thing[@0], $thing[@-1]
I have to agree that a new syntax will be required by this.
On 20 March 2015 at 18:17, Rowan Collins wrote:
> Leigh wrote on 20/03/2015 16:17:
>
>>
>> For $thing[-1] I think this only works for strings (and I have this
>> im
Grand.
Thank you.
On 20 March 2015 at 19:00, Ferenc Kovacs wrote:
>
> On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers wrote:
>
>> Good day,
>>
>> My Wiki username is: alexbowers
>>
>> I have an RFC currently under gauge within the thread (link:
Is everybody happy with the RFC being called 'Slice Operator', or is there
a better name for it?
On 20 March 2015 at 18:17, Rowan Collins wrote:
> Leigh wrote on 20/03/2015 16:17:
>
>>
>> For $thing[-1] I think this only works for strings (and I have this
>> implemented, should probably RFC it)
>
> The concept itself can still work, but it’d need a token other than @.
This is the symbol currently being used for examples, but thats all it is
currently. Nothing is set in stone (and most likely will change), not just
for this reason but for the reason that I mentioned earlier in the thread
On 20 March 2015 at 20:10, Sean Coates wrote:
> That’s no different than `@` being invalid because it’s already in use.
The syntax would be [*from:to], which would currently throw a parse error
(since asterisk is required to be placed between two numbers), so this
would be different.
Alternati
>
> There’s no existing unary form of * and ^, though, so I think they’d both
> be available in this context (^ is my preference).
I think that is also my preference too.
On 20 March 2015 at 20:17, John Bafford wrote:
>
> On Mar 20, 2015, at 16:10, Sean Coates wrote:
>
> >> I posted four sug
The latest comments in this thread are talking about having a symbol before
the range to show that it is by positional index. Current propositions for
this are ^ and *.
I'm not sure how such operation would be useful
Anywhere on the front-end where a foreach() is used, and expects at most
say, 1
On 20 March 2015 at 20:52, Stanislav Malyshev wrote:
> I'm not sure how such operation would be useful, and it definitely would
> not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive
> semantic, or [0:0] with inclusive semantics) would return completely
> different things. That
>
> // alternative old
> foreach(array_slice($results, 0, 9) as $result) {
> echo $result . "\n"; // 1 2 3 4 5 6 7 8 9
> }
> Not so bad, in my opinion.
To be the same, your example would have to be:
// alternative old
foreach(array_slice($results, 0, 9, true) as $result) {
echo
>
> Why not use array_slice for it?
There certainly are ways to do most of what this RFC covers, however most
of them don't lend themselves well to clean code in my opinion.
Thats why this RFC is listed as being syntactic sugar.
On 20 March 2015 at 21:30, Stanislav Malyshev wrote:
> Hi!
>
> >
On 20 March 2015 at 22:12, Stanislav Malyshev wrote:
> You're not using the keys in foreach, so why you need to preserve them?
This was merely an example of the features equal part in current code, not
a real life use case.
Using the new syntax will keep the keys preserved, therefore any examp
On 20 March 2015 at 23:03, Stanislav Malyshev wrote:
> $array[*1:4] by reference -
> what is actually passed?
>
Implementation is not something I have looked into for this yet, so I am
unsure how this would be possible; but by passing $array[*1:4], you'd be
passing an extracted array which is a
Would it make more sense then to have a RFC for array by positional index.
No range or anything initially (that will be a separate RFC), but simply to
get the value of an array by positional index?
$array[*4] to get the item in position 4.
The deadline for PHP 7 features has passed
On 26 March 2015 at 20:54, Michael Morris wrote:
> Per PHPsadness...
>
> http://phpsadness.com/sad/30
>
> Since 7 is allowed to have BC breaks this would be the time to fix this.
>
> I'll let someone with more seniority actually write this up - but plea
I think deprecating it is a good idea, and looking at the documentation it
does mention that not providing it is the intended option; so it isn't a
complete surprise for it to become deprecated.
On 31 March 2015 at 19:49, Anthony Ferrara wrote:
> All,
>
> Ever since we introduced password_hash()
Is the last one really a strict? Sounds like it should be a warning to me.
Similar to when you for each over something not an array
On 1 Apr 2015 15:58, "Nikita Popov" wrote:
> On Wed, Mar 25, 2015 at 5:14 PM, Nikita Popov
> wrote:
>
> > On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov
> > wrote:
2012/7/12 Anthony Ferrara :
> Hello all,
>
> Since the discussion has died down around the concept, I have updated the
> RFC and moved it into Proposed (under discussion) status.
>
> I have updated the RFC to include a section on discussion points containing
> points that I know were raised but I f
2012/7/12 Nikita Popov :
> On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach wrote:
>> 1. The resulting string should have a version information. For example
>> the first char. the example hash will look like
>> "1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6
at there's even a valid use-case for such a function. Can you elaborate
> over why you would use such a function?
I do not quite completly understand the version/algorithm here. I
think about fast checks for millions of hashes.
Hm. In my class, the string had a defined format. If it hadn&#
e reason of this discussion.
To implement this we need for example a special type of exception (e.
g. "interface non_displayable"), which will remove the error-messages.
--
Alex
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2012/7/14 Andrew Faulds :
> Well... if people have poorly configured servers spitting out debug
> info in production mode, I don't think it is our problem. It is
> theirs.
Do you want to make it secure or do you want to discuss?
--
Greetings Alex Aulbach
--
PHP Internals
fault
exception-handling which can be overridden (like the error-handlers).
Could be an interesting concept. :) And of course its something which
needs time.
--
Sevus
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this case it's also concepts
of handling errors. And much other stuff.
Again: This is off-topic. The RFC is very fine, it's a good work, I
like it! Really, I do! :)
But for me - as PHP-developer - it's like renewing all doors of a
house with newest technique, but forgetting the wind
2012/7/16 Galen Wright-Watson :
> What about an approach like PDO, where the password functions would
> generate errors by default, but could be configured to throw exceptions?
I think it makes things more complicated instead of less. For security
simpleness is important.
--
Alex A
tering, it's extending to a new level. Which is in
the beginning always uncomfortable. :)
And I think it depends on what architecture-features PHP should
follow. E. g. simpleness or security (security means often simpleness)
or ... or ...?
--
Alex Aulbach
--
PHP Internals - PHP Runtime
al for some other things (many string functions have it), I
suggest that it is not part of random_string(). Make a new function
str_from_character_class(), or if you use pcre like above
pcre_str_from_character_class()?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
regex in this case is maybe faster)
trim("\rblaa\n", str_charset('/[^[:print:]]/'));
// remove invisible chars: when doing this with very big strings it
could be much faster than with regex.
str_replace(str_split(str_charset('/[^[:print:]]/')), "\rblaa\n");
There are many other more or less useful things you can do with a
charset-string. :)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
'),
range('A','Z'),
range('0','9'))
))
So I think, if we don't need charset-encoding, we won't need
this special functionality.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Ivan,
> try
> throw new Exception('foobar');
> catch(Exception $e)
> var_dump($e->getMessage());
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
PS: And if without brackets should be forbidden.
ut the implementations in other languages. :)
PS: I would like to see that yield goes hand in hand with the iterator-stuff.
PPS: Ok, maybe a change isn't really needed, but I think how to use
this in a good manner (to avoid the problems mentioned above) should
be part of the docs.
--
Regards, Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
set, only an empty.
>
> Does this seem like a possible improvement we can work on? Anyone
> interested in championing the change?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2012/7/20 Ivan Enderlin @ Hoa :
> On 20/07/12 15:32, Alex Aulbach wrote:
>> If you use try/catch that much, that you begin to think about the
>> syntax, you have an architecture- or design-problem.
>
> Not sure about that. First, it was an example. Second, it happens more o
function _greater($a, $b, $c, $d)
{
if ($a > $b) {
return $c;
}
return $d;
}
My suggestion just is: At any point everybody needs one more operator
for "his stuff". But that's why functions exists.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Developmen
ator_handler_once() should be possible, so that a second
call isn't executed.
Other things: I don't like the first operator (the operator-name). Any
goof idea?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
OOP - but that's a different topic.
Existing operators shouldn't be changeable. My suggestion is the
"PHP-way" of operator driven development for a very special problem,
which is making very repeating but complex things very short, nothing
else. :)
Or in other words: In detail it'
we need to have it as _function_?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
thing which is, when called once finished once. I
don't like mathematics, but that is one of the definition of a
function:
http://en.wikipedia.org/wiki/Function_%28mathematics%29
"each input is related to exactly one output"
Couldn't be so complicated to introduce a new name for that,
x27;s a different topic from the suggested feature...
Which is a much better idea in general. My suggestion was only for a
very special context and should be easier to implement.
I currently think, this discussion needs more time, because I begin to
forget, for what this is really needed. :)
I
d is not a function.
And if other languages do so, my argument will be the same.
We need not to make
the same mistake again! :)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ittle bit more for that.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I just want to make such simple mistakes not
so easy and the afford is worth the results.
You can argue: "Those mistakes will always happen". I say "Yes, of
course, but if we have the chance to reduce those mistakes we should
do it."
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
o
it. I always think of Bob Ross, when I explain PHP.
But it's ok, there are no mistakes, there are just happy little accidents. :)
[means: I will not complain any more]
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
d how to make it a little bit better and I explained why.
I'm just wondering... for whom is PHP developed, for the PHP-internals
or for PHP-developers?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in the C#-way.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the "mass" of anonymous PHP-programmers really needs and that,
what is written in this internals list.
I with you introducing new features like this, but it must be done in
a way that is more self-explaining, has a low learning-curve. Yield
implemented like this dosn't match this crite
not necessarily a good programmer make, nor
> an expert in other programmers.
It's not sufficient but neccessary.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
means: If we
have the chance to make things easier we must do it.
Experience: The current concept dosn't "feel right" for me. I like to
listen to my belly in those questions, because he is in most cases
right. With the change I suggested he stops grumbling.
Please correct me if I use
doing.
Experience: Most PHP-programmers are not so experienced like most
programmers in other languages.
(Can't be proven, but I would bet for it.)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
who you're talking
> about) routinely have to spend time understanding the purpose of a given
> function. To assume that one can pretend to understand a function without
You dream. You don't have time. You need to get things done. :)
> having seen and questioned an unfamiliar ke
ple with the original iterators...
But it's just what it does.
> BTW: I still don't think that the generators need a unique word and I suggest
> using functions, but I didn't read al the mails chain, so I assume that I'll
> find there the answer.
Of course
- think at
first try this isn't implemented with all consequences, so they may
not be helpful to see the difference.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
about this new feature
before they first will see it. But we can. And maybe we should,
because they are the users of what we do.
And we don't need to look at all the others. There is just no need to.
They didn't even use PHP. :)
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
troducing it. And - this is my secret hope :) - this will kill the
need for discussion of this *now*. The future will show us, if this is
accepted/needed or not. Because who knows? This gives also more
options for the future and is in my eyes good design.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ay arround, it's one of the best
things, that have been introduced, because before it, a very small
write error had big impacts.
I see - as you - the need to make simple things more short, but
removing warnings from existing code constructs is definitly the wrong
way.
--
Alex Aulbach
h()..., of course remove it before verify!).
Every change (new algorithms etc) will increment the version. This can
help to detect the case when in version 79 bcrypt is removed because
too insecure/too old.
As said, currently not needed, but if someone likes to, here it is. :)
--
Alex Aulba
with the 'or' operator (or not ||)...
Which brings us back to the subject...
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
he parent
> scope, expecting to continue on later (think of it as a stop light where
> you let the other code run for a while until you go to the next one).
I think for people, which are - like me - more used with databases,
the cursor-concept is a good comparison.
Perhaps this could help a
rces, which can't be shared. For example: the file-read-example
doesn't lock. To implement locking new functions or a new class is
needed - hiding complexity.
Generators are (in my opinion) really nice for things which are
already in the memory. Not more or less.
--
Alex Aulbach
--
PH
1 - 100 of 214 matches
Mail list logo
