Hi all!
I prepared my first contribution to internals:
https://github.com/php/php-src/pull/1932
I would like to discuss the proposed new function here. I directly went
on and implemented it for the learning experience. I also prepared the
RFC, but as a Gist because I do not have Karma yet:
https://gist.github.com/Fleshgrinder/6942daaae32372876e5219998e5e418c
There are a few open issues (see Gist) that require discussion and of
course a code review of the pull request.
--
Richard "Fleshgrinder" Fussenegger
Hi all!
I prepared my first contribution to internals:
Hello FG,
Having a standard way to get the type of a variable, that matches the
name of how it appears in PHP is a good idea.
The 'extended' parameter is not such a good idea, for various reasons
but mainly because it's simpler for people to call is_callable() as
well as typeof, rather than having to interpret the extended string to
tell if a string represents a callable.
The same is true for floats; it is easier for people to call
is_infinite or is_nan rather than searching inside a string for
'infinite' or 'invalid'.
cheers
Dan
Hello FG,
Having a standard way to get the type of a variable, that matches the
name of how it appears in PHP is a good idea.The 'extended' parameter is not such a good idea, for various reasons
but mainly because it's simpler for people to callis_callable()as
well as typeof, rather than having to interpret the extended string to
tell if a string represents a callable.The same is true for floats; it is easier for people to call
is_infinite or is_nan rather than searching inside a string for
'infinite' or 'invalid'.cheers
Dan
Hi Dan,
many thanks for your feedback. This is definitely NOT the purpose of the
extended mode, and I tried to emphasize this in the RFC. I also think it
would be very bad to introduce anything that would compete with any of
the existing is_* functions. It is also the reason why the strings are
very verbose and human readable: they are meant for debug and error
messages.
// complicated code ...
// error branch {{{
$type = typeof($v, true);
throw new Ex('Expected Foo but got ' . $type);
// }}}
// complicated code ...
This matches the main usage -- according to my research -- of the
existing gettype() function in userland software. :)
--
Richard "Fleshgrinder" Fussenegger
It would be beneficial to not reduce this to stringly-typed programmer
(again), as Dan mentioned.
Returning something like a ReflectionType instance (which then implements
__toString) would be much simpler, efficient and easy to use.
Marco Pivetta
Hello FG,
Having a standard way to get the type of a variable, that matches the
name of how it appears in PHP is a good idea.The 'extended' parameter is not such a good idea, for various reasons
but mainly because it's simpler for people to callis_callable()as
well as typeof, rather than having to interpret the extended string to
tell if a string represents a callable.The same is true for floats; it is easier for people to call
is_infinite or is_nan rather than searching inside a string for
'infinite' or 'invalid'.cheers
DanHi Dan,
many thanks for your feedback. This is definitely NOT the purpose of the
extended mode, and I tried to emphasize this in the RFC. I also think it
would be very bad to introduce anything that would compete with any of
the existing is_* functions. It is also the reason why the strings are
very verbose and human readable: they are meant for debug and error
messages.// complicated code ...
// error branch {{{$type = typeof($v, true); throw new Ex('Expected Foo but got ' . $type);// }}}
// complicated code ...This matches the main usage -- according to my research -- of the
existinggettype()function in userland software. :)--
Richard "Fleshgrinder" Fussenegger
It would be beneficial to not reduce this to stringly-typed programmer
(again), as Dan mentioned.Returning something like a ReflectionType instance (which then implements
__toString) would be much simpler, efficient and easy to use.Marco Pivetta
Hey Marco,
not sure if I like that approach for a procedural function. If we would
want that than it would be better to implement it as a named constructor
of the actual class.
class ReflectionType {
public static function from(mixed $var): ReflectionType;
}
But anyways, it would result in changing the purpose of that class:
The ReflectionType class reports information about a function's
return type.
I'd argue that we would need a completely new reflection class to handle
this use case, e.g. ReflectionVariable. However, I cannot see that this
is actually required while looking at the usage patterns of the existing
gettype() function. The goal here is to continue supporting the existing
mode of operation and its usage in userland while updating it to reflect
the current state of the type system. Additionally, pretty much nobody
uses it to determine the type of a variable but merely to include the
resulting string in debug/error messages.
The reflection class approach would mean that even more reflection code
ends up in production code, another thing I consider questionable.
--
Richard "Fleshgrinder" Fussenegger
Hey Richard,
It would be beneficial to not reduce this to stringly-typed programmer
(again), as Dan mentioned.Returning something like a ReflectionType instance (which then implements
__toString) would be much simpler, efficient and easy to use.Marco Pivetta
Hey Marco,
not sure if I like that approach for a procedural function. If we would
want that than it would be better to implement it as a named constructor
of the actual class.class ReflectionType {
public static function from(mixed $var): ReflectionType;}
But anyways, it would result in changing the purpose of that class:
Good point, probably not something you'd want to happen to pre-existing
code.
The ReflectionType class reports information about a function's
return type.I'd argue that we would need a completely new reflection class to handle
this use case, e.g. ReflectionVariable. However, I cannot see that this
is actually required while looking at the usage patterns of the existing
gettype()function. The goal here is to continue supporting the existing
mode of operation and its usage in userland while updating it to reflect
the current state of the type system. Additionally, pretty much nobody
uses it to determine the type of a variable but merely to include the
resulting string in debug/error messages.The reflection class approach would mean that even more reflection code
ends up in production code, another thing I consider questionable.
I may have misunderstood the feature at first. By thinking about other
languages with typeof support, I assumed this RFC was about a
machine-friendly representation of a variable.
I'd be "okay" with this if it was documented as "human friendly string
representation of a variable's content", or something similar. It should be
made 100% crystal clear that it is not for machine-consumption though.
Returning a string will cause developers to rely on it for other things
(besides meaningful exception messages), and that should be discouraged
behavior.
I also back Sara's concern, which is that a function like this one can be
implemented, tested, improved and upgraded in userland, without the need
for it to exist in core.
I'd rather do a composer require some-debug-utils-orga/type-of than
relying on another core function, which (and this will happen anyway), if
bugged, cannot get fixes without a complete php installation upgrade.
Marco Pivetta
Hi Richard,
I can't review the implementation, but the RFC looks good - great
initiative!
The only thing I would comment on, is the idea of packing essentially two
different functions into one - by default, the return value is a
machine-friendly type-name, but the $extended argument turns it into a
different function altogether, producing a human-readable type-description.
It seems like you have two functions in one, and I personally would prefer
having two functions.
Other than that, this looks like a nice replacement for e.g. this lengthy
switch-statement:
https://github.com/mindplay-dk/readable/blob/master/src/readable.php#L30
Incidentally, this library creates "more readable" representations of e.g.
closures, displaying filename and line number, which would be another
nice-to-have, and another good reason to separate the human-readable
function from the machine-friendly function. (I wrote this library mostly
to create readable representations of e.g. invalid arguments so I can throw
exceptions with more helpful messages - it would be great if that was no
longer necessary.)
Hi all!
I prepared my first contribution to internals:
https://github.com/php/php-src/pull/1932
I would like to discuss the proposed new function here. I directly went
on and implemented it for the learning experience. I also prepared the
RFC, but as a Gist because I do not have Karma yet:https://gist.github.com/Fleshgrinder/6942daaae32372876e5219998e5e418c
There are a few open issues (see Gist) that require discussion and of
course a code review of the pull request.--
Richard "Fleshgrinder" Fussenegger
Hi Richard,
I can't review the implementation, but the RFC looks good - great
initiative!The only thing I would comment on, is the idea of packing essentially two
different functions into one - by default, the return value is a
machine-friendly type-name, but the $extended argument turns it into a
different function altogether, producing a human-readable type-description.It seems like you have two functions in one, and I personally would prefer
having two functions.Other than that, this looks like a nice replacement for e.g. this lengthy
switch-statement:https://github.com/mindplay-dk/readable/blob/master/src/readable.php#L30
Incidentally, this library creates "more readable" representations of e.g.
closures, displaying filename and line number, which would be another
nice-to-have, and another good reason to separate the human-readable
function from the machine-friendly function. (I wrote this library mostly
to create readable representations of e.g. invalid arguments so I can throw
exceptions with more helpful messages - it would be great if that was no
longer necessary.)
Hi Rasmus,
thanks for the very positive feedback and this is exactly the target I
am aiming for with the proposal. I am more than open to the idea of
splitting the functionality because after all I am a big friend of the
Unix philosophy.
The hard question to answer is, how to call that function?
typeof_extended() is kind of weird ... I will definitely investigate. :)
--
Richard "Fleshgrinder" Fussenegger
I prepared my first contribution to internals:
Welcome!
I've put a couple minor notes on the implementation. Nothing
technically wrong, just style and micro-perf.
I would like to discuss the proposed new function here.
My number one issue with this PR is that it's all PHP code. There's
nothing in here that couldn't be done as a composer installable
library wrapping the existing gettype() and mapping around the
oddities you mention in the RFC. Wouldn't it be better to make
something that'll work across PHP versions, rather than something only
available in 7.1?
Beyond that, though on a similar vein, the extended format feels like
unparsable overkill for any use case but logging, and in the case of
logging you probably want the value as well which calls for something
more in the var_*() family. var_describe, perhaps?
By comparison, when it comes to code logic, there's nothing I do with
(typeof($foo, true) === 'bool true') that I can't do with
((gettype($foo) === 'boolean') && $foo). I'll grant that the former
is marginally more readable, but only in the most generous, liberal
sense.
If you'd like a new typeof() function, I think we should design it to
be much more robust like what Marco suggested. I don't care if that's
ReflectionType or ReflectionVariable or ReflectionBananaForScale.
Something that serves both programmatic needs by having ->isCallable()
->isNumeric() etc methods and serves human readability through a
__toString() method seems to make much more sense.
Lastly, with all the work going into gradual typing, I can see us
specifically wanting the name typeof at some later point. So at the
VERY least, I'd rename this to var_type() or similar.
-Sara
I prepared my first contribution to internals:
Welcome!
Hi Sara, nice to eventually becoming part of it. :)
I've put a couple minor notes on the implementation. Nothing
technically wrong, just style and micro-perf.
Many thanks for the code review and feedback!
I would like to discuss the proposed new function here.
My number one issue with this PR is that it's all PHP code. There's
nothing in here that couldn't be done as a composer installable
library wrapping the existinggettype()and mapping around the
oddities you mention in the RFC. Wouldn't it be better to make
something that'll work across PHP versions, rather than something only
available in 7.1?
Sure but the goal is to have a function in PHP that actually returns the
proper type name of a variable. I think it is wrong that one requires a
userland extension just to get the totally normal type name of something.
(The above only refers to the non-extended mode.)
Beyond that, though on a similar vein, the extended format feels like
unparsable overkill for any use case but logging, and in the case of
logging you probably want the value as well which calls for something
more in the var_*() family. var_describe, perhaps?
I was thinking about type_info() right now but var_info() would also be
nice I guess.
By comparison, when it comes to code logic, there's nothing I do with
(typeof($foo, true) === 'bool true') that I can't do with
((gettype($foo) === 'boolean') && $foo). I'll grant that the former
is marginally more readable, but only in the most generous, liberal
sense.
Arg, none of the above examples is a goal of mine for this function.
(is_bool($foo) && $foo) is the idiomatic way to perform such things.
If you'd like a new typeof() function, I think we should design it to
be much more robust like what Marco suggested. I don't care if that's
ReflectionType or ReflectionVariable or ReflectionBananaForScale.
Something that serves both programmatic needs by having ->isCallable()
->isNumeric() etc methods and serves human readability through a
__toString() method seems to make much more sense.
As I answered to Marco, I can put that in the future scope section since
I see the usefulness of it. But I would prefer to not extend the RFC
with it. (However, I am more than open to the idea of removing the
extended mode.)
Lastly, with all the work going into gradual typing, I can see us
specifically wanting the nametypeofat some later point. So at the
VERY least, I'd rename this to var_type() or similar.
I addressed this in the RFC. I do not think that typeof would be a
good operator in PHP because we already have instanceof and most
discussions in the last months where going into the direction of
extended the functionality of that instead of introducing another one. I
also propose in the open issues section to use is as an operator
instead of both typeof and instanceof because it does not have any
relation to the kind of a variable. It is short and complements other
operators like and plus or nicely. It also reads extremely nice:
if ($var is bool);
if ($var is Fleshgrinder\Examples\Example);
That being said, I actually like the var_type() name. We already have
many var_* functions but no type_* functions so far. I'd happily change
it to that if others think that it is a good name. I went for typeof()
because of the broad language support (illustrated in the RFC) and the
close type relation but the relation to variables is equally close in my
opinion.
--
Richard "Fleshgrinder" Fussenegger
My number one issue with this PR is that it's all PHP code. There's nothing
in here that couldn't be done as a composer installable library
It's a valid point, but not really a good argument against having it - the
same could after all be said about a lot of PHP functions.
The problem is that gettype() has numerous inconsistencies with the
language - since we can't fix gettype() without causing serious BC breaks,
I think that we do need this up-to-date function. (in fact, I would
encourage you to think about deprecating gettype, but that's probably a
discussion for another day.)
Also, this should be easy to polyfill for PHP < 7.1, correct?
It's harder to argue the same for the human-readable function, but I do
think it would be pretty great if we had this - people wouldn't think twice
about using it to generate more helpful and friendly exception messages,
and that's a good thing for the language overall. As for a third-party
dependency (such as my library) people will always think twice before
installing that just to produce better exception messages - I wrote the
thing, and even I think twice before I add that as a dependency.
I prepared my first contribution to internals:
Welcome!
I've put a couple minor notes on the implementation. Nothing
technically wrong, just style and micro-perf.I would like to discuss the proposed new function here.
My number one issue with this PR is that it's all PHP code. There's
nothing in here that couldn't be done as a composer installable
library wrapping the existinggettype()and mapping around the
oddities you mention in the RFC. Wouldn't it be better to make
something that'll work across PHP versions, rather than something only
available in 7.1?Beyond that, though on a similar vein, the extended format feels like
unparsable overkill for any use case but logging, and in the case of
logging you probably want the value as well which calls for something
more in the var_*() family. var_describe, perhaps?By comparison, when it comes to code logic, there's nothing I do with
(typeof($foo, true) === 'bool true') that I can't do with
((gettype($foo) === 'boolean') && $foo). I'll grant that the former
is marginally more readable, but only in the most generous, liberal
sense.If you'd like a new typeof() function, I think we should design it to
be much more robust like what Marco suggested. I don't care if that's
ReflectionType or ReflectionVariable or ReflectionBananaForScale.
Something that serves both programmatic needs by having ->isCallable()
->isNumeric() etc methods and serves human readability through a
__toString() method seems to make much more sense.Lastly, with all the work going into gradual typing, I can see us
specifically wanting the nametypeofat some later point. So at the
VERY least, I'd rename this to var_type() or similar.-Sara
Hi!
My number one issue with this PR is that it's all PHP code. There's nothing
in here that couldn't be done as a composer installable libraryIt's a valid point, but not really a good argument against having it - the
same could after all be said about a lot of PHP functions.
Many of those were introduced when we didn't have good ecosystem for
libraries, and whatever is baked into PHP binary is all you got to work
with. Not the case anymore. Many others were introduced because it was
hard to do it in PHP (no access to some internals, or slow, or required
things that code break between versions). Not the case here either.
Also, there's a difference between core having 20 functions and adding
21st that is doing something new, and core having 200 functions and
adding 201st that does exactly like one of the existing ones but
slightly different (slightly enough so you'd have to consult the manual
now to see why you used each of them in each context).
--
Stas Malyshev
smalyshev@gmail.com
I don't think we need a core function that almost exactly duplicates the working
of existing function but with a slight tweak. I do not think it is a good
idea to do such things, it only produces more confusion.
I strongly disagree.
The old function is actively causing confusion - the reported type-names
aren't even inconsistent with scalar type-hints, and then you have to go
and read the manual with some explanation about historical reasons why the
function doesn't work like you'd expect.
PHP is infamous for these surprise moments.
I think that gettype() should be deprecated in favor of a new function that
actually makes sense.
I think that deprecating and fixing things is long-term less confusing than
documenting your way around legacy functions that produce surprising and
confusing results.
IMO this is a clear improvement which removes a source of confusion.
On Sat, Jun 4, 2016 at 10:38 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
My number one issue with this PR is that it's all PHP code. There's
nothing
in here that couldn't be done as a composer installable libraryIt's a valid point, but not really a good argument against having it -
the
same could after all be said about a lot of PHP functions.Many of those were introduced when we didn't have good ecosystem for
libraries, and whatever is baked into PHP binary is all you got to work
with. Not the case anymore. Many others were introduced because it was
hard to do it in PHP (no access to some internals, or slow, or required
things that code break between versions). Not the case here either.Also, there's a difference between core having 20 functions and adding
21st that is doing something new, and core having 200 functions and
adding 201st that does exactly like one of the existing ones but
slightly different (slightly enough so you'd have to consult the manual
now to see why you used each of them in each context).--
Stas Malyshev
smalyshev@gmail.com
Hi!
The old function is actively causing confusion - the reported type-names
aren't even inconsistent with scalar type-hints, and then you have to go
and read the manual with some explanation about historical reasons why
the function doesn't work like you'd expect.
Why it should match scalar types? You can't use output of this function
in a scalar type in any way.
PHP is infamous for these surprise moments.
So let's add more of it by having multiple functions that do exactly the
same thing but name null and float differently.
I think that
gettype()should be deprecated in favor of a new function
that actually makes sense.
If you think people would want to edit gigabytes of existing code
because you want NULL to be lowercase, you are very seriously mistaken
about the order of priority of an average PHP developer. I am sure
99.9999% of people care about all this pedantry infinitely less than
they care about their code keeping working and their development not be
impeded by things like having to read the manual each time to choose
which two of almost identical functions they need now and which of them
has null in which case.
I think that deprecating and fixing things is long-term less confusing
than documenting your way around legacy functions that produce
surprising and confusing results.
I think constantly disrupting the language environment by pedantic
tweaks that add BC and cognitive load but do not actually enable
anything new, just move things around - is not only confusing, but
harmful for the whole ecosystem.
And if "NULL" really confuses you to the point you have no idea what it
means - well, really, I don't know what to say.
--
Stas Malyshev
smalyshev@gmail.com
Why it should match scalar types? You can't use output of this function
in a scalar type in any way.
To avoid those WTF moments and make it easier for newcomers.
So let's add more of it by having multiple functions that do exactly the
same thing but name null and float differently.
The RFC contains the deprecation and removal of gettype as a non
optional vote. You are completely right that introducing new stuff and
more new stuff is the wrong way to go. We need to clean up too.
If you think people would want to edit gigabytes of existing code
because you wantNULLto be lowercase, you are very seriously mistaken
about the order of priority of an average PHP developer. I am sure
99.9999% of people care about all this pedantry infinitely less than
they care about their code keeping working and their development not be
impeded by things like having to read the manual each time to choose
which two of almost identical functions they need now and which of them
has null in which case.
I doubt that anybody relies on gettype to determine such things. They
use is_null($x) and $x == null or $x === null. Anyone who relies on a
function that had for years a warning in the manual that one should not
rely on the returned string value or debugging/error output to stay
consistent is doing something EXTREMELY wrong.
I think constantly disrupting the language environment by pedantic
tweaks that add BC and cognitive load but do not actually enable
anything new, just move things around - is not only confusing, but
harmful for the whole ecosystem.
This is the very nature of refactoring. Make things better without
changing its functionality. However, in this case we even have a change
of functionality.
And if "NULL" really confuses you to the point you have no idea what it
means - well, really, I don't know what to say.
Thanks for reducing my first contribution to this single tiny change
that is part of it. I am sure it will attract more people to contribute
to php-internals. :P (No worries, you don't scare me away, harharhar.)
--
Richard "Fleshgrinder" Fussenegger
So let's add more of it by having multiple functions that do exactly the same
thing but name null and float differently.
It's a point of view, that's all.
You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers would
actually expect.
You know what, all this rhetoric in favor of inconsistency, against a
solution that has already been implemented?
I don't know how to participate in this.
On Sun, Jun 5, 2016 at 12:36 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
The old function is actively causing confusion - the reported type-names
aren't even inconsistent with scalar type-hints, and then you have to go
and read the manual with some explanation about historical reasons why
the function doesn't work like you'd expect.Why it should match scalar types? You can't use output of this function
in a scalar type in any way.PHP is infamous for these surprise moments.
So let's add more of it by having multiple functions that do exactly the
same thing but name null and float differently.I think that
gettype()should be deprecated in favor of a new function
that actually makes sense.If you think people would want to edit gigabytes of existing code
because you wantNULLto be lowercase, you are very seriously mistaken
about the order of priority of an average PHP developer. I am sure
99.9999% of people care about all this pedantry infinitely less than
they care about their code keeping working and their development not be
impeded by things like having to read the manual each time to choose
which two of almost identical functions they need now and which of them
has null in which case.I think that deprecating and fixing things is long-term less confusing
than documenting your way around legacy functions that produce
surprising and confusing results.I think constantly disrupting the language environment by pedantic
tweaks that add BC and cognitive load but do not actually enable
anything new, just move things around - is not only confusing, but
harmful for the whole ecosystem.And if "NULL" really confuses you to the point you have no idea what it
means - well, really, I don't know what to say.--
Stas Malyshev
smalyshev@gmail.com
-----Original Message-----
From: Rasmus Schultz [mailto:rasmus@mindplay.dk]
Sent: Sunday, June 05, 2016 2:51 PM
To: Stanislav Malyshev smalyshev@gmail.com
Cc: Sara Golemon pollita@php.net; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC DISCUSSION] typeofSo let's add more of it by having multiple functions that do exactly
the same
thing but name null and float differently.It's a point of view, that's all.
You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers would
actually expect.You know what, all this rhetoric in favor of inconsistency, against a solution
that has already been implemented?
We're weighing a certain level of inconsistency that exists with gettype(), with a different kind of inconsistency - having typeof() and gettype() both be members of the language, and behave subtly inconsistently with each other. So this is not consistency vs. non-consistency, we're choosing between two non-ideal options.
IMHO, we're better off sticking with the devil everyone knows; The inconsistency is there but it's not a very strong one with few practical issues. IMHO, we're better off having this compared to having two similar-but-different options. People for whom gettype() is inadequate can obtain typeof() (or whatever it will be called) using Composer. For people for whom this is a non-issue (vast majority I would believe), don't have to be confused by two similar-but-different options.
As a side note, the fact we happen to have an implementation for this should play no role in whether we accept a proposal like this or not; This holds true for most RFCs - unless the implementation manages to achieve some remarkably complex feat, and even then - it should stand at its own merit.
Zeev
We're weighing a certain level of inconsistency that exists with
gettype(), with a different kind of inconsistency - having typeof()
andgettype()both be members of the language, and behave subtly
inconsistently with each other. So this is not consistency vs.
non-consistency, we're choosing between two non-ideal options.IMHO, we're better off sticking with the devil everyone knows; The
inconsistency is there but it's not a very strong one with few
practical issues. IMHO, we're better off having this compared to
having two similar-but-different options. People for whomgettype()
is inadequate can obtain typeof() (or whatever it will be called)
using Composer. For people for whom this is a non-issue (vast
majority I would believe), don't have to be confused by two
similar-but-different options.
You are completely ignoring the fact that the deprecation and removal of
gettype() is actually part of my proposal. Anyone who continues to use
gettype() should be informed that this is not the idiomatic way of
performing this action and to use the new function instead.
It might be a /slight inconsistency/ but it is at the same time a very
shameful and sad one. Our language is not able to tell us the type of a
variable!
As a side note, the fact we happen to have an implementation for this
should play no role in whether we accept a proposal like this or not;
This holds true for most RFCs - unless the implementation manages to
achieve some remarkably complex feat, and even then - it should stand
at its own merit.
That is true, yes.
--
Richard "Fleshgrinder" Fussenegger
Hi!
You are completely ignoring the fact that the deprecation and removal of
gettype()is actually part of my proposal. Anyone who continues to use
gettype()should be informed that this is not the idiomatic way of
performing this action and to use the new function instead.
That makes it much worse, not better. Having two functions is bad.
Having to pass through heaps of old of code, change it, re-test it,
re-release it, re-deploy it, all because a basic engine function is
being removed - and not because it didn't work for you, but because
somebody didn't like NULL being in uppercase - is much, much worse than
just having the annoyance of two similar functions. Having two functions
would be bad, but tolerable - adding this huge disruption for no reason
but slightly changing the output is completely unacceptable.
It might be a /slight inconsistency/ but it is at the same time a very
shameful and sad one. Our language is not able to tell us the type of a
variable!
I don't know which language you are talking about, but it's certainly
not PHP.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers
would actually expect.
It's not just a point of view. If it is implemented, it will have
consequences for millions of people using PHP. Adding them extra work
and having them to deal with all the consequences that follow from that
decision. With this ecosystem, each change has a cost. It's not just "I
think this way, it's my opinion". That is true for a personal project.
PHP is not a personal project, so proposing change to it is not a matter
of personal opinion - it is much broader. That is why I am and will
continue to argue against changes that have minimal benefit - like this
one - because they are not worth the cost of change imposed on the
ecosystem. There's no such thing as free change, so it should be worth it.
You know what, all this rhetoric in favor of inconsistency, against a
It's not in favor of inconsistency. It is in favor of not creating a
mess of having two basic functions doing almost, but not quite the same.
The cost of having imperfect, but widely used function is much less than
the cost of switching to another function, learning to distinguish them
in the code, having transition period with two functions and then trying
to eliminate old function from all code that had absolutely no problem
with it. And the benefit is mostly vague "consistency". I mean,
consistency is important design consideration. But in no way "it makes
me sad to see people complain on Reddit about PHP being inconsistent"
is worth more than "people having to change tons of code everywhere to
accommodate change made so that people won't complain on Reddit".
solution that has already been implemented?
That fact that is has been implemented does not mean it should be part
of PHP core. You can implement a lot of things, being implementable is a
necessary condition, but in no way sufficient. Yes, you take the risk by
implementing feature that is not accepted. But it's not an argument for
acceptance.
Stas Malyshev
smalyshev@gmail.com
Hi!
You can choose your point of view - I choose the point of view where we
replace a broken function with a function that does what developers
would actually expect.
Show me developer that expects core engine functions to go away and be
replaced with functions with almost the same, but slightly different
output - and I show you a developer that has way too much free time on
their hands. Most developers don't have time for such things. Yes, if we
designed this function from scratch, knowing all we know now, we'd take
different decisions. But we don't have this luxury, we are where we are
now, and it's not from scratch.
Stas Malyshev
smalyshev@gmail.com
Hi!
I prepared my first contribution to internals:
I don't think we need a core function that almost exactly duplicates the
working of existing function but with a slight tweak. I do not think it
is a good idea to do such things, it only produces more confusion. I
mean yes, NULL may be annoying (not to me but I understand how it can
be) but introducing new core function to change "NULL" to "null" and
similar small tweaks and encourage people (99.99999% of which do not
care) to rewrite their code does not seem beneficial to me.
The extended mode seems to be a kind of pretty-printing debugging output
which probably matches some use case but definitely not all of them. I
don't see how these cases are common enough to be part of core. This
would be completely fine as a PHP library but I don't see why it needs
to be a core function.
--
Stas Malyshev
smalyshev@gmail.com
Quick sketch of a ReflectionVariable class:
https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e
What do you think?
PS: This would definitely be a different RFC!
--
Richard "Fleshgrinder" Fussenegger
Quick sketch of a ReflectionVariable class:
https://gist.github.com/Fleshgrinder/40d256a4bf44a0e2579b41d6e92e976e
What do you think?
PS: This would definitely be a different RFC!
The one thing that sticks out from this is 'why do I need all this?'
This may be because I don't understand just what happens under the hood
when you create a $var and in my naive way I have ALWAYS assumed that a
variable was a set of data elements with a pointer which 'a single
compiled and optimized set of code' operated each of to provide either
the raw value, or transformed version of that data essentially in a
different type. but if the value was provided as a string, that string
was maintained.
I've never viewed a $var as a single data element, so 'typing' it as int
does not mean that it only exists as a fixed length register - probably
64bit - with no other versions stored. If it was provided as a hex
string then I would anticipate that both the hex string type will exist
in parallel with the binary value. At least a $var has a name field,
flags for access restrictions, and yes null fields where they have not
be defined.
I would expect ALL of the extras listed in 'ReflectionVariable' simply
to be core code handling any $var value be that as an element of an
enclosing array, a property in a class, or a parameter in a function
call. This is why I don't understand the 'strict' mode at all. Or rather
I do in relation to a compiled language that does not have the
flexibility to pass data from one domain to another and where the typing
is directed to specific hardware restrictions which then make optimizing
code appropriate, but PHP specifically avoids that problem. It was the
major plus when I started using it! I understand that type checking has
a place, but NOT as it is currently structured, which is why I think all
the current round robins on typing/null/strict are simply going to carry
on in that manor.
When I create 100 person objects how many copies of the class and
related code are created? Is each property then it's own full copy of
the var code, which is why you want to 'optimise' for each different
type, rather than improving the caching of the objects data to only run
a type conversion when it is needed.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk