RFC - Array Of for PHP 7

7 years ago by Sara Golemon — view source

unread

I would like to create a RFC for PHP 7, but the same RFC was created and
declined 3 years ago for PHP 5.4. PHP 7 support much better type hinging so
I think this RFC should be voted again.

What should I do? Should I create the RPF in common way?

Link to mentioned RFC:
https://wiki.php.net/rfc/arrayof

Approach the original author(s) directly. You'll find Joe is much
more active in PHP atm (he's also an RM for 7.1), though Phil is
decently responsive via Twitter.
If that fails, go ahead and create your own RFC which references
their original version.

Given that the previous version did fail, you should take extra care
to identify and address the reasons why it failed. The lack of scalar
type hinting was likely a component, but I doubt it was the overriding
reason for most.

-Sara

7 years ago by Dan Ackroyd — view source

unread

Hallo,

I think this RFC should be voted again.

Although 'array of' as well as full blown generics are popular ideas,
I'm pretty certain the RFC failed due to the type check on the array
happening every time the 'array of' was passed from one function to
another, which would make it too slow to actually use.

An 'array of' RFC almost certainly needs a different programming
approach to have a change of succeeding.

What should I do?

If you can, either learn a lot of C, or hire a world class C
programmer who is familiar with PHP internals for several months, to
make a new implementation.

Joe might have some thoughts on alternative approaches.

cheers
Dan

7 years ago by Rowan Collins — view source

unread

Although 'array of' as well as full blown generics are popular ideas,
I'm pretty certain the RFC failed due to the type check on the array
happening every time the 'array of' was passed from one function to
another, which would make it too slow to actually use.

The fundamental problem with extending PHP's type declarations - either to more complex types, or to other code elements such as properties - is that they are currently always checked at run-time, not with a separate static analyser. It's notable that in Go, the runtime type checks are considered a "development only" option, and strongly discouraged in production code due to performance impact.

I wrote about this a few months back here: http://rwec.co.uk/q/php-type-system

One possibility if we do want to keep the current run-time approach is to cache type information against values (zvals) so subsequent checks become quicker. The problem is working out exactly what to store and when to invalidate it - if you append 42 to an array that passed int[] on the last check, the ideal would be for us to know the type is still valid.

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Levi Morrison — view source

unread

My thoughts on the RFC:

The syntax typename[] is a poor. Consider how nullability might
bind ?int[]. Is that (?int)[] or ?(int[]) ? Here are some
variants that do not have this issue:
[?int] and ?[int]
array<?int> and ?array<int>
Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

7 years ago by Andrea Faulds — view source

unread

Hi Levi,

Levi Morrison wrote:

My thoughts on the RFC:

The syntax typename[] is a poor. Consider how nullability might
bind ?int[]. Is that (?int)[] or ?(int[]) ? Here are some
variants that do not have this issue:
[?int] and ?[int]
array<?int> and ?array<int>

Thank you for bringing this up. The introduction of nullables means that
the type[] syntax is problematic and should probably be avoided now. As
you say, there is an issue of ambiguity as to whether it would be
interpreted as (?int)[] or ?(int[]). Unfortunately, both of these are
reasonable interpretations and might be desired. So if we use that
syntax, we'd have to add brackets. It would be simpler and prevent any
misunderstandings if we use a syntax that is unambiguous in the first place.

Personally I might like generics-esque angular brackets, but a problem
there is that << and >> are operators with their own tokens, so
supporting nested arrays (array<array<array>>) would require some sort
of lexer hack.

Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

Something I've thought about but not gotten round to implementing is a
typed array value. That is, you could write $x = array<int>(1, 2, 3);
and $x would contain a typed array that would enforce the types of
values added to it. This feels like a cleaner solution, but it
introduces a new issue: does an array<int> type declaration require an
array<int> value, or will it implicitly cast from vanilla array?

Thanks.

Andrea Faulds
https://ajf.me/

7 years ago by Mark Randall — view source

unread

Thank you for bringing this up. The introduction of nullables means that
the type[] syntax is problematic and should probably be avoided now. As
you say, there is an issue of ambiguity as to whether it would be
interpreted as (?int)[] or ?(int[]).

That would be a shame, TypeName[] is a defacto standard already for PHP
docs (not to mention a absolute standard for many programming languages)
and if it can be made to work it would be one less piece of syntax.

IMHO ?(int[]) would be the way to go staying with the current trend, or
alternatively bite the bullet and specific both like we do in docblocs:

function fn(null | int[] $x) { ... }

Generics gives the less ambiguous option:

function fn(?array<int> $x) { ... }

This would become a lot less of an issue if we had function overloading
in future crosses fingers.

Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

Which brings up perhaps a longer term point, does the language need an
inbuilt alternative to "array" that implements ArrayAccess and provides
for an "Operator array" that will allow it to be cast to an native array
just as __tostring does for objects that implement it.

The benefit would be that type checking could be performed on
initialization and assignment, and with "operator array" it would be
transparent.

The downside I see? Well, being a generic object it would not exhibit
traditional PHP copy-on-write behaviour, unless that was somehow baked
into the language as part of the class definition (in a similar manner
to "abstract" or "implements CopyOnWrite").

Something I've thought about but not gotten round to implementing is a
typed array value. That is, you could write $x = array<int>(1, 2, 3);
and $x would contain a typed array that would enforce the types of
values added to it. This feels like a cleaner solution, but it
introduces a new issue: does an array<int> type declaration require an
array<int> value, or will it implicitly cast from vanilla array?

Would an "operator array" not solve this in the same manner that
__tostring does?

I think once we have operator overloading (and supported by native
types) then we should be able to do the following:

function fn(MyCollection<int> $y) { ... }

generic class MyCollection<T1> {
public function __construct(array $in) {
foreach ($in as $x) {
if (!($x typeof T1)) {
throw new InvalidArgumentException('...');
}
}
}
}

fn(['hello', 'world']);

And the engine should be smart enough to create a new instance of
MyCollection<int> with the defined constructor. I say overloading would
be necessary as several different constructors may be required.

Equally:

generic class SomeArray<T1> {
...
public function __operator_array(): array {
return $this->privateInternalArray;
}
...
}

function fn(array $x) { ... }
fn(new SomeArray<int>(1, 2, 3));

Admittedly I do not know the PHP core with any degre of intimacy, but
from a language perspective I can't think of a better way than generics,
casting operators, and overloaded function constructors...

... and yes, that did include almost every major language wishlist item
in a single go. Chalk it up to me romancing my long lost love of C++.

Thanks.

--
Mark Randall

7 years ago by Andrea Faulds — view source

unread

Hi,

Mark Randall wrote:

Thank you for bringing this up. The introduction of nullables means
that the type[] syntax is problematic and should probably be avoided
now. As you say, there is an issue of ambiguity as to whether it would
be interpreted as (?int)[] or ?(int[]).

That would be a shame, TypeName[] is a defacto standard already for PHP
docs (not to mention a absolute standard for many programming languages)
and if it can be made to work it would be one less piece of syntax.

IMHO ?(int[]) would be the way to go staying with the current trend,

Yes, it is a bit unfortunate to deviate from the docs. But array<> is
also a familiar syntax, yet it's unambiguous and wouldn't require the
new complication of parentheses. For that reason I don't find [] a
compelling option. Syntax æsthetics are nice but in the end it's
readability that matters.

or

alternatively bite the bullet and specific both like we do in docblocs:

function fn(null | int[] $x) { ... }

Generics gives the less ambiguous option:

function fn(?array<int> $x) { ... }

This makes things even more complicated.

This would become a lot less of an issue if we had function overloading
in future crosses fingers.

Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

Which brings up perhaps a longer term point, does the language need an
inbuilt alternative to "array" that implements ArrayAccess and provides
for an "Operator array" that will allow it to be cast to an native array
just as __tostring does for objects that implement it.

The benefit would be that type checking could be performed on
initialization and assignment, and with "operator array" it would be
transparent.

The downside I see? Well, being a generic object it would not exhibit
traditional PHP copy-on-write behaviour, unless that was somehow baked
into the language as part of the class definition (in a similar manner
to "abstract" or "implements CopyOnWrite").

Why create an almost-array that works almost-everywhere when you can
improve the actual array that works actually everywhere?

Something I've thought about but not gotten round to implementing is a
typed array value. That is, you could write $x = array<int>(1, 2, 3); and $x would contain a typed array that would enforce the types
of values added to it. This feels like a cleaner solution, but it
introduces a new issue: does an array<int> type declaration require an
array<int> value, or will it implicitly cast from vanilla array?

Would an "operator array" not solve this in the same manner that
__tostring does?

Your proposed objects would not be usable everywhere an array is,
because they're not arrays, and by converting to an array you lose the
type info, so we still have to iterate over the whole thing to type
check. This would be significantly less useful than an actually typed
array. I can see some benefit to it, but I'm not sure it's worth the effort.

I think once we have operator overloading (and supported by native
types) then we should be able to do the following:

function fn(MyCollection<int> $y) { ... }

generic class MyCollection<T1> {
public function __construct(array $in) {
foreach ($in as $x) {
if (!($x typeof T1)) {
throw new InvalidArgumentException('...');
}
}
}
}

fn(['hello', 'world']);

And the engine should be smart enough to create a new instance of
MyCollection<int> with the defined constructor. I say overloading would
be necessary as several different constructors may be required.

Equally:

generic class SomeArray<T1> {
...
public function __operator_array(): array {
return $this->privateInternalArray;
}
...
}

function fn(array $x) { ... }
fn(new SomeArray<int>(1, 2, 3));

A problem here is that we'd need to implement generics! That's quite the
complex task. I do like the idea of generics, but I don't really expect
them to get implemented (let alone accepted) any time soon. Maybe if I
suddenly decide to take all my yearly paid holiday at once and am
unusually determined. But there are much nicer things to go on holiday for…

Admittedly I do not know the PHP core with any degre of intimacy, but
from a language perspective I can't think of a better way than generics,
casting operators, and overloaded function constructors...

... and yes, that did include almost every major language wishlist item
in a single go. Chalk it up to me romancing my long lost love of C++.

We all have our wishlist features. :)

