bastian.schneider@commerce-plus.com> wrote:
> Just a quick thought.
>
>
> union Iterable {
> use array;
> use ArrayAccess;
> use Traversable;
> }
>
I think this example creates another meaning on the "use" syntax, which
make "use" context depended.
The "use" statement is already used to "create an class name alias in the
current namespace." and this makes "use" confusing.
Thanks, Yo-An Lin
> On Sun, Apr 17, 2016 at 6:06 AM, Bastian Schneider <
> bastian.schneider@commerce-plus.com> wrote:
>
>> Just a quick thought.
>>
>>
>> union Iterable {
>> use array;
>> use ArrayAccess;
>> use Traversable;
>> }
>>
>
> I think this example creates another meaning on the "use" syntax, which
> make "use" context depended.
>
> The "use" statement is already used to "create an class name alias in the
> current namespace." and this makes "use" confusing.
>
Especially since its not needed at all. HHVM already solved most of
these issues extremely nicely:
- https://docs.hhvm.com/hack/types/type-system
- https://docs.hhvm.com/hack/type-aliases/introduction
- https://docs.hhvm.com/hack/shapes/introduction
We want the same but do not want to copy?!?
--
Richard "Fleshgrinder" Fussenegger
Especially since its not needed at all. HHVM already solved most of
these issues extremely nicely:
- https://docs.hhvm.com/hack/types/type-system
- https://docs.hhvm.com/hack/type-aliases/introduction
- https://docs.hhvm.com/hack/shapes/introduction
We want the same but do not want to copy?!?
The simple answer NO
If that is how you think it should be done, then use it. On my platform,
'point' is a number of floating point numbers depending on your
geometry. And shapes use those points. So that area of 'hack' is of
little use to any mapping system, and trying to shoehorn existing code
to fit is 'pointless' ...
It's the fact that many of these problems HAVE been solved without
resorting to overloading PHP with a subset that does not provide a
complete solution to the alleged problems that is the reall problem
here. Having to re-write libraries because some one else thinks the
basic rules are wrong and need fixing :(
--
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
Especially since its not needed at all. HHVM already solved most of
these issues extremely nicely:
- https://docs.hhvm.com/hack/types/type-system
- https://docs.hhvm.com/hack/type-aliases/introduction
- https://docs.hhvm.com/hack/shapes/introduction
We want the same but do not want to copy?!?
The simple answer NO
If that is how you think it should be done, then use it. On my platform,
'point' is a number of floating point numbers depending on your
geometry. And shapes use those points. So that area of 'hack' is of
little use to any mapping system, and trying to shoehorn existing code
to fit is 'pointless' ...It's the fact that many of these problems HAVE been solved without
resorting to overloading PHP with a subset that does not provide a
complete solution to the alleged problems that is the reall problem
here. Having to re-write libraries because some one else thinks the
basic rules are wrong and need fixing :(
Why do you need to rewrite anything?
Why do you need to use it?
Especially, why do you thing that PHP was made solely for auto-mappers
from some SQL to PHP?
$array_point = array('x' => 0.0, 'y' => 0.0); // valid
type Point = shape('x' => float, 'y' => float);
$point = shape('x' => 0.0, 'y' => 0.0); // valid
function distance(array|Point $p1, array|Point $p2) {
// works
}
function distance(Point $p1, Point $p2) {
// works better
}
var_dump($point);
// array(2) {
// ["x"]=>
// float(0.0)
// ["y"]=>
// float(0.0)
// }
Both works and both is valid. Only the latter case ensures that it is as
defined and the former allows arbitrary changes. If you need arbitrary
changes go for it. It does not matter why you want to use the former
(anemic domain, legacy support, no time to adopt, no muse to adopt,
"everything was better in the old days", ...) as long as it solves your
use case and satisfies your users. All changes that were proposed are
without any BC!
If you are only afraid that usage of your libraries declines because
users demand these new features to be part of it and you do not want to
implement them. Sorry, but that would be a clear sign that the features
are good and should be used.
--
Richard "Fleshgrinder" Fussenegger
If you are only afraid that usage of your libraries declines because
users demand these new features to be part of it and you do not want to
implement them. Sorry, but that would be a clear sign that the features
are good and should be used.
I have two major libraries I have used since day one of PHP5 ... ADOdb
and Smarty ... both of these have provided the core of my framework, but
have needed a lot of work simply keeping my code in sync with them, and
the latest 'improvements' to both are not BC for reasons that are blamed
on needing to 'modernise' the code. Now I DID keep my own copies of both
for many years to keep the PHp5.2 code working, and perhaps I should
simply close the door on PHP7 and stay with what is currently working.
But PHP7 ... ignoring any of the new features ... does provide
improvements in some areas if you REMOVE the legacy stuff which prevents
the optimisations from giving their best. The 'improvements' to ADOdb
and Smarty are claimed to help this process but unfortunately the people
pushing those changes are 'new school' and expect all the new stuff as
well. So exactly where is PHP heading? Do we keep with the original
simple flexible language that even today still works fine, or do we
accept that everything that is being demanded should also be included
and just roll over.
I do not accept the statement that 'You do not have to use it'! That may
have been true in the past, but today one has to live with the fact that
legacy code and modern hosting simply do not co-exist. One HAS to take
care that the key third party bits still work, and it's libraries like
the mapping extensions which relied on many key elements that HAVE now
been removed from PHP.
--
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
If you are only afraid that usage of your libraries declines because
users demand these new features to be part of it and you do not want to
implement them. Sorry, but that would be a clear sign that the features
are good and should be used.I have two major libraries I have used since day one of PHP5 ... ADOdb
and Smarty ... both of these have provided the core of my framework, but
have needed a lot of work simply keeping my code in sync with them, and
the latest 'improvements' to both are not BC for reasons that are blamed
on needing to 'modernise' the code. Now I DID keep my own copies of both
for many years to keep the PHp5.2 code working, and perhaps I should
simply close the door on PHP7 and stay with what is currently working.
But PHP7 ... ignoring any of the new features ... does provide
improvements in some areas if you REMOVE the legacy stuff which prevents
the optimisations from giving their best. The 'improvements' to ADOdb
and Smarty are claimed to help this process but unfortunately the people
pushing those changes are 'new school' and expect all the new stuff as
well. So exactly where is PHP heading? Do we keep with the original
simple flexible language that even today still works fine, or do we
accept that everything that is being demanded should also be included
and just roll over.I do not accept the statement that 'You do not have to use it'! That may
have been true in the past, but today one has to live with the fact that
legacy code and modern hosting simply do not co-exist. One HAS to take
care that the key third party bits still work, and it's libraries like
the mapping extensions which relied on many key elements that HAVE now
been removed from PHP.
The situation you describe is a pain that I know myself and I agree.
There are too many libraries that try to solve things in the most
possible generic way and abuse OO to ridiculous excesses instead of just
solving a single, simple problem with a few functions (as our old but
gold Unix philosophy has taught us). The simple rule "If it ain't broke
don't fix it" is also violated too much.
The reasons for this are manifold and hard to grasp from time to time. I
guess most often the problem boils down to "my library is not cool if it
does not use the latest language features". Ignoring completely if those
language features are actually appropriate for the problem. E.g.
excessive usage of exceptions without a single assertion spread all over
a code base to validate developer input.
However, you should seek the discussion with the maintainers of these
libraries and have a serious talk about BC, stability, and appropriate
usage of language constructs to solve problems. Instead of trying to
block advancement and evolution within the language itself.
Most features that are currently discussed are aiming at enterprise
applications that require more built-in functionality to ensure
correctness, reduce the amount of tests (unit as well as runtime) to
detect bugs, and where many developers work together at the same code
base. Most features can increase agility and productiveness of such
teams and allow them to implement new features and A/B tests faster. Of
course many features require more knowledge about programming. This can
also be bad for such teams because big teams almost always suffer from a
huge knowledge gap. Despite that, it helps the more advance developers
to create richer APIs that are harder to abuse and in turn allow the
overall design to achieve previously mentioned goals.
This is the sole reason why new language like Rust and Ceylon were
invented in the last years. Of course there are also projects that aim
at the novice user, e.g. Golang[1]. PHP currently achieves both in the
context of web projects and support for enterprise was grew and grew and
big companies like Facebook or my employee trivago who decided to go for
PHP do not want to invest a shitload of money into rewriting everything
from scratch in another language[2] like Twitter did (and exchange all
their developers who were already extremely hard to find in the first
place with new ones) just to get enterprise features. No, they want to
see advances in PHP to support exactly those features.
Facebook did not see those advancements and sent out their OCaml/C++
team to create something that has exactly those enterprise features
while we at trivago plan to upgrade to PHP 7, while I am writing these
lines, to get more performance out of the language and strict type checks.
There are always pros and cons and it is hard to satisfy everyone but
the type system of PHP is definitely one of its main weak spots and it
must be improved to support enterprise requirements better.
[1]
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
[2] This applies to switching from PHP to HHVM/Hack as well.
--
Richard "Fleshgrinder" Fussenegger
Most features that are currently discussed are aiming at enterprise
applications that require more built-in functionality to ensure
correctness, reduce the amount of tests (unit as well as runtime) to
detect bugs, and where many developers work together at the same code
base. Most features can increase agility and productiveness of such
teams and allow them to implement new features and A/B tests faster. Of
course many features require more knowledge about programming. This can
also be bad for such teams because big teams almost always suffer from a
huge knowledge gap. Despite that, it helps the more advance developers
to create richer APIs that are harder to abuse and in turn allow the
overall design to achieve previously mentioned goals.
And this is where the likes of Hack should be exactly where you are
working ... The vast majority of grass roots users don't need another
layer of complexity loaded on top of what IS a perfectly functional
platform. Adding types, complicating procedure calls and lumbering
everything with 'optional' layers of complexity is not something that a
small jobbing shop user has time to investigate the implications on his
client base. I'm still working through code that other have written and
trying to in many cases unravel exotic code that no longer fits the
modern programming style. I no longer take on any new clients as there
is enough work keeping my existing client base working, but there are a
LOT of people still using PHP5.2/3 who now need help if they are ever to
be brought forward.
Now if you were proposing something that actually validated the data
fully rather than some very restricted 'type' elements then it might be
worth the effort, but 'int' is only a very small part of validating a
number and we still need the rest of the validation library after you
install a replacement for that bit mf it ...
--
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
And this is where the likes of Hack should be exactly where you are
working ... The vast majority of grass roots users don't need another
layer of complexity loaded on top of what IS a perfectly functional
platform. Adding types, complicating procedure calls and lumbering
everything with 'optional' layers of complexity is not something that a
small jobbing shop user has time to investigate the implications on his
client base. I'm still working through code that other have written and
trying to in many cases unravel exotic code that no longer fits the
modern programming style. I no longer take on any new clients as there
is enough work keeping my existing client base working, but there are a
LOT of people still using PHP5.2/3 who now need help if they are ever to
be brought forward.Now if you were proposing something that actually validated the data
fully rather than some very restricted 'type' elements then it might be
worth the effort, but 'int' is only a very small part of validating a
number and we still need the rest of the validation library after you
install a replacement for that bit mf it ...
Union and intersection types already get us closer to stricter data
types that are flexible too. Of course they are not the best solution. I
already mentioned in another mail that operator overloading is the only
way to get us there. It is the only thing that allows us to create truly
meaningful types.
However, the problem of primitives remains, as was illustrated in this
and related threads multiple types, e.g. array|Traversable.
--
Richard "Fleshgrinder" Fussenegger
Hi!
Just a quick thought.
union Iterable {
use array;
use ArrayAccess;
use Traversable;
}I think this example creates another meaning on the "use" syntax, which
make "use" context depended.The "use" statement is already used to "create an class name alias in the
current namespace." and this makes "use" confusing.
I don't think this additional usage of "use" makes it any more confusing.
Many keywords are reused elsewhere, including "use":
- namespace importing
- variable importing for closures
- trait importing
(Ditto with "as.")
Thanks,
Tom