Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90013
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
 <12.34.07292.41F9A865@pb1.pair.com>
Message-ID: <568AF408.6020105@gmail.com>
Date: Mon, 4 Jan 2016 14:36:56 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <12.34.07292.41F9A865@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: RFC Operator Overloading in Userspace
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> constraint on function parameters and return types. I think it would be
> more worth pursuing a Haskell-style approach in PHP, most likely with a
> hierarchy of magic interfaces.

I agree that interface approach looks better than Python/C++ approach
for PHP. One thing it also allows is introducing things in a gradual and
conceptually sound manner - i.e. Comparable, Numeric, etc. which would
implement specific operator set instead of just letting people
implementing random bag of operators. I'm not sure how to make it
technically but it looks better to me conceptually. We don't have as
powerful type system as Haskell but I think we still can do a lot with
interfaces.

> should work on all number types. I don't think GMP currently overloads
> any of these, though, and there is the possibility we might create
> confusion if overloading extended to math functions.

Which reinforces the point above that maybe before the are tackling the
operators in userspace we need to identify use cases and create
structure for them, and then it might be easier for us to avoid
inconsistencies. We're kind of moved forward with GMP without doing
that, but fortunately it's easier to fix such things while it's confined
to the engine/extensions. Once it's in userspace, changing it would be
way harder.

-- 
Stas Malyshev
smalyshev@gmail.com