I think I share some of yours.

Thanks for your reply.

Thanks.

--
Mark Randall

--
Andrea Faulds
https://ajf.me/

7 years ago by Mark Randall — view source

unread

Your proposed objects would not be usable everywhere an array is,
because they're not arrays, and by converting to an array you lose the
type info, so we still have to iterate over the whole thing to type
check. This would be significantly less useful than an actually typed
array. I can see some benefit to it, but I'm not sure it's worth the
effort.

Thanks for the reply.

So if I am following right, would your goal in the short-to-mid term at
least be to attach type information inside the HashTable, or as part of
the zval value?

I may be pulling this out our my arse of course, but does the nature of
an array not mean that the individual values inside can be used as
references and potentially break the type restrictions and require
all-item checking again?

$t1 = array<string>([ 'hello', 'goodbye']);
$val = &$t1[1];
$val = 1;
-> [ 'hello', 1]

I did take a look in zend_types.h half expecting to see a pointer to an
optional structure defining an indirect function call + argument to be
called whenever the zval_value was about to be changed, but if it's in
there, I missed it.

--
Mark Randall

7 years ago by Andrea Faulds — view source

unread

Hi Mark,

Mark Randall wrote:

Your proposed objects would not be usable everywhere an array is,
because they're not arrays, and by converting to an array you lose the
type info, so we still have to iterate over the whole thing to type
check. This would be significantly less useful than an actually typed
array. I can see some benefit to it, but I'm not sure it's worth the
effort.

Thanks for the reply.

So if I am following right, would your goal in the short-to-mid term at
least be to attach type information inside the HashTable, or as part of
the zval value?

Inside the HashTable, yes. There's no space to hide it in the zval, and
it's not the zval it's specific to anyway.

I may be pulling this out our my arse of course, but does the nature of
an array not mean that the individual values inside can be used as
references and potentially break the type restrictions and require
all-item checking again?

$t1 = array<string>([ 'hello', 'goodbye']);
$val = &$t1[1];
$val = 1;
-> [ 'hello', 1]

