Re: [RFC] Return Type Declarations pre-vote follow-up

Hi! > everything. This means that, not only can a superclass omit an > annotation that a subclass specifies, but a *subclass* can omit an > annotation that the superclass specifies. While this isn't the most I'm not sure it is a good idea. This means having this code: class FooGetter { function getFoo(): Foo { return new Foo(); } } I can extend it as: class TwoFaceFooGetter extends FooGetter { function getFoo() { return rand()%2?new Bar():new Foo(); } } and every function getting FooGetter and expecting getFoo() to return Foo is now broken since instead it could just get Bar(). Since the type return specification is meant, as far as I understand, exactly to avoid cases like that, I don't see it as a good idea. > principled methodology from a hardcore type system perspective, we > believe it is very pragmatic and interoperates well with the > dynamically typed world of PHP. It's been extremely important to us I don't see how having strict typing and then making exceptions for "dynamic typed world of PHP" makes much sense. If we want dynamic typed world, we should do what Ruby, Python, Javascript and others do. If we want to go to strict typing direction instead, we should provide guarantees that strict typing is for. Having strict typing without guarantees makes very little sense to me. > There is always an easy escape hatch. If you require subclasses to The point of strict typing is not having escape hatches. If you can just put anything into typing system and say "shut up and accept it", then you have no guarantees that any value is of any known type. And the the question is - why bother with strict typing at all? What advantage it gives if it's not guarantees that values have known types? > discussion. What is the reason for "self"? The Hack type system calls > it "this", which I admit is a little confusing since it is the type "this" is not a type in PHP. "self" is, which is the type of the class it is mentioned in. > of more things than just the literal variable "$this" ("new static" > for example is also of type "this"). But the type "static" is much "new static" in PHP is not of a known type statically. Dynamically, it is of a type that the method was called with, which is signified, somewhat confusingly, by the keyword "static" even though it is actually not static as dynamic (yes, I know, welcome to the wonderful world of keyword reuse). > more consistent with the existing LSB language, i.e., "new static".. > So is there any reason to call it "self" over "static" or "this"? "self" and "static" are two distinct type keywords. "this" is not a type keyword at all, is there a need for yet another type keyword? I don't think so. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227