On 4/29/2017 6:25 PM, Sara Golemon wrote:
> Your example of GMP can't be simply dismissed as "a special edge
> case", it's precisely true that internals does not always follow the
> same rules as userspace and often it breaks those rules for very good
> reason.
> 

I only said that I do not consider GMP being a dirty hack. I still think
that it is very wrong that we cannot achieve the same in userland.
Operator overloading is something I would love to see.

On 4/29/2017 6:25 PM, Sara Golemon wrote:
> Again, you're weakening your own position.  The PHP manual page for
> curl_setopt() GOES ON to state the per-option types which should be
> passed for $value.  I expect strict types to validate that for me, not
> more, not less.  The fact that you fail to read past the first line of
> the manual page doesn't invalidate the function's *total* signature.
> 

No, this is about the logic inside the function and not it's signature.
Part of the signature is everything before the opening brace. Of course
there are still some short-comings here which I hope will be resolved in
the future, e.g. union types, exceptions, generics; for those we are
required to rely on documentation, for now.

I for one am totally in favor of having dedicated methods for all
options on an option class. It makes it straight forward to discover the
possibilities that are available. The implementation is also simple with
the aid of macros. Doing that would mean that the types of the arguments
are part of the signature. Heck, the array arguments could be variadic
and thus type safe.

On 4/29/2017 6:25 PM, Sara Golemon wrote:
> Again, false.  The fact* that something can not be done in userland
> does not preclude doing it in internals.  You mentioned one such case
> at the start of your reply and there are plenty others.
> 

Of course we can do it, the question is, if we should do it. It makes
the language unpredictable at times, and that is a bad thing.

On 4/29/2017 6:25 PM, Sara Golemon wrote:
> * Pedantically: This is not even true.  Using backtraces and some
> simple hacks, it's quite possible to determine the caller's
> strict_types setting from userspace.  But that's going off on a
> tangent...
> 

More dirty hacks?

I understand that we disagree, but do not try to tell me how I think
about how things should work. Your assumptions/expectations about these
things are built around the idea that strict types is a flag that
changes PHP's behavior. My idea of strict types is built around the idea
that it makes PHP behave they way other sane type safe languages work
(the word sane limits the amount of languages to compare to, Java is
definitely not part of that because of null references, but Kotlin,
Ceylon, Rust, would definitely be candidates).

-- 
Richard "Fleshgrinder" Fussenegger

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to