Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37240
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.200.174 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=sZC6/GvooJEdTdgyCLIjWe2554z+xTpRVzAw8oQC5ePgCxUOmO6exwNjKvrmdAiDwP1/HMS/rC3d256im6RO/UxyZWUzaQl+V3WyNy6/vmAgULXsWsGrsiT+497V/JpB0wR2opZn50yAd42RLRdmG45bF40VIfxx1T3qpqg76yg=
Message-ID: <e2e02fe0804251515j2f2f2de4we340f373abb9ee03@mail.gmail.com>
Date: Fri, 25 Apr 2008 15:15:15 -0700
To: "Sam Barrow" <sam@sambarrow.com>
Cc: "Nathan Nobbe" <quickshiftin@gmail.com>, 
	"Jeremy Privett" <jeremy@omegavortex.net>, 
	"Alain Williams" <addw@phcomp.co.uk>, internals@lists.php.net
In-Reply-To: <1209161062.31032.1.camel@desktop>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_7918_24780249.1209161715458"
References: <1209137410.6642.9.camel@sbarrow-desktop>
	 <1209147362.20639.7.camel@sbarrow-desktop>
	 <20080425182341.GB14490@mint.phcomp.co.uk>
	 <1209149047.20639.18.camel@sbarrow-desktop>
	 <48122C14.7070705@omegavortex.net>
	 <1209150944.20639.24.camel@sbarrow-desktop>
	 <7dd2dc0b0804251224s750679acn169637efbd8653fa@mail.gmail.com>
	 <1209151505.20639.25.camel@sbarrow-desktop>
	 <e2e02fe0804251422k36dd56c6r71b1ce69401d42b6@mail.gmail.com>
	 <1209161062.31032.1.camel@desktop>
Subject: Re: [PHP-DEV] Return type hinting patch
From: chrisstocktonaz@gmail.com ("Chris Stockton")

------=_Part_7918_24780249.1209161715458
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello Sam,

I think you misunderstand, let me retype for you.

strlen('abstract protected function string dostuff()') < strlen('abstract
protected function dostuff() return string')

Making your argument on length void, also, maybe we should not base a
language change decision on typing extra characters..

Sorry man, but to me the code below looks so unusual for what it is meant to
represent:

abstract protected function bar($foo) return string {
    // code
}

The above, actually kind of makes me think something non-conventional is
going to happen like return string specifies that it will be auto type
casted to a string for me or something. like:

abstract protected function bar($foo) return string {
    return $foo;
    // is auto magically like: return (string) $foo;
}

vs the below code that tells me function returns a string like in many
popular languages.
abstract protected function string bar($foo) {
    return (string) $foo;
}

-Chris

On Fri, Apr 25, 2008 at 3:04 PM, Sam Barrow <sam@sambarrow.com> wrote:

> I don't know, maybe it does work. But either way I'm not introducing a
> new keyword, I changed the patch to reuse the return keyword.
>
> Yes, long strings of keywords:
>
> abstract protected string function dostuff()
>
> On Fri, 2008-04-25 at 14:22 -0700, Chris Stockton wrote:
> > On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow <sam@sambarrow.com>
> > wrote:
> >
> >         On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
> >         > On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow
> >         <sam@sambarrow.com> wrote:
> >         >         On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett
> >         wrote:
> >         >         > Sam Barrow wrote:
> >         >         > > I figured it out, the syntax is now as follows:
> >         >         > >
> >         >         > > function a($b, $c) returns d {
> >         >         > > }
> >         >         > >
> >         >         > > I'll post an update soon.
> >         >         > >
> >         >         > >
> >         >         > >
> >         >         >
> >         >         > That's certainly a non-intuitive syntax. How about
> >         we take a
> >         >         page out of
> >         >         > the book of other C-style languages before trying
> >         to invent
> >         >         something
> >         >         > else? I agree with Stas, "return" and "returns"
> >         are not part
> >         >         of a
> >         >         > function definition.
> >         >
> >         >
> >         >         I don't think it's non-intuitive at all, and even
> >         so, it's the
> >         >         most intuitive we have. This ordering makes more
> >         sense to me
> >         >         at first glance (in the order I would think about
> >         things;
> >         >         scope, name, arguments, return).
> >         >
> >         > im not sure the following has been explicitly proposed, but
> >         how about
> >         > omitting the 'return' keyword and placing the return type
> >         hint before
> >         > the function identifier
> >         >
> >         > function int a($b, $c) {}
> >         >
> >
> >
> >         This is, but I don't think this is possible, due to confusion
> >         with the
> >         keywords (public, private, static, abstract, etc). Plus this
> >         leads to
> >         long strings of keywords.
> >
> > There can be no technical reason why this more adopted and understood
> > syntax should  not be possible. Adding returns as a keyword would
> > completely break tons of code. Why are the proposals on something that
> > is so consistent across many languages being changed so obscurely? Why
> > a seperate non-intuitive syntax.
> >
> > public function int (string $foo) { return 1; }
> >
> > Can't we keep the sanity?
> >
> >
> >         [ ... ] Plus this leads to
> >         long strings of keywords.
> >
> > Are you kidding?  strlen('returns int') > strlen('int'); .....
> >
> >
> > -Chris
>
>

------=_Part_7918_24780249.1209161715458--