Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77191
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.6.131 as permitted sender)
Message-ID: <5415D074.3020907@sugarcrm.com>
Date: Sun, 14 Sep 2014 10:29:24 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk> <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com> <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
In-Reply-To: <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> The vote would be for the RFC as it is. Possible changes are things
> in the RFC I was uncertain on. I might hold votes on some of them,
> actually.

I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them "as it
is"? Only one of them can be implemented in code. If everybody agrees
that one of them should be so, then just remove the others. If there's
disagreement then how people can vote "yes" having contradictory ideas
in mind? One of them would be voting "yes" for the opposite of what he
thought he's voting. If the specific choices do not matter, just choose
one of the options - if they're so insignificant nobody would care if
you end up with another. In any case, there should be a clear
understanding of what is actually proposed, instead of having 5
branching points for potentially 32 different RFCs. Or, if you
absolutely can't make up your mind you can offer the options for the
vote. But there should be some specificity.

Otherwise the vote is meaningless - it's not the vote for specific
implementation but just for some vague "let's do something I don't care
what it is" and I don't think such votes make sense. Please choose
something and put it to a vote. If it doesn't work, we can have
different try or maybe we can just see there's no consensus on this for
now, but at least we'd be clear and not think we have consensus on
something but not know what actually it is.

> The problem is that we *can't* be consistent. Internal functions
> already live in this completely different world from user land
> functions. Nullability is handled differently. They use implicit

If we can't make it work well, maybe we should clean it up first instead
of making it worse.

> If we're just talking about casting, then this proposal does not
> alter casting behaviour, in fact I've been very careful not to touch
> it. It does, however, only accept a subset of the values zpp usually

Casting while passing parameters is part of the casting behavior.

> does. This is because it is a compromise between strict and weak
> parameter typing. While I understand you might like it to be fully

Again, my opinion is that bad compromise is worse than not having any
implementation, because it closes future possibilities for better
solution. Of course, there's a risk better one would never come, so
everyone has to decide if they want "at least something" now or have a
better one latter.

> weak like zpp, many userland developers are in favour of something
> stricter, thus the compromise. Unlike zpp's rules, at least these
> rules are clearly specified and prevent data loss.

I'm not sure why is this attention to data loss. In most scenarios when
we're not talking about banking applications etc. if you expect a number
and you've got a string "123abc", treating it as 123 is fine. No
*useful* data is lost, since "abc" part passed to a numeric function is
not useful data, it's garbage. Of course, for some app if you have
garbage in data you're supposed to stop the app and wait for the human
to arrive and clean up because it's too sensitive to trust a computer to
figure it out. But in more common case just ignoring the garbage would
work fine.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/