Yes. There's a similar problem for implementing typed property. I think
Bob Weinand might have been working on a solution to this (typed
references), but I have no idea where that went, if anywhere.

Thanks.

Andrea Faulds
https://ajf.me/

7 years ago by Rowan Collins — view source

unread

Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

Do you have a mechanism in mind for "optimising this away"? I think releasing the feature without any optimisation will just lead to painful slowdowns when people use it without realising the implications.

As I said in my previous message, it seems to be a fundamental issue with PHP's current type declarations that they are a) runtime, and b) asserted at arbitrary points, not at assignment. So even if you optimise the check slightly, it's still a separate check every time you enter a new function, which puts a limit on optimisation.

The only way I've thought of to improve things is to cache the result of previous type checks, but this comes with all the normal challenges of caching. For instance, all assignments into the array would need to invalidate these cached checks, or check the new value against each. References would be particularly tricky, as they were with the property type hint proposal.

If we selectively invalidated cached checks, we'd be running specific type checks at every variable assignment, but not letting the user actually assert on those checks. At which point, should we approach from the other direction, and let the user declare variable types, rather than assert value types?

This is kind of implied if we implement generics, too, since explicitly constructing an instance of list<int> is asking the runtime to check future assignments to members of that list. In effect, could declaring "int $foo = 42;" be considered equivalent to "$foo = new checkedScalar<int>(42);"?

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Michael Morris — view source

unread

Drupal 8 accomplishes this through assert() and a helper class.

function foo ( array $a ) {
assert( Inspector::assertAllStrings( $a ));
}

This could be improved by having an collectionof operator similar to the
instanceof operator.

function ( array $a ) {
assert( $a collectionof string );
}

I say "collectionof" because while arrays are the most common traversable
objects, they aren't the only ones. The above approach, combined with the
existing assert structure, can provide the dev time checking of the code
while in under development, and it can be turned off in production. Or it
can be used outside of assert to be checked at all times.

Since this invokes a new keyword I think that would mean this solution
would be PHP 8.

Brackets might be used with instance of to notify it to traverse down one
level maybe??

function ( array $a ) {
assert( $a instanceof [string] );
}

This avoids any BC issues, but it looks odd. Not as odd as \ for a
namespace operation :P But odd.

On Wed, Nov 1, 2017 at 10:40 AM, Rowan Collins rowan.collins@gmail.com
wrote:

On 31 October 2017 17:37:17 GMT+00:00, Levi Morrison levim@php.net
wrote:

Our current infrastructure requires us to check every element of
the array for conformance. While undesirable I believe this can be
optimized away in the future if we care enough, and therefore not a
show-stopper.

Do you have a mechanism in mind for "optimising this away"? I think
releasing the feature without any optimisation will just lead to painful
slowdowns when people use it without realising the implications.

As I said in my previous message, it seems to be a fundamental issue with
PHP's current type declarations that they are a) runtime, and b) asserted
at arbitrary points, not at assignment. So even if you optimise the check
slightly, it's still a separate check every time you enter a new function,
which puts a limit on optimisation.

The only way I've thought of to improve things is to cache the result of
previous type checks, but this comes with all the normal challenges of
caching. For instance, all assignments into the array would need to
invalidate these cached checks, or check the new value against each.
References would be particularly tricky, as they were with the property
type hint proposal.

If we selectively invalidated cached checks, we'd be running specific type
checks at every variable assignment, but not letting the user actually
assert on those checks. At which point, should we approach from the other
direction, and let the user declare variable types, rather than assert
value types?

This is kind of implied if we implement generics, too, since explicitly
constructing an instance of list<int> is asking the runtime to check future
assignments to members of that list. In effect, could declaring "int $foo =
42;" be considered equivalent to "$foo = new checkedScalar<int>(42);"?

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Larry Garfield — view source

unread

Drupal 8 accomplishes this through assert() and a helper class.

function foo ( array $a ) {
assert( Inspector::assertAllStrings( $a ));
}

This could be improved by having an collectionof operator similar to the
instanceof operator.

function ( array $a ) {
assert( $a collectionof string );
}

I say "collectionof" because while arrays are the most common traversable
objects, they aren't the only ones. The above approach, combined with the
existing assert structure, can provide the dev time checking of the code
while in under development, and it can be turned off in production. Or it
can be used outside of assert to be checked at all times.

Since this invokes a new keyword I think that would mean this solution
would be PHP 8.

Brackets might be used with instance of to notify it to traverse down one
level maybe??

function ( array $a ) {
assert( $a instanceof [string] );
}

This avoids any BC issues, but it looks odd. Not as odd as \ for a
namespace operation :P But odd.

While I normally strongly agree with supporting all traversables, not
just arrays, in this case I don't think it works. The whole point of
using a traversable is that you don't have all of the values up front.
If you did... you'd just have an array. So checking "all values" of a
traversable in one point in time is a destructive operation as it runs
out the iterator, which if it's an infinite iterator could, erm, be bad.

Rather, arrays can/should be checked at once (as above), whereas a
traversable should be able to declare that it only returns a given type,
and if it ever tries to return a different type then the traversable
itself type-errors.

--Larry Garfield

7 years ago by Michael Morris — view source

unread

On Thu, Nov 2, 2017 at 3:21 PM, Larry Garfield larry@garfieldtech.com
wrote:

While I normally strongly agree with supporting all traversables, not
just arrays, in this case I don't think it works.

Hmm.. You're right. Traversables would be best served by having another
method to indicate their return type as part of the interface. Adding this
to the existing traversable interface would be BC breaking. A new interface
would be best and having another interface isn't without precedent -
countable already exists.

This new interface would the PHP engine on what to do.

So, what about this syntax

$a instanceof string[]

If the engine sees this and it's an array, all the values are checked to
see if it's a string.

Else if $a references a generator, the return type definition of the
generator will be checked, and a failure will occur if the generator
doesn't declare its return type.

Else if $a references an object and that object implements the
SingleReturnType* interface then the method of that interface,
getReturnType() is queried and it's return is checked to see if it matches.
In the above case 'string' would need to be returned.

