On Wed, 23 Jan 2019 at 09:02, Markus Fischer <mar...@fischer.name> wrote:
> Hi,
>
> On 22.01.19 21:34, Girgias wrote:
> > - phpversion (use PHP_VERSION constant)
>
> The function takes an optional argument `string $extension`, what is the
> replacement for that?
>
Didn 't realise not all of the extensions have a version constant.
> > - intval (for arbitrary base change there exists the math function
> > base_convert)
>
> I've seen and myself use the following construct a lot to "quickly"
> convert data within an array:
>
> $data = array_map('intval', $data);
>
> It's really practical because I don't have to write a (more verbose)
> closure.
>
> I'd argue this applies to the other `*val` calls too.
>
Seems like this is one of the only practical usages but a quite important
one
that I did not consider.
> - join (alias of implode)
> >
> > Old signatures:
> >
> > - implode (historical signature)
>
> Is there a correlation here why you mention the alias join and the
> actual function implode? I hope you would want to leave either in the
> language :-)
>
Completly unrelated, join is an alias whereas the old implode signature I'm
talking about is the implode(array $pieces, string $glue = '') which is not
recommended
compared to the recommended signature implode(string $glue, array $pieces)
which
mimics the explode signature.
I do want to keep implode() just deprecate the historical signature.
On Wed, 23 Jan 2019 at 09:19, Claude Pache <claude.pa...@gmail.com> wrote:
>
> > - settype
>
> AFAICS, there is no easy replacement for settype(). If the second argument
> is a string literal, you can use type coercion + assignment at the price of
> duplicating the occurrence of the first argument. If the second argument is
> not known at compile time, you have to resort to a switch statement or
> something similar.
>
I did not consider that someone might want to set the type of a variable at
runtime because
I can not see any pratical usages for that, imho you change a variable type
into another one
because you want to work with that specific type. But it basically boils
down to the same issue
as with gettype that without it you need to do a switch statement to get
something similar.
>
> > - deprecate array function creation (array())
>
> Here, I was really wondering why you didn’t mention function-like
> destructuring as well (list()). (Not that I think it is a good idea.)
>
Thanks for catching that oversight, been a while since I haven't used list()
And I can totally see why you wouldn't think it's a good idea I just feel a
major version change
is an approriate time to bring such controversial issues to the table.
On Wed, 23 Jan 2019 at 11:04, Jani Ollikainen <jani.ollikai...@valve.fi>
wrote:
> Hi,
>
> The arguments why to deprecate didn't seem much more than, this maybe
> could be deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?
>
My reasonning for theses deprecation is to get rid of some of the "clutter"
within the
PHP core, as in I don't see the benefit of having multiple aliases nor
functions which can
be achieved with some more modern constructs.
> But some comments that I didn't notice in others.
>
> > - php_uname (use PHP_OS constant)
>
> PHP_OS is php_uname('s'), how about rest:
>
> mode
>
> mode is a single character that defines what information is returned:
>
> 'a': This is the default. Contains all modes in the sequence "s n
> r v m".
> 's': Operating system name. eg. FreeBSD.
> 'n': Host name. eg. localhost.example.com.
>
gethostname() can retrive this information
> 'r': Release name. eg. 5.1.2-RELEASE.
>
PHP_EXTRA_VERSION
> 'v': Version information. Varies a lot between operating systems.
> 'm': Machine type. eg. i386.
>
For these two doesn't seem like I can find something equivalent
> Classes/Objects functions:
> > - is_a (use instanceof operator)
>
intanceof accepts a string as secodn operand but it needs to be within a
variable
however contrary to is_subclass_of, is_a does not accept a string as first
parameter
which makes is_a completly unnecessary imho.
See: https://3v4l.org/hn1Ao
> - is_subclass_of (not exactly what it's purpose is but the instanceof
> > operator SHOULD be a valid equivalence with another condition if the
> same
> > class must not be used)
>
I do acknoledge this one has a usage as per one of my previous replies.
> > Function handling functions:
> > - call_user_func (invoke directly)
>
> Yes, they give a little performance hit, but I still kind of like them.
> Like if we think the following, I think I would prefer call_user_func for
> syntax.
>
> class PREA {
> public function AB() {
> echo "HELLO".PHP_EOL;
> }
> public static function AC() {
> echo "HELLOSTATIC".PHP_EOL;
> }
> }
>
> $prefix='PRE';
> $class='A';
> $method='B';
> $static='C';
>
> $classVar=$prefix.$class;
>
> (new $classVar())->{$class.$method}();
> ($prefix.$class)::{$class.$static}();
>
> call_user_func(array(new $classVar(), $class.$method));
> call_user_func($prefix.$class.'::'.$class.$static);
>
Going from the fact that you are using call_user_func instead of
forward_static_call
to make a static call I feel this shows how call_user_func can be abused
comapred to
just doing a direct call.
But in the end this maybe boils down to personal preferences as I find
call_user_fun
horrendous as a construction
> And for the rest. Yes, there is another way of doing it, but is that
> really enough for deprecating something?
>
> > Setting var type (can use variable casting nowadays):
>
> Yes, we can cast, but is this reason for make someone to go through all
> the old code and do
> -$var = intval($var);
> +$var = (int) $var;
>
I feel with a whole major version to be able to adapt that seems like a
reseonable drawback to
have - imho - better code.
On Wed, 23 Jan 2019 at 11:15, Arvids Godjuks <arvids.godj...@gmail.com>
wrote:
> Hello to everyone.
>
> As a userland dev, I have to agree with Jani here - when I looked through
> the list of functions I had question marks all over the place about the
> `call_user_func*` family. Sure, closures are nice, but as demonstrated
> above they are not always the best-looking code and `call_user_func*`
> family has it's used. Maybe I'm just not using this functionality that
> much, so it seems like it's out of nowhere to deprecate/remove these for me.
>
I feel like not a lot of people are aware that you can replace
call_user_func with the splat operator,
and as said just before imho closures are nicer than call_user_fun*
I just want to finish and say that thanks for the constructive feedback and
different opinions that
you all provided.
Best regards
George P. Banyard
