AFAIK is not possible with
"exists".
Regards,
--
Rowan Tommins
[IMSoP]
n($x)=>$x[array_key_first($x)], $rows)
Of course for a list-style array like the example shown, it can be a lot
simpler:
array_map(fn($x)=>$x[0], $rows)
Regards,
--
Rowan Tommins
[IMSoP]
to; if nothing else works, you might be able to pay someone to do it.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
being able to write $"Hello
#{Foo::bar()}\n" rather than "Hello " . Foo::bar() ."\n"
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, 17 Aug 2020 at 16:21, Matteo Beccati wrote:
> Hi Rowan,
>
> On 21/05/2020 23:53, Rowan Tommins wrote:
> > d) Support "chunked" transfer encoding (RFC 7230 Section 4.1)
>
> FWIW, I've just been hit by https://bugs.php.net/bug.php?id=47021 in a
> SOAP resp
anana',
4 => 'caramel',
];
$selected_option = $options[ $_GET['id'] ] ?? 'vanilla';
Casting between arrays and objects is a whole separate issue, and changed
in PHP 7.2; the RFC explains the issues quite well:
https://wiki.php.net/rfc/convert_numeric_keys_in_object_array_casts
Regards.
--
Rowan Tommins
[IMSoP]
arts: [ '<', '>Hello ', '' ],
expressions: [ $tag, $_GET['name'], $tag ],
modifiers: [ ['raw'], [], ['raw'] ]
);
It will take a while to figure out the details, but I think a powerful
feature like this is more worthy of adding new syntax.
[1]
https://developer.mozilla.org/en-US/docs
ointed out are similar to
visibility or scope modifiers - anywhere that could be an attribute will be
parsed as one, not as a statement, comment, or whatever else, so some code
changes meaning, and other code becomes a syntax error.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
always use fully-qualified names in attributes...
Regards,
--
Rowan Tommins
[IMSoP]
ance of matching something like "$foo =
$bar<> has a small disadvantage here, but it's also been
thoroughly rejected in a previous vote, and seems unlikely to suddenly make
a comeback.
Regards,
--
Rowan Tommins
[IMSoP]
useful if it was a re-cap of
arguments discussed in prose elsewhere, but it is not on its own a good
source of information for making a decision.
Regards,
--
Rowan Tommins
[IMSoP]
on, and what the
impact would be.
My vote, if I had one, would remain under "No" for this re-vote. There
seems to be no reason to allow this vote, but not allow another one next
week with a new suggestion, and nothing objective to choose between the
syntaxes.
Regards,
--
Rowan Tommins
[IMSoP]
tor discussed, this is
basically a subjective feeling, rather than anything substantial.
Regards,
--
Rowan Tommins
[IMSoP]
right of the letters, although #[] is
the only one that doesn't need any use of shift. Which mostly just goes to
show that pretty much any punctuation will be hard to type on some layouts
and easy on others.
Regards,
--
Rowan Tommins
[IMSoP]
nput is casted to 0 and thus producing
unexpected behaviour if the user is not aware of the current method
prototype.
Unless there are problems with the implementation, this seems like a
straight-forward win.
Regards,
--
Rowan Tommins
[IMSoP]
On Mon, 10 Aug 2020 at 14:56, Benjamin Eberlei wrote:
>
> On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins
> wrote:
>
>> The question asked was that _if the parentheses were made mandatory_,
>> would
>> this provide the same benefits ascribed to the other syntaxes?
syntaxes?
To avoid repeating myself, here are the previous posts where I elaborated
on this question:
* https://externals.io/message/111312#111342
* https://externals.io/message/111312#111354
Regards,
--
Rowan Tommins
[IMSoP]
is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.
Regards,
--
Rowan Tommins
[IMSoP]
ich in my view make this new feature unnecessary.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
arams#vote
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
te static
variables, since right now we don't think of a function as "belonging
to" a file in the same way it would belong to a class.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/ type of result inferred from
existing constant
function waste_time(BigNum $iterations = GOOGOLPLEX) { ... }
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ather subjective; is it the
"@" that makes it familiar? the lack of extra brackets? I'm not sure it's
fair to boil this down to a straight yes/no.
* "Tokens Used" seems to be an implementation detail, with no explanation
of why this would make a difference to anyone's vote.
Regards,
--
Rowan Tommins
[IMSoP]
it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
I agree that it is probably rarer than //... and /*...*/ but let's avoid
unnecessary hyperbole.
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 6 Aug 2020 at 07:40, Derick Rethans wrote:
> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > The confusing thing about this argument is that as soon as they have
> > arguments, attributes will have an ending delimiter _whatever_ syntax
> > we choose, because nob
process.
Opportunities that might, depending on a whole bunch of other factors,
come in PHP 10.0 or 11.0 are probably not a strong argument for a syntax
option.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
[Foo]@
With complex parameters:
@@Foo('hello @@ world', (1+2)*3)
@(Foo('hello @@ world', (1+2)*3))
@[Foo('hello @[ world ]', [1,2,3])]
@[Foo('hello @[ world ]@ again', [1,2,3])]@
Regards,
--
Rowan Tommins
[IMSoP]
not enjoy going through
every Composer package in my vendor directory, checking for or supplying an
appropriate patch, and then waiting for a tag or forking to create my own.
Regards,
--
Rowan Tommins
[IMSoP]
tory (i.e. @@Deprecated() rather than
@@Deprecated)? The rules for what could appear between @@ and ( are pretty
simple, and finding the correct ending ) should be pretty much the same
effort as finding the correct ending ], since both can occur in matching
pairs inside the argument list.
Regards,
--
Rowan Tommins
[IMSoP]
On Wed, 29 Jul 2020 at 03:31, Ryan Jentzsch wrote:
> https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
https://3v4l.org/guXbl#v800alpha3
You're welcome.
--
Rowan Tommins
[IMSoP]
have been able to tell, the client code now complies
with the spec for HTTP 1.1, although I struggled to find a list of
minimum capabilities.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ous HTTP 1.1 features are enabled in our
client code by default suggests that is frequently not the case.
Regards,
--
Rowan Tommins
[IMSoP]
because it's increasingly rare for a server to actually
honour the 1.0 spec.
My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.
Regards,
--
Rowan Tommins
[IMSoP]
/5899
I realise it's now rather last-minute for 8.0, so if anyone thinks it
should have more careful thought, or an RFC, it will have to wait. If
there are no objections, though, it would be nice to have it merged
before the freeze.
Thanks,
Rowan
On 21/05/2020 22:53, Rowan Tommins wrote:
Hi
bolt on in a hurry just to solve an issue with named
parameters.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/message/110004
[4] https://externals.io/message/110910#110961
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 25/07/2020 16:26, Chuck Adams wrote:
On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote:
If anything, I would argue for making both of these into errors, if
that's possible. I think the biggest risk with this kind of change is
not existing code relying on the old behaviour, it is code
by adding parentheses
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
a particularly good comparison for PHP.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ot;PHP"
in its name is a " fake namespace" at all - it is an object representing a
token of PHP source code, and thus a PHP token. Even inside a namespace,
there would be an argument for giving it that name.
Regards,
--
Rowan Tommins
[IMSoP]
needing to skip parameters, it would be great to see some ideas to make
those alternatives easier. For instance, if you think parameter objects
plus the builder pattern is the right way to go, how can we reduce the
boilerplate currently required to define the builder class?
Regards,
--
Rowan Tommins
[IMSoP]
you the same question I have asked others, but without much
response: would you vote Yes to an alternative proposal to officially adopt
a policy of _never_ using the PHP\* namespace, to eliminate future debates
about when to use it?
Regards,
--
Rowan Tommins
[IMSoP]
ium did in PECL)? Or
should the policy be that there are no namespaces used by the core?
Regards,
--
Rowan Tommins
[IMSoP]
t you're trying to catch here
is programmer mistakes, not unexpected run-time behaviour.
Regards,
--
Rowan Tommins
[IMSoP]
tures.
If the input is an actual array or object coming from "outside", you're
probably going to want a more extensible validation system anyway. Those are
really hard to design, and probably best left to userland where people can
choose the tradeoffs they prefer.
Regards,
--
Ro
ause you can't guarantee yours is the only reference) or an
optimised copy-on-write (mutate if you happen to have the last reference,
otherwise clone). It would be better for the language to implement those in a
user-friendly way than exposing the implementation details of refcounting.
Regards,
--
t also has much lower performance impact. Even the automatic form can probably
be performed by the compiler - e.g. if "new" was called in this function,
insert a call to "freeze" before the first time the object appears as a
function parameter
Regards,
--
Rowan Tommins
[IMSoP]
olution to the "modified clone" problem of
full immutability (how to implement withFoo methods), since any "frozen" object
could be cloned to get a mutable copy, which would be frozen before passing on.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
native I know of is the builder pattern
($builder->withFoo($foo)->withBar($bar)->withBaz($baz)->build()), which at
least makes the boilerplate scale linearly rather than exponentially, but
is still going to require dozens of lines of code to achieve what named
parameters can do with one.
Regards,
--
Rowan Tommins
[IMSoP]
u be more open to a version of the feature that was opt-in at the
definition site? Then your example could swap the hand-rolled documentation
and validation in "fromArray" for a fully typed signature in
"fromNamedParams", and the only compatibility promises would be ones
already made by "fromArray" anyway.
Regards,
--
Rowan Tommins
[IMSoP]
On Thu, 9 Jul 2020 at 18:14, Derick Rethans wrote:
> On Thu, 9 Jul 2020, Rowan Tommins wrote:
>
> > And yet we have repeatedly had discussions about whether this or that
> > feature should or shouldn't be prefixed with a namespace. If you think
> > the correct answe
- quite the contrary, it will mean
more time is wasted debating every case.
It's worth stressing that naming conventions are not new - we've had them
for global functions for many many years. We may talk about "putting things
into namespaces", but PHP's namespaces really are just names, so this RFC
could easily be called "update naming conventions for classes".
Regards,
--
Rowan Tommins
[IMSoP]
ious discussions and proofs of
concept before diving in.
[1] https://wiki.php.net/rfc/userspace_operator_overloading
[2] https://externals.io/message/105589
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lumn showing those
additions: https://rwec.co.uk/x/php-parse-errors/comparison.html
If there's no other comments or objections, I would appreciate if
someone could merge this in so it can be tested in the next alpha :)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
and what updates the user would
need to make.
Regards,
--
Rowan Tommins
[IMSoP]
On 29/06/2020 17:21, Marco Pivetta wrote:
Hey Rowan,
On Mon, Jun 29, 2020, 18:19 Rowan Tommins <mailto:rowan.coll...@gmail.com>> wrote:
On Mon, 29 Jun 2020 at 16:44, Marco Pivetta mailto:ocram...@gmail.com>> wrote:
> property accessors seem to perpetuat
it.md#detailed-design
[2] https://wiki.php.net/rfc/object-initializer
[3]
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly
[4] https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#with-expressions
--
Rowan Tommins
[IMSoP]
ut, something like: unexpected double quotation mark.
>
That would be a reasonable special-case; theoretically, the same would
apply for a lone single-quote, although I think the parser happens never to
see that as a separate token.
Thanks for the feedback,
--
Rowan Tommins
[IMSoP]
to parse the error message, since
the pattern /unexpected ([^"]+) "(.*?)"/ will always give you a token name
(even if just 'token') and its content.
I can re-visit that part if you feel strongly, though.
Regards,
--
Rowan Tommins
[IMSoP]
sted change was to include column
numbers; this appears to be feasible, but definitely more complex, and
with potential performance trade-offs. I hope to re-visit this later.)
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t. I also appreciate that I hadn't provided any
public updates on my progress, and what hurdles needed to be over-come.
But you did know I was working on a patch, so the simple solution would
have been to ask me before opening the vote.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Int
fully expect to have a
patch (and, if deemed necessary, RFC) in plenty of time for 8.0.
I intend to post a new thread with examples of old and new messages once
I've finalised the details.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
T
ew PHP\* names, and provide a userland polyfill for users upgrading
from the PECL extension?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
omplex rules of "it's
optional except when it's not", which I'm personally not a fan of.
Regards,
--
Rowan Tommins
[IMSoP]
-type), and __construct() was marked ": void", and
leave the rest of the logic to the generic code for handling those
declarations.
Again, I would be surprised if any style guide would forbid writing
"getIterator(): Traversable" just because the check is already enforced
imp
nitialise_object($classDefinition);
$newInstance->__construct(...$args);
return $newInstance;
If a constructor returns a value, it is simply discarded, so a signature of
void would be completely appropriate.
Regards,
--
Rowan Tommins
[IMSoP]
rectly by the parser.
In both cases, I think we know roughly what we'd like to see, so there's
not much else to say until somebody looks into actually doing it.
Regards,
--
Rowan Tommins
[IMSoP]
here be value in a "lightweight reflection" API, which
gave access to things like this without the full power or performance cost
of Reflection?
Regards,
--
Rowan Tommins
[IMSoP]
On 10/06/2020 22:38, Rowan Tommins wrote:
rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure
the user never needs to see it.
I'd like to clarify this slightly: I should have said "beyond renaming
... we should ensure" - I have no particular objection t
he unexpected token was, so that searching for "Parse
error: syntax error, unexpected" wouldn't give enough of a hint?
Other information currently missing from the message - e.g. column
number, hints about unclosed blocks - is likely to be far more useful.
Regards,
--
Rowan Tommins (né Coll
umber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
// Rust-style
#[ManyToMany(Phonenumber::class)]
#[JoinTable("users_phonenumbers")]
#[JoinColumn("user_id", "id")]
#[InverseJoinColumn("phonenumber_id", "id", JoinColumn::U
t;> function(<> int
$var) {};
Finally, typing up those examples, it occurs to me that @@ is quite a
"heavy" symbol - it has a large proportion of black (or whatever colour)
pixels - and inevitably a rather "fussy" one. I find it draws the eye
more than the angle-
-right operators, and so the
immediate association on seeing them is so obvious it's not worth
mentioning; to others, they just look like a new kind of brackets.
That association might actually be a good reason to avoid that syntax,
but if so it should be spelled out, rather than taken as a given.
y react to this one better. That's fine; we can make a
decision for subjective reasons, but let's be honest and say that.
Regards,
--
Rowan Tommins
[IMSoP]
ing almost the same thing.
> while not having to disable strict_types
It feels a bit like you want to "have your cake and eat it" here - if you want
a loose check and aren't worried about a few unusual values getting through,
why are you running in strict_types mode in the first pl
x;
Once converted in that way, you could safely pass to a parameter marked int
in strict mode, so wouldn't need a new pseudo-type.
Regards,
--
Rowan Tommins
[IMSoP]
a lot uglier than << and think a bracket-link
syntax looks clearer when writing multiple attributes on one line to avoid
long thin columns of code:
<> <>
public function test()
{
}
vs
@@Attr2("foo") @@Attr2("bar")
public function test()
{
}
Regards,
--
Rowan Tommins
[IMSoP]
1 a few days ago; I think
it needs someone to don their flame-proof armour and edit together a first
draft so that we can discuss specifics.
Regards,
--
Rowan Tommins
[IMSoP]
for
false anyway, defeating the purpose.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
low-level and expose nghttp2 itself
in some way?
[1] https://asgi.readthedocs.io/en/latest/introduction.html
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t;
- "\Attribute", but "\PHP\Attributes\Deprecated"
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ht even prefer your RFC, which is still marked "Under
Discussion": https://wiki.php.net/rfc/php_namespace_policy
It is possible that "officially declare that we won't use the \PHP
namespace" would get a majority, but that's not what this vote asks.
Regards,
--
Rowan Tommins (n
, and new directives are errors in old versions of PHP.
That doesn't necessarily mean we shouldn't use it for now, though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
xt option, e.g.:
https://gist.github.com/IMSoP/a685fed6589435530102d57138755511
What are people's opinions? Does this need an RFC, or should I just
submit a PR if nobody objects?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
quot;guard( condition ) else { throw new Exception; }" instead of "assert(
condition );"?
* "guard ( condition ) else { return; }" instead of "if ( ! condition )
return;"?
* "guard ( condition ) { complex logic }" instead of "if ( ! condition )
{
n addition to return, rather than having to invent special
syntaxes for each.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
d block oriented language, and CPP purports to add
Javascript-like complexity into a single statement.
I'm not sure what is "Javascript-like" about the proposed syntax, or why
using semicolons rather than commas makes it less so.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Int
ith all Mike's ideas, nor do I always feel the
mailing list is as productive as it could be, but I think this message
was just way off base.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
he standard library?
Regards,
--
Rowan Tommins
[IMSoP]
hub.com/mikeschinkel/faaee3fc8ccc2371c7200f3d634289c4
>
Here's the single-declaration version of that with a syntax error on line
163: https://3v4l.org/mGq2f
I think you're solving a non-existent problem here.
Regards,
--
Rowan Tommins
[IMSoP]
on changed
slightly from "(public $foo, public $bar)" to "{public $foo; public $bar;}"
I'm not sure how this changes anything, or how it relates to named
parameters. Could you expand on the problems you see this solving?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
domized parameter orders.
I you typed that into a special accessibility aid, and it was
automatically translated into the correct order by predictable rules
before I saw it, I a) wouldn't even know; and b) would be happy you were
able to use that aid to communicate with me.
Similarly, if yo
rmat could
write a polyfill, while people wanting other formats wouldn't need to mess
around with binhex, hexdec, etc.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t to named parameters proper. But the problems
I would like to solve with named parameters wouldn't be solved by
Swift/Smalltalk style functions.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
..., a: ...).
Re-ordering is, IMO, a key advantage of named parameters, so banning it
feels both arbitrary and counter-productive.
Regards,
--
Rowan Tommins
[IMSoP]
ompatibility contract, and until recently have always argued it should be
opt-in at the call-site. I've been somewhat won round to the idea that that
leaves the migration too painfully slow.
Regards,
--
Rowan Tommins
[IMSoP]
On Tue, 5 May 2020 at 08:52, Peter Bowyer wrote:
>
> On Tue, 5 May 2020 at 07:38, Niklas Keller wrote:
>
>> Rowan Tommins schrieb am Mo., 4. Mai 2020,
>> 10:59:
>> > Although the name sounds similar, I don't think UUID would be a good
>> > replacement fo
-in
functions to use inout rather than by-ref parameters; but then we
already have magic "prefer-ref" in internal functions, so maybe we could
come up with some kind of "prefer-inout".
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Deve
The only downside I can see suggesting something like random_string(13,
'0-9a-f') as a direct replacement for uniqid() is that without a time input
it might happen to generate the same string twice in a request. On the
other hand, uniqid actually disclaims any guarantee of uniqueness anyway.
Regards,
--
Rowan Tommins
[IMSoP]
ters; or perhaps
accept a range of characters to allow in some form.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
701 - 800 of 1043 matches
Mail list logo