I leave it to people smarter than me to find the holes in the above, but
this moron thinks it might work.

Someone smarter than me can come up with a better name too :P

7 years ago by Tony Marston — view source

unread

""Michal Harezlak"" wrote in message
news:CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com...

Hallo,

I would like to create a RFC for PHP 7, but the same RFC was created and
declined 3 years ago for PHP 5.4. PHP 7 support much better type hinging so
I think this RFC should be voted again.

What should I do? Should I create the RPF in common way?

Link to mentioned RFC:
https://wiki.php.net/rfc/arrayof

This strikes me as being nothing more than a micro-optimisation that does
nothing but pander to the laziness of certain programmers. Instead of having
to write a few lines of code to validate something they want the language to
do it for them. It may come as a surprise to some people, but being a
programmer actually involves the writing of program code. It is not
sufficient to express an idea and have the language fill in all the details
as that forces the language to have to detect and deal with a myriad of
possibilities.

I would evaluate each proposed change to the language with a simple
question - does it provide the greatest good to the greatest number?
Considering the fact that this RFC will only benefit a miniscule minority of
developers yet make the language more complicated, slower to run, and more
difficult to maintain as more and more edge cases are identified as "bugs",
it offers negative benefits to the vast number of programmers who are happy
with the language as it currently exists. As such it fails that test and
should be rejected.

--
Tony Marston

7 years ago by Thomas Hruska — view source

unread

""Michal Harezlak"" wrote in message
news:CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com...

Hallo,

I would like to create a RFC for PHP 7, but the same RFC was created and
declined 3 years ago for PHP 5.4. PHP 7 support much better type
hinging so
I think this RFC should be voted again.

What should I do? Should I create the RPF in common way?

Link to mentioned RFC:
https://wiki.php.net/rfc/arrayof

This strikes me as being nothing more than a micro-optimisation that
does nothing but pander to the laziness of certain programmers. Instead
of having to write a few lines of code to validate something they want
the language to do it for them. It may come as a surprise to some
people, but being a programmer actually involves the writing of program
code. It is not sufficient to express an idea and have the language fill
in all the details as that forces the language to have to detect and
deal with a myriad of possibilities.

I would evaluate each proposed change to the language with a simple
question - does it provide the greatest good to the greatest number?
Considering the fact that this RFC will only benefit a miniscule
minority of developers yet make the language more complicated, slower to
run, and more difficult to maintain as more and more edge cases are
identified as "bugs", it offers negative benefits to the vast number of
programmers who are happy with the language as it currently exists. As
such it fails that test and should be rejected.

I agree.

Features that result in significant improvements to algorithmic
complexity but can't be implemented in userland are the sort of features
that should be priority for core. That's another way to look at the
question that Tony put forth but in more concrete terms. Internals
already tends to adhere to that sort of policy anyway even if it isn't
formally written anywhere.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

7 years ago by Kalle Sommer Nielsen — view source

unread

Hi Tony

2017-10-31 11:35 GMT+01:00 Tony Marston TonyMarston@hotmail.com:

This strikes me as being nothing more than a micro-optimisation that does
nothing but pander to the laziness of certain programmers. Instead of having
to write a few lines of code to validate something they want the language to
do it for them. It may come as a surprise to some people, but being a
programmer actually involves the writing of program code. It is not
sufficient to express an idea and have the language fill in all the details
as that forces the language to have to detect and deal with a myriad of
possibilities.

I do understand where you are coming from, but I don't necessarily
agree on this topic. We can (hopefully) agree that programming
language design is hard, because we need to determine how fine a line
we should have between things thats an integral part of the language,
its standard library or its extensions and how much power the
programmer has in their arsenal to do crazy things.

If we boil things down, then we didn't really need the scalar type
hints, PHP had been working perfectly fine for 20 years without it and
while it does not add anything but a couple of checks at
compile/runtime, its essentially "laziness of certain programmers" it
becomes useful to. Another example is constant visibility modifiers in
PHP 7.1.

I think one of the advocates for features that are within that
category you mention can sometimes be productivity and rid of
boilerplate code. For this case with 'Array Of', I think it makes
perfect sense to add with PHP7's improved type system on that regard,
but thats my personal opinion.

I would evaluate each proposed change to the language with a simple question

does it provide the greatest good to the greatest number? Considering the
fact that this RFC will only benefit a miniscule minority of developers yet
make the language more complicated, slower to run, and more difficult to
maintain as more and more edge cases are identified as "bugs", it offers
negative benefits to the vast number of programmers who are happy with the
language as it currently exists. As such it fails that test and should be
rejected.

Tho you said its a micro optimization, would argue that (see [1]), it
far from makes the code complicated, internally it doesn't add any
complexity and only adds a member to the arg_info, which is an
unsigned char, it wouldn't do anything unless a type is specified
anyway and the slower to run argument above is pretty void, sure it
adds a few CPU instructions but its not something you will feel unless
you are Facebook, in which case you already re-implemented the
language on your own.

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I
myself don't like PDO, so I just use mysqli instead, great. If its not
something that affects the programmer and the programmers code
continue to run, I fail to see how it negatively impacts the vast
majority. If I asked you how you feel about the exif extension now
supports streams as arguments instead of only file names, would you
care much unless you are actively using the exif extension? Probably
not.

[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e

--
regards,

Kalle Sommer Nielsen
kalle@php.net

7 years ago by Tony Marston — view source

unread

"Kalle Sommer Nielsen" wrote in message
news:CAJW__o3QJOe6G3ybmBcoCU=FCAdjZAcgbKTiJRBM3RS8Q0hBNQ@mail.gmail.com...

Hi Tony

2017-10-31 11:35 GMT+01:00 Tony Marston TonyMarston@hotmail.com:

This strikes me as being nothing more than a micro-optimisation that does
nothing but pander to the laziness of certain programmers. Instead of
having
to write a few lines of code to validate something they want the language
to
do it for them. It may come as a surprise to some people, but being a
programmer actually involves the writing of program code. It is not
sufficient to express an idea and have the language fill in all the
details
as that forces the language to have to detect and deal with a myriad of
possibilities.

I do understand where you are coming from, but I don't necessarily
agree on this topic. We can (hopefully) agree that programming
language design is hard,

I totally agree that compiler writing is hard, which is why I believe that
only those things which are hard to do in userland code should be added to
the language.

because we need to determine how fine a line
we should have between things thats an integral part of the language,
its standard library or its extensions and how much power the
programmer has in their arsenal to do crazy things.

For me the rule is simple - if something can already be done quite easily in
userland code then it should not be forced into the language just because a
small number of developers wnat to save themselves a few keystrokes. Making
the language more complicated than it need be leads to a maintenance burden
both for the core developers and the application developers who now have to
deal with a growing array of indeciferable shortcuts.

If we boil things down, then we didn't really need the scalar type
hints, PHP had been working perfectly fine for 20 years without it and
while it does not add anything but a couple of checks at
compile/runtime, its essentially "laziness of certain programmers" it
becomes useful to. Another example is constant visibility modifiers in
PHP 7.1.

I think one of the advocates for features that are within that
category you mention can sometimes be productivity and rid of
boilerplate code. For this case with 'Array Of', I think it makes
perfect sense to add with PHP7's improved type system on that regard,
but thats my personal opinion.

This type of checking can quite easily be done in userland code, so I see no
reason why it should be built into the language. What percentage of userland
developers would actually use such a feature? I wouldn't as I never pass
around arrays of single types. I regularly use the $_POST array and a
database record array which are both of mixed types.

I would evaluate each proposed change to the language with a simple
question

does it provide the greatest good to the greatest number? Considering
the
fact that this RFC will only benefit a miniscule minority of developers
yet
make the language more complicated, slower to run, and more difficult to
maintain as more and more edge cases are identified as "bugs", it offers
negative benefits to the vast number of programmers who are happy with
the
language as it currently exists. As such it fails that test and should be
rejected.

Tho you said its a micro optimization, would argue that (see [1]), it
far from makes the code complicated,

internally it doesn't add any complexity

I disagree. The language has to be changed to recognise that type of
argument, then it has to iterate through the array checking that every
member is of the designated type. In other words the langage now has to do
what you are doing with a few lines of userland code.

and only adds a member to the arg_info, which is an
unsigned char, it wouldn't do anything unless a type is specified
anyway and the slower to run argument above is pretty void, sure it
adds a few CPU instructions but its not something you will feel unless
you are Facebook, in which case you already re-implemented the
language on your own.

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but what
percentage of the user base would actually take advantage of this feature?
If it's only 1% then for the other 99% it's a complete waste of time.

myself don't like PDO, so I just use mysqli instead, great. If its not
something that affects the programmer and the programmers code
continue to run, I fail to see how it negatively impacts the vast
majority.

It has complications in the language that are not used. Have you ever heard
o the 80-20 rule? This is where 80% of the usage is simple and 20% is
complicated, but that complicated 20% takes up 80% of the programming
effort. I was around in the 1980s during the switch to RISC (Reduced
Instruction Set Computers) where it was found that by removing the
complicated instructions which could be executed in a single cycle and
replacing them with a series of simple instructions there were enormous
benefits all round - the chips became smaller, were cheaper to manufacture,
the cycles faster, the energy consumption smaller and with less heat
generated. It was a win-win all round.

By keeping out the frivolous froth from the language and restricting it to a
set of really useful features you end up with a smaller language which is
faster to run and easier to maintain. IMHO this RFC does not benefit the
greater PHP community, it just saves a few keystrokes for the lazy
developer.

If I asked you how you feel about the exif extension now
supports streams as arguments instead of only file names, would you
care much unless you are actively using the exif extension? Probably
not.

There is a great deal of difference between an extension which does
something complicated which cannot easily be done in userland code and
changing the core language just to save a few keystrokes. There are dozens
of extensions that I don't use, but I would never call for them to be
scrapped. Changing the core language is something else altogether. It's
there whether I want it or not, and it affects the execution of every
function or method call.

[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but
what percentage of the user base would actually take advantage of this
feature? If it's only 1% then for the other 99% it's a complete waste of
time

how does any feature you don't use affect you?

i don't care about pdo and many other core extensions nor about
namespaces, traits and so on - but they don't affect me at all

7 years ago by Tony Marston — view source

unread

wrote in message news:6643d10b-8703-693c-15c2-da338022ef41@rhsoft.net...

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but what
percentage of the user base would actually take advantage of this
feature? If it's only 1% then for the other 99% it's a complete waste of
time

how does any feature you don't use affect you?

Because the language itself becomes bloated with the capabilities it has to
offer, look for and deal with. This makes it bigger and slower. For example,
if you have a vehicle which is capable of going anywhere, over every types
of terrain, in every climate from sub zero to blisteringly hot then at any
one time you are not using all the capabilities, yet you are still carrying
the around.

The core language should be kept lean and mean, and should only have new
instructions added when (a) something cannot be done easily in userland
code, and (b) when that something is of genuine use to a significant number
of people. Complicating the language with something that can already be done
with a few lines of userland code and which is desired by only a miniscule
number of people does not fall into this category.

i don't care about pdo and many other core extensions nor about namespaces,
traits and so on - but they don't affect me at all

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022ef41@rhsoft.net...

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but
what percentage of the user base would actually take advantage of
this feature? If it's only 1% then for the other 99% it's a complete
waste of time

how does any feature you don't use affect you?

Because the language itself becomes bloated with the capabilities it has
to offer, look for and deal with. This makes it bigger and slower

unproven claim!

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all have
new features and where faster then the previous version - frankly you
are raising alarm for no reason

7 years ago by Tony Marston — view source

unread

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa722b@rhsoft.net...

Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022ef41@rhsoft.net...

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but
what percentage of the user base would actually take advantage of this
feature? If it's only 1% then for the other 99% it's a complete waste
of time

how does any feature you don't use affect you?

Because the language itself becomes bloated with the capabilities it has
to offer, look for and deal with. This makes it bigger and slower

unproven claim!

It's pure common sense! You have to carry around the capability of doing
something, then have tests everywhere to see if that capability is actually
required or not at run-time.

There is a big difference between adding something to the language core
which everyone has to load into memory, and having something in an extension
which is entirely optional.

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all have new
features and where faster then the previous version - frankly you are
raising alarm for no reason

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit
instead of 32bit, and improvements made to the engine itself, such as the
AST. I submit that it would be smaller and faster if it did not have to
carry around so much dross. Adding something to the core language just to
save a few keystrokes for a small number of lazy developers falls into the
category of dross.

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 04.11.2017 um 10:18 schrieb Tony Marston:

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa722b@rhsoft.net...

Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022ef41@rhsoft.net...

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently
exists", I

If it's put into the language then it affects 100% of the users,
but what percentage of the user base would actually take advantage
of this feature? If it's only 1% then for the other 99% it's a
complete waste of time

how does any feature you don't use affect you?

Because the language itself becomes bloated with the capabilities it
has to offer, look for and deal with. This makes it bigger and slower

unproven claim!

It's pure common sense! You have to carry around the capability of doing
something, then have tests everywhere to see if that capability is
actually required or not at run-time.

it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"

There is a big difference between adding something to the language core
which everyone has to load into memory, and having something in an
extension which is entirely optional.

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all have
new features and where faster then the previous version - frankly
you are raising alarm for no reason

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit
instead of 32bit

WTF, only in your windows world which don't matter that much, everywhere
else x86_64 is normal for many years and each software

and improvements made to the engine itself, such as
the AST. I submit that it would be smaller and faster if it did not have
to carry around so much dross. Adding something to the core language
just to save a few keystrokes for a small number of lazy developers
falls into the category of dross

you ignored that practicaly every PHP version before PHP/ was faster
and had new features compared to the previous one

7 years ago by Tony Marston — view source

unread

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014271@rhsoft.net...

Am 04.11.2017 um 10:18 schrieb Tony Marston:

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa722b@rhsoft.net...

Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message
news:6643d10b-8703-693c-15c2-da338022ef41@rhsoft.net...

Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen" wrote in message

I fail to see how it offers "negative benefits to the vast number of
programmers who are happy with the language as it currently exists",
I

If it's put into the language then it affects 100% of the users, but
what percentage of the user base would actually take advantage of
this feature? If it's only 1% then for the other 99% it's a complete
waste of time

how does any feature you don't use affect you?

Because the language itself becomes bloated with the capabilities it
has to offer, look for and deal with. This makes it bigger and slower

unproven claim!

It's pure common sense! You have to carry around the capability of doing
something, then have tests everywhere to see if that capability is
actually required or not at run-time.

it depends on the implementation and just beause you say so does not prove
anything and even if you need to measure, optimize and make decisions based
on technical facts - what you do is "mimimi i say"

I have worked on software which provided lots of different options, which
means that you have to keep testing if an option is being used or not. This
is an overhead whether you like it or not.

There is a big difference between adding something to the language core
which everyone has to load into memory, and having something in an
extension which is entirely optional.

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all have
new features and where faster then the previous version - frankly you
are raising alarm for no reason

Can you prove that each new version was faster? Where is your evidence?

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit
instead of 32bit

WTF, only in your windows world which don't matter that much, everywhere
else x86_64 is normal for many years and each software

Excuse me! Some of the major clients who use my ERP application only use
Windows servers, so your claim that Windows does matter is completely bogus.

and improvements made to the engine itself, such as the AST. I submit
that it would be smaller and faster if it did not have to carry around so
much dross. Adding something to the core language just to save a few
keystrokes for a small number of lazy developers falls into the category
of dross

you ignored that practicaly every PHP version before PHP/ was faster
and had new features compared to the previous one

Just think how much faster and easier to maintain it would be if all this
save-a-few-keystrokes dross had not been added in the first place.

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014271@rhsoft.net...

it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"

I have worked on software which provided lots of different options,
which means that you have to keep testing if an option is being used or
not. This is an overhead whether you like it or not.

maybe your implementation was bad

There is a big difference between adding something to the language
core which everyone has to load into memory, and having something in
an extension which is entirely optional.

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all
have new features and where faster then the previous version -
frankly you are raising alarm for no reason

Can you prove that each new version was faster? Where is your evidence?

everbody knows that and can benchmark it at any time, but if it makes
you happy that others are doing your homework

https://www.phpclasses.org/blog/post/493-php-performance-evolution.html

PHP 7 is faster than PHP 5 for various reasons, such as it being
64bit instead of 32bit

WTF, only in your windows world which don't matter that much,
everywhere else x86_64 is normal for many years and each software

Excuse me! Some of the major clients who use my ERP application only use
Windows servers, so your claim that Windows does matter is completely
bogus.

how does that change the fact that your claim "such as it being 64bit
instead of 32bit" is nonsense when most of the benchamrks and production
servers out there are running PHP on x86_64 with 86_64 builds for a
decade now?

and improvements made to the engine itself, such as the AST. I submit
that it would be smaller and faster if it did not have to carry
around so much dross. Adding something to the core language just to
save a few keystrokes for a small number of lazy developers falls
into the category of dross

you ignored that practicaly every PHP version before PHP/ was faster
and had new features compared to the previous one

Just think how much faster and easier to maintain it would be if all
this save-a-few-keystrokes dross had not been added in the first place.

again: unproven claim, but in your own world a hashtable probably is
also not O(1) or you are just not capable to optimize software at all
but then stop claim others aren't too

7 years ago by Tony Marston — view source

unread

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6ff27@rhsoft.net...

Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014271@rhsoft.net...

it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"

I have worked on software which provided lots of different options, which
means that you have to keep testing if an option is being used or not.
This is an overhead whether you like it or not.

maybe your implementation was bad

Everybody knows that carrying around code which is either rarely used or not
used at all is an overhead. That's what the 80-20 rule demonstrates.

Adding something to the language core for something which can already be
done easily is userland code, but with slightly fewer keystrokes, does not
provide any benefits for the majority of developers who have already written
those few lines of code. This is a classic example of pandering to the whims
of a tiny minority to the detriment of the majority.

There is a big difference between adding something to the language core
which everyone has to load into memory, and having something in an
extension which is entirely optional.

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all have
new features and where faster then the previous version - frankly
you are raising alarm for no reason

Can you prove that each new version was faster? Where is your evidence?

everbody knows that and can benchmark it at any time, but if it makes you
happy that others are doing your homework

https://www.phpclasses.org/blog/post/493-php-performance-evolution.html

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit
instead of 32bit

WTF, only in your windows world which don't matter that much, everywhere
else x86_64 is normal for many years and each software

Excuse me! Some of the major clients who use my ERP application only use
Windows servers, so your claim that Windows does matter is completely
bogus.

how does that change the fact that your claim "such as it being 64bit
instead of 32bit" is nonsense when most of the benchamrks and production
servers out there are running PHP on x86_64 with 86_64 builds for a decade
now?

64bit builds of PHP 5 for Windows were all marked as experimental, therefore
not guaranteed to be as reliable as the 32bit versions. The "experimental"
tag was only removed for PHP 7.

and improvements made to the engine itself, such as the AST. I submit
that it would be smaller and faster if it did not have to carry around
so much dross. Adding something to the core language just to save a few
keystrokes for a small number of lazy developers falls into the
category of dross

you ignored that practicaly every PHP version before PHP/ was faster
and had new features compared to the previous one

Just think how much faster and easier to maintain it would be if all this
save-a-few-keystrokes dross had not been added in the first place.

again: unproven claim, but in your own world a hashtable probably is also
not O(1) or you are just not capable to optimize software at all but then
stop claim others aren't too

Everybody knows that carrying around code which is either rarely used or not
used at all is an overhead. That's what the 80-20 rule demonstrates.

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 06.11.2017 um 12:09 schrieb Tony Marston:

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6ff27@rhsoft.net...

Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014271@rhsoft.net...

it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"

I have worked on software which provided lots of different options,
which means that you have to keep testing if an option is being used
or not. This is an overhead whether you like it or not.

maybe your implementation was bad

Everybody knows that carrying around code which is either rarely used or
not used at all is an overhead

everybody knows that claims without measure the impact are worthless

it can even happen that due the implementation other code paths which
would not have been touched otherwise may get optimized due refactoring
and the end result can be even faster in general

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 all
have new features and where faster then the previous version -
frankly you are raising alarm for no reason

Can you prove that each new version was faster? Where is your evidence?

everbody knows that and can benchmark it at any time, but if it makes
you happy that others are doing your homework

https://www.phpclasses.org/blog/post/493-php-performance-evolution.html

interesting that you ignore that now completly

how does that change the fact that your claim "such as it being 64bit
instead of 32bit" is nonsense when most of the benchamrks and
production servers out there are running PHP on x86_64 with 86_64
builds for a decade now?

64bit builds of PHP 5 for Windows were all marked as experimental,
therefore not guaranteed to be as reliable as the 32bit versions. The
"experimental" tag was only removed for PHP 7.

yes, but the majority of production servers is running on Linux,
especially in times where they are mostly virtualized

Just think how much faster and easier to maintain it would be if all
this save-a-few-keystrokes dross had not been added in the first place.

again: unproven claim, but in your own world a hashtable probably is
also not O(1) or you are just not capable to optimize software at all
but then stop claim others aren't too

Everybody knows that carrying around code which is either rarely used or
not used at all is an overhead. That's what the 80-20 rule demonstrates

everybody knows that claims without measure the impact are worthless

it can even happen that due the implementation other code paths which
would not have been touched otherwise may get optimized due refactoring
and the end result can be even faster in general

7 years ago by Tony Marston — view source

unread

wrote in message news:748869f7-13bb-5bdd-6fec-399a33b790b3@rhsoft.net...

Am 06.11.2017 um 12:09 schrieb Tony Marston:

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6ff27@rhsoft.net...

Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message
news:d70cc49d-c397-3f09-d08d-b79b31014271@rhsoft.net...

it depends on the implementation and just beause you say so does not
prove anything and even if you need to measure, optimize and make
decisions based on technical facts - what you do is "mimimi i say"

I have worked on software which provided lots of different options,
which means that you have to keep testing if an option is being used or
not. This is an overhead whether you like it or not.

maybe your implementation was bad

Everybody knows that carrying around code which is either rarely used or
not used at all is an overhead

everybody knows that claims without measure the impact are worthless

Some things are so obvious that they do not need scientific proof. For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car has
a heater which you only use when it's cold. It also has an air conditioner
for when it's hot. It has windscreen wipers, and a motor, for when it's
raining. When the temperature is mild and it's not raining it means that you
are not using any of this equipment, yet you are still carrying their
weight, and this weight is affecting your car's performance. I do not have
to supply any figures as proof as the car manufacturers keep telling us that
cars that weigh less perform better, which is why they try to reduce the
weight of as any components as possible.

It is the same with software. The more code you carry around that is not
being used then the worse it will perform. Esoteric code which uses clever
features to perform tasks which can already be performed with simple code
is, IMHO, an unnecessary complication which benefits only those lazy
programmers who are obsessed with reducing the number of keystrokes. Taking
out the rarely used complicated stuff and concentrating on making the
commonly used stuff as fast and efficient as possible is what drove the
efforts in the RISC architecture. I was around when that happened, so I know
what I'm talking about.

<snip> -- Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 07.11.2017 um 11:21 schrieb Tony Marston:

wrote in message news:748869f7-13bb-5bdd-6fec-399a33b790b3@rhsoft.net...

Everybody knows that carrying around code which is either rarely used
or not used at all is an overhead

everybody knows that claims without measure the impact are worthless

Some things are so obvious that they do not need scientific proof. For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold

pretty sure you know why you removed "it can even happen that due the
implementation other code paths which would not have been touched
otherwise may get optimized due refactoring and the end result can be
even faster in general" beause it may make all your claims and car
comparison worthless at the end of the day

software development is not pure physics and as example code-inlining as
a optimization step of modern compilers proves that all your claims are
wrong until the implementation exists and can be measured

7 years ago by Alice Wonder — view source

unread

Some things are so obvious that they do not need scientific proof.

Some things that appear obvious are incorrect, especially when bias
enters. Scientific proof brings human bias out of the equation, or at
least reduces it.

For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold. It also has an air
conditioner for when it's hot. It has windscreen wipers, and a motor,
for when it's raining. When the temperature is mild and it's not raining
it means that you are not using any of this equipment, yet you are still
carrying their weight, and this weight is affecting your car's
performance. I do not have to supply any figures as proof as the car
manufacturers keep telling us that cars that weigh less perform better,
which is why they try to reduce the weight of as any components as
possible.

You then give an example for which every first year physics students has
done experiments which use science to demonstrate it (namely
demonstrating how weight impacts friction)

Sorry but if something is obvious then it should be able to test in a
scientific experiment.

It use to be obvious that some animals were closely related until
scientific tests were done, showing that they weren't, and we discovers
convergent evolution.

Sorry, I don't mean to go off topic, but saying the scientific method
isn't needed to back up certain claims because they are obvious is a
very dangerous point of view.

7 years ago by Tony Marston — view source

unread

"Alice Wonder" wrote in message
news:572d0e30-7214-0842-6624-7647514b9ad1@librelamp.com...

Some things are so obvious that they do not need scientific proof.

Some things that appear obvious are incorrect, especially when bias enters.
Scientific proof brings human bias out of the equation, or at least reduces
it.

For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold. It also has an air
conditioner for when it's hot. It has windscreen wipers, and a motor,
for when it's raining. When the temperature is mild and it's not raining
it means that you are not using any of this equipment, yet you are still
carrying their weight, and this weight is affecting your car's
performance. I do not have to supply any figures as proof as the car
manufacturers keep telling us that cars that weigh less perform better,
which is why they try to reduce the weight of as any components as
possible.

You then give an example for which every first year physics students has
done experiments which use science to demonstrate it (namely demonstrating
how weight impacts friction)

Sorry but if something is obvious then it should be able to test in a
scientific experiment.

Individuals do not need to provide proof of this claim as it has already
been made by the motor manufacturers who have provided their own proof. That
is why they spend fortunes trying to reduce the weight of every single
component in their cars.

It should also be obvious to every first year student that if a program
contains code that is rarely or never used then carrying around the "weight"
of that code has a detrimental effect. The code has a bigger footprint,
therefore takes up more memory and is slower to load. It also increases the
burden on those who maintain that code as they have to consider every piece
of code without knowing how often it is used.

--
Tony Marston

7 years ago by lists@rhsoft.net — view source

unread

Am 07.11.2017 um 12:53 schrieb Tony Marston:

It should also be obvious to every first year student that if a program
contains code that is rarely or never used then carrying around the
"weight" of that code has a detrimental effect

but you don#t get the basics right: you need to measure if that effect
is significant at all

The code has a bigger
footprint, therefore takes up more memory and is slower to load

slower to load don't matter, if the memory overhead is significant needs
to be measured

It also
increases the burden on those who maintain that code as they have to
consider every piece of code without knowing how often it is used.

and that is not your problem - the whole discussion was about your
claim that it has a bad effect for everybody out there

GOD DAMNED: stop to ignore "it can even happen that due the
implementation other code paths which would not have been touched
otherwise may get optimized due refactoring and the end result can be
even faster in general" - that you ignored it multiple times proves that
you can't say anything which would not prove your claims about the
overall impact wrong

well, you always ignore anything but your opinion and the next step is
calling people "except if you are a nit-picking, anal retentive OCD
sufferer" because they don't follow your argumentation as it happened in
several threads

7 years ago by Levi Morrison — view source

unread

The last 10 or so email messages in this thread have been pointless
bickering. Please stop. Thank you!

7 years ago by Tony Marston — view source

unread

wrote in message news:0f4b93e2-d8fa-edbd-e1ff-5021018393f0@rhsoft.net...

<snip> >well, you always ignore anything but your opinion and the next step is >calling people "except if you are a nit-picking, anal retentive OCD >sufferer" because they don't follow your argumentation as it happened in >several threads

The whole point of my argument is that I believe it is wrong to fill the
language with clever functions which do nothing but save a few keystrokes
for those developers who are too lazy to type out a few simple lines of
userland code. Filling the language with such bloat has a detrimental effect
on everybody who uses the language, and especially on the core developers
who have to maintain that bloat.

You stop telling me that you don't like my opinion and I will stop telling
you that I don't like your opinion.

--
Tony Marston

7 years ago by Stephen Reay — view source

unread

I was around when that happened, so I know what I'm talking about.

I'm not going to get into the whole "it can be done in userland why do we need it in core" debate, because honestly that's a silly discussion to have when you don't have any planned implementation to discuss the merits of.

The only reason I wanted to respond was your last line, quoted above.

Being "around" when something happens means zero as far as credibility or knowledge.

The captain of the titanic was "around" when it sank.

7 years ago by Tony Marston — view source

unread

"Stephen Reay" wrote in message
news:562E5C38-B46B-449D-8676-8699B59DDE4E@koalephant.com...

I was around when that happened, so I know what I'm talking about.

I'm not going to get into the whole "it can be done in userland why do we
need it in core" debate, because honestly that's a silly discussion to have
when you don't have any planned implementation to discuss the merits of.

So you are quite happy to see the language filled with complicated features
which do nothing but save a few keystrokes or lazy developers?

The only reason I wanted to respond was your last line, quoted above.

Being "around" when something happens means zero as far as credibility or
knowledge.

The captain of the titanic was "around" when it sank.

Irrelevant analogy. If you read
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will see
the advantage of getting rid of complex and specialised instructions and
concentrating on simple and general instructions.

--
Tony Marston

7 years ago by Alice Wonder — view source

unread

Irrelevant analogy. If you read
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will
see the advantage of getting rid of complex and specialised instructions
and concentrating on simple and general instructions.

You will see some advantages.

There are also advantages to adding things.

Often it is easier for programmers to write secure code when the complex
stuff they could do in user land is already done for them.

Indeed I believe that is part of the design decisions in TLS 1.3.

It's not just that programmers are lazy and want fewer keystrokes, it is
more likely for the end developer to have fewer mistakes and properly
maintain his code when the complex stuff isn't his or her worry.

That's not the right solution all the time, but it also isn't the wrong
solution all the time.