# Inline typecasting / typehinting for classes and interfaces

- Thread: https://externals.io/message/62136
- Original archive: https://news-web.php.net/php.internals/62136
- Started by Stan Vass on 2012-08-14T07:46:26+00:00
- Messages: 30
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/62136.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #62136 — Stan Vass — 2012-08-14T07:46:26+00:00

URL: https://externals.io/message/62136#62136

I've felt the need for this for some time.

Proposed syntax:
-------------------------

$x = (InterfaceName) $container->service;

Proposed behavior:
---------------------------

Checks if the instance if an instance of the given class/interfaces. If yes, does nothing, if not, issues a fatal error. Pseudo code:

$temp = $container->service;
if ($temp instanceof InterfaceName) {
    $x = $temp;
} else {
    trigger_error('The object can not be cast to InterfaceName');
}

Use cases:
----------------

As my example hints, the intent is to provide type safety and hinting for the increasingly used dependency injection container pattern. 

It's useful to provide type safety also for all similar patterns which may not return a result of the expected type: Registry, ServiceLocator, Factory etc.

Additionally to runtime type safety, this will also serve to editors/IDEs as an inline hint to provide proper autocompletion, i.e. instead of this:

/** @var $foo InterfaceName */
$foo = $container->service;

People can now just write:

$foo = (InterfaceName) $container->service;

Alternative syntax:
--------------------------

I realize "casting" isn't a perfect match as the behavior is equivalent to inline type hinting. On the other hand, casting and inline type hinting in dynamic languages often behave identically (see the casting behavior in ActionScript which combines type hints with a JS-like dynamic type system).

And this syntax doesn't introduce new keywords. Still, alternative ways to implement this could be:

1. $foo = $container->service as InterfaceName;
2. $foo = $container->service is InterfaceName;
3. $foo = (InterfaceName $container->service);
4. InterfaceName $foo = $container->service;

All of those would be fine, especially 4, which has precedent in other languages, and in PHP as well with typehinting and in catch blocks:  catch (ClassName $e) { ... }

I'm ok with suggestions for any syntax that is as short, if it fits the behavior better.

Feedback?

Stan

---

## #62137 — Kris Craig — 2012-08-14T08:46:05+00:00

URL: https://externals.io/message/62136#62137 · In reply to: #62136

> I've felt the need for this for some time.
>
> Proposed syntax:
> -------------------------
>
> $x = (InterfaceName) $container->service;
>
> Proposed behavior:
> ---------------------------
>
> Checks if the instance if an instance of the given class/interfaces. If
> yes, does nothing, if not, issues a fatal error. Pseudo code:
>
> $temp = $container->service;
> if ($temp instanceof InterfaceName) {
>     $x = $temp;
> } else {
>     trigger_error('The object can not be cast to InterfaceName');
> }
>
> Use cases:
> ----------------
>
> As my example hints, the intent is to provide type safety and hinting for
> the increasingly used dependency injection container pattern.
>
> It's useful to provide type safety also for all similar patterns which may
> not return a result of the expected type: Registry, ServiceLocator, Factory
> etc.
>
> Additionally to runtime type safety, this will also serve to editors/IDEs
> as an inline hint to provide proper autocompletion, i.e. instead of this:
>
> /** @var $foo InterfaceName */
> $foo = $container->service;
>
> People can now just write:
>
> $foo = (InterfaceName) $container->service;
>
> Alternative syntax:
> --------------------------
>
> I realize "casting" isn't a perfect match as the behavior is equivalent to
> inline type hinting. On the other hand, casting and inline type hinting in
> dynamic languages often behave identically (see the casting behavior in
> ActionScript which combines type hints with a JS-like dynamic type system).
>
> And this syntax doesn't introduce new keywords. Still, alternative ways to
> implement this could be:
>
> 1. $foo = $container->service as InterfaceName;
> 2. $foo = $container->service is InterfaceName;
> 3. $foo = (InterfaceName $container->service);
> 4. InterfaceName $foo = $container->service;
>
> All of those would be fine, especially 4, which has precedent in other
> languages, and in PHP as well with typehinting and in catch blocks:  catch
> (ClassName $e) { ... }
>
> I'm ok with suggestions for any syntax that is as short, if it fits the
> behavior better.
>
> Feedback?
>
> Stan


I actually like the (InterfaceName) casting approach.  I can see how type
casting as an object instance could lead to all sorts of innovative coding
architectures.  I'm less enthused about the 4 alternatives you mentioned,
though.  But overall I think it's a pretty awesome idea.

--Kris

---

## #62143 — Levi Morrison — 2012-08-14T13:51:20+00:00

URL: https://externals.io/message/62136#62143 · In reply to: #62136

> I've felt the need for this for some time.
>
> Proposed syntax:
> -------------------------
>
> $x = (InterfaceName) $container->service;

I'm against this.  Let's be honest, how different is this that an
optionally static type?

InterfaceName $x = $container->service;

To be clear, I WANT optionally static typing. For the most part,
type-hinting in class methods solves the static typing needs, but if
we were able to declare a class member to be a certain type that would
be another significant improvement.  I have a proposal in the works,
but I don't want to hijack your thread.

To sum up: I think we need something LIKE what you are proposing, but
I'm against this particular proposal.

---

## #62144 — Stan Vass — 2012-08-14T15:29:18+00:00

URL: https://externals.io/message/62136#62144 · In reply to: #62143

> > […]
>
> I'm against this.  Let's be honest, how different is this that an
> optionally static type?
>
> InterfaceName $x = $container->service;
>
> To be clear, I WANT optionally static typing. For the most part,
> type-hinting in class methods solves the static typing needs, but if
> we were able to declare a class member to be a certain type that would
> be another significant improvement.  I have a proposal in the works,
> but I don't want to hijack your thread.
>
> To sum up: I think we need something LIKE what you are proposing, but
> I'm against this particular proposal.

What you want is option 4 under my alternative syntaxes section :)

I'm ok with syntax 4, in fact, the more I think about it, the more I prefer 
that one (the one you want).
I don't mind the syntax as much, I want the feature.

Stan

---

## #62146 — Anthony Ferrara — 2012-08-14T15:45:35+00:00

URL: https://externals.io/message/62136#62146 · In reply to: #62143

Levi,

On Tue, Aug 14, 2012 at 9:51 AM, Levi Morrison <morrison.levi@gmail.com>wrote:

> 
> > […]
>
> I'm against this.  Let's be honest, how different is this that an
> optionally static type?
>
> InterfaceName $x = $container->service;
>
> To be clear, I WANT optionally static typing. For the most part,
> type-hinting in class methods solves the static typing needs, but if
> we were able to declare a class member to be a certain type that would
> be another significant improvement.  I have a proposal in the works,
> but I don't want to hijack your thread.
>
> To sum up: I think we need something LIKE what you are proposing, but
> I'm against this particular proposal.
>

I agree with you. The one case where this syntax may be very useful is if
we want to implement class casting. So introduce a pair of magic methods

public function __castToClass($class) {
}

public static function __castFromScalar($scalar) {
}

Then,

$foo = (A) $objectExtendingFromA; // No-op
$foo = (A) $objectNotFromA; // Calls $objectNotFromA->__castToClass('A'),
and if it returns something that matches A, good, if not fail
$foo = (A) 1; // Calls A::__castFromScalar(1);

Now, note that it would only work on class names, as doing it on interfaces
would only work in the objectNotFromA case (and even then, it would be
weird).

Now, I'm just saying that this is the only way I'd want to see something
like this. The use cases for it are there, but extremely narrow and likely
better solved with other mechanisms. So I'm not completely sure I like the
concept as a whole, but just throwing it out there...

Anthony

---

## #62149 — Stas Malyshev — 2012-08-14T17:11:06+00:00

URL: https://externals.io/message/62136#62149 · In reply to: #62146

Hi!

> I agree with you. The one case where this syntax may be very useful is if
> we want to implement class casting. So introduce a pair of magic methods

I do not think we want to implement class casting. I'm not sure how
class casting even makes sense - if the object is of one class, how can
you just make it into another class by casting? If you mean "casting"
actually returns another object of different class, then just make a
method for that that returns that object, I do not see how obscuring the
purpose of this operation with unobvious syntax would help.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62164 — Stan Vass — 2012-08-15T07:57:34+00:00

URL: https://externals.io/message/62136#62164 · In reply to: #62149

> Hi!
>
> > […]
>
> I do not think we want to implement class casting. I'm not sure how
> class casting even makes sense - if the object is of one class, how can
> you just make it into another class by casting? If you mean "casting"
> actually returns another object of different class, then just make a
> method for that that returns that object, I do not see how obscuring the
> purpose of this operation with unobvious syntax would help.

The discussion is starting to drift very far from my original proposal.

Instead of trying to guess what I mean, can't people just refer to my very 
simple definitive proposed behavior?

My proposal is simple: behave as an inline type hint. The same type hints 
you have in arguments lists, but inline. The use case is "I want to make 
sure this value is of this type" and a side benefit is the IDE can know the 
variable is of this type too (for autocompletion purposes).

Whether they'd be exposed with the cast syntax or otherwise isn't that 
important. Languages like ActionScript expose inline type validation both by 
"static typing" hints and by "casting". In both cases the operation simply 
validates the class can be seens as an instance of this class/interface.

Stan

---

## #62165 — Stas Malyshev — 2012-08-15T08:02:54+00:00

URL: https://externals.io/message/62136#62165 · In reply to: #62164

Hi!

> My proposal is simple: behave as an inline type hint. The same type hints 
> you have in arguments lists, but inline. The use case is "I want to make 
> sure this value is of this type" and a side benefit is the IDE can know the 
> variable is of this type too (for autocompletion purposes).

What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
  trigger_error(E_USER_ERROR, "Wrong foo!");
}

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62166 — Stan Vass — 2012-08-15T08:06:30+00:00

URL: https://externals.io/message/62136#62166 · In reply to: #62149

I'd like to also ask people to read what the intended effect of the proposal 
is instead of going into abstract discussions about how casting one class to 
another doesn't make sense (this is not what's being proposed).

Just like PHP typehints look like static typing but *aren't*, the same way 
the fact this looks like a static cast *doesn't* make it so. A dynamic 
language can't have static casts, and I'd think this is obvious to 
everybody.

Instead, I'm adapting the principle so it fits with existing PHP behaviors 
and patterns.

Syntax which looks like static typing is fine by me as well. Examples:

ClassName $foo = expression();

foreach ($list as InterfaceName $item) { ... }

etc.

The only operation done here is validating the variable is a valid instance 
of this type. No transformation is happening.

Stan

---

## #62167 — Stan Vass — 2012-08-15T08:15:04+00:00

URL: https://externals.io/message/62136#62167 · In reply to: #62165

> What's wrong with instanceof? You can then throw fatal error if you
> want, it's just two lines:
>  if(!($foo instanceof Bar)) {
>  trigger_error(E_USER_ERROR, "Wrong foo!");
> }

That's 3 lines on top of the line where you assign the value, and you forgot 
the 4th line for the IDE:

-----
/* @var $foo Bar */
$foo = expression();
if(!($foo instanceof Bar)) {
   trigger_error(E_USER_ERROR, "Wrong foo!");
}
-----

Versus this:

----
Bar $foo = expression();
----

And assignment is a kinda common operation. So I hope you can see what's 
wrong with it now.

Stan

---

## #62168 — Stas Malyshev — 2012-08-15T08:23:27+00:00

URL: https://externals.io/message/62136#62168 · In reply to: #62167

Hi!

> And assignment is a kinda common operation. So I hope you can see what's 
> wrong with it now.

No I do not. Not every imaginable use case should have dedicated
language construct for it - sometimes it is OK to type 2 lines of code.
Sometimes even 3. This case is well served by existing language syntax,
which also allows much more flexibility and control over what happens if
the variable does not match. I see no reason to invent language
construct the only purpose of which is to save you typing one if clause.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62169 — Nikita Popov — 2012-08-15T08:27:56+00:00

URL: https://externals.io/message/62136#62169 · In reply to: #62166

> I'd like to also ask people to read what the intended effect of the proposal
> is instead of going into abstract discussions about how casting one class to
> another doesn't make sense (this is not what's being proposed).

I think you confused everyone by a) having "typecasting" in the title
and b) starting with the (Foo) casting syntax (so everyone assumed
that you indeed want some kind of class casts, whatever that may be).

Regarding the actual proposal, could you maybe clarify the use-cases
for this? I can see that it could be useful in principle, but your
actually named use cases confuse me somewhat. In particular, I don't
see how this would help dependency injection containers. I can see
that it helps service locators and registries, but both of those are
considered antipatterns, so there is no reason to add additional
language features for them. DICs are only used to inject top-level
dependencies, so in that case types should be fairly well covered by
parameter type hints.

Nikita

---

## #62170 — Stan Vass — 2012-08-15T08:29:12+00:00

URL: https://externals.io/message/62136#62170 · In reply to: #62168

> > […]
>
> No I do not. Not every imaginable use case should have dedicated
> language construct for it - sometimes it is OK to type 2 lines of code.
> Sometimes even 3. This case is well served by existing language syntax,
> which also allows much more flexibility and control over what happens if
> the variable does not match. I see no reason to invent language
> construct the only purpose of which is to save you typing one if clause.

Let me ask you - do you think the existing PHP typehints are pointless too? 
Do you feel they don't give you enough flexibility? Do you feel they 
reinvented a language construct for the purpose of saving the typing of one 
if clause (per argument) (per method) (per class)?

And why do you keep ignoring the fact that IDE's need additional clutches to 
understand the type of the variable?

Stan

---

## #62171 — Stas Malyshev — 2012-08-15T08:36:26+00:00

URL: https://externals.io/message/62136#62171 · In reply to: #62170

Hi!

> Let me ask you - do you think the existing PHP typehints are pointless too? 
> Do you feel they don't give you enough flexibility? Do you feel they 
> reinvented a language construct for the purpose of saving the typing of one 
> if clause (per argument) (per method) (per class)?

They are not pointless, but I think they are often misunderstood and not
used correctly. And they definitely lack flexibility in many cases. But
they are helpful for one important thing - defining interface between
the method and the method client. Having strictly typed variables does
not serve it, and trying to make PHP into half-baked
half-statically-typed language does not sound like a good idea to me.

> And why do you keep ignoring the fact that IDE's need additional clutches to 
> understand the type of the variable?

Because I don't think inventing language constructs for the purpose of
helping IDEs simulate static typing in dynamically typed language makes
much sense.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62172 — Stan Vass — 2012-08-15T08:39:06+00:00

URL: https://externals.io/message/62136#62172 · In reply to: #62169

> 
> > […]
>
> I think you confused everyone by a) having "typecasting" in the title
> and b) starting with the (Foo) casting syntax (so everyone assumed
> that you indeed want some kind of class casts, whatever that may be).

I had "typecasting / typehinting" in the title, and I'd like to remind 
everyone again that in dynamically typed languages class casts are often 
implemented as a basic validation operation, consistent with what I 
proposed.

> Regarding the actual proposal, could you maybe clarify the use-cases
> for this? I can see that it could be useful in principle, but your
> actually named use cases confuse me somewhat. In particular, I don't
> see how this would help dependency injection containers. I can see
> that it helps service locators and registries, but both of those are
> considered antipatterns, so there is no reason to add additional
> language features for them. DICs are only used to inject top-level
> dependencies, so in that case types should be fairly well covered by
> parameter type hints.

Two use cases apart from registries: PHP has no typed iteration and arrays, 
so you the only way to guarantee (and the IDE to know) the type of a 
variable in these cases is a hint:

Foo $bar = $array[1];
foreach ($array as Foo $item) { ... }

Automatically this applies to everything that uses ArrayAccess as a 
shorthand too, and properties of anonymous objects (stdClass).

The current alternative is peppering code with pseudo-PHPDoc inline hints, 
and instanceof assertions which truly is a facility the language core should 
provide, instead of us emulating it.

Stan

---

## #62173 — Stan Vass — 2012-08-15T08:43:13+00:00

URL: https://externals.io/message/62136#62173 · In reply to: #62171

> Hi!
>
> > […]
>
> They are not pointless, but I think they are often misunderstood and not
> used correctly. And they definitely lack flexibility in many cases. But
> they are helpful for one important thing - defining interface between
> the method and the method client. Having strictly typed variables does
> not serve it, and trying to make PHP into half-baked
> half-statically-typed language does not sound like a good idea to me.

All right, your method accepts an array of objects, instances of Foo. How do 
you enforce this contract?

Here's how my proposal enforces it:

function foobar(array $collectionOfFoo) {
    foreach ($collectionOfFoo as Foo $item) {
        ...
    }
}

What's your proposal? From the discussion so far, I'd guess it's peppering 
out code with if-s with the same error written everywhere everytime we check 
the item in an array.

> Because I don't think inventing language constructs for the purpose of
> helping IDEs simulate static typing in dynamically typed language makes
> much sense.

The same applies to typehints, so make up your mind.

Stan

---

## #62174 — Stas Malyshev — 2012-08-15T09:06:38+00:00

URL: https://externals.io/message/62136#62174 · In reply to: #62173

Hi!

> All right, your method accepts an array of objects, instances of Foo. How do 
> you enforce this contract?

You are trying to re-invent generics/parametrized types and bolt it onto
PHP. I still don't think it is a good idea - PHP is not a statically
typed language. Just check you array elements if you need.

> What's your proposal? From the discussion so far, I'd guess it's peppering 
> out code with if-s with the same error written everywhere everytime we check 
> the item in an array.

By "peppering" here you mean one if. Yes, this is my proposal - if you
need to do a check - do a check.

> The same applies to typehints, so make up your mind.

No it does not. But this is exactly why I think one of the problems with
strict typing in arguments is - because people take it and starting to
use it as a legitimation of turning PHP into weird hybrid of dynamically
typed language with random islands of static typing popping in random
places. I still do not think it is a good idea.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62175 — Stan Vass — 2012-08-15T09:17:46+00:00

URL: https://externals.io/message/62136#62175 · In reply to: #62174

> Hi!
>
> > […]
>
> You are trying to re-invent generics/parametrized types and bolt it onto
> PHP. I still don't think it is a good idea - PHP is not a statically
> typed language. Just check you array elements if you need.

You're 10 years too late to argue the merits of typehints in PHP.

I am not proposing the introduction of typehints. I'm just saying "we have 
the option to use them in arguments, let's have the options inline too."
This way we can validate expressions and structures we can't today, in a 
minimal, readable, consistent, easy to maintain way.

> By "peppering" here you mean one if. Yes, this is my proposal - if you
> need to do a check - do a check.

Yes, exactly: one if. For your entire codebase that has one single 
assignment in it.

Or one foreach. Pick one or the other, but not both, otherwise they become 
two ifs, and that invalidated your argument.

> > […]
>
> No it does not. But this is exactly why I think one of the problems with
> strict typing in arguments is - because people take it and starting to
> use it as a legitimation of turning PHP into weird hybrid of dynamically
> typed language with random islands of static typing popping in random
> places. I still do not think it is a good idea.

Saying "weird hybrid random islands popping random" doesn't make simple type 
validation hints any more awkward than they were yesterday before I posted 
this thread, Stas.

Stan

---

## #62176 — Nikita Popov — 2012-08-15T09:26:39+00:00

URL: https://externals.io/message/62136#62176 · In reply to: #62175

> You're 10 years too late to argue the merits of typehints in PHP.
>
> I am not proposing the introduction of typehints. I'm just saying "we have
> the option to use them in arguments, let's have the options inline too."
> This way we can validate expressions and structures we can't today, in a
> minimal, readable, consistent, easy to maintain way.

Stas already pointed out that parameter typehints allow you to define
the interface for your method. Return typehints would server a similar
purpose and as such I'd consider them useful. But "variable" typehints
don't serve any such purpose. Actually, one could even say that they
don't serve *any* purpose, short of providing the IDE with type
information, because your code would work just as well even without
the type check. If the type were wrong, it would just throw a fatal
error when trying to do something with it (like invoking a method that
does not exist).

And if the sole purpose is type hinting for the IDE, then I don't see
what's wrong with the established system of PHPDoc comments. They seem
to serve the same purpose, don't they?

Nikita

---

## #62178 — Stan Vass — 2012-08-15T09:34:04+00:00

URL: https://externals.io/message/62136#62178 · In reply to: #62176

> Stas already pointed out that parameter typehints allow you to define
> the interface for your method. Return typehints would server a similar
> purpose and as such I'd consider them useful. But "variable" typehints
> don't serve any such purpose.

I gave an example validating an array of Foo instances, which the current 
system doesn't solve. Of course PHP could extend argument typehints to 
describe this, but Stas *just* said he doesn't want generics and so on in 
PHP.

All right, I don't either. I just want a clean way to describe my 
expectation that a variable is what it is, and assuming that all function 
arguments are one single instance simply doesn't match the real world out 
there. People iterate arrays, they pass arrays around. And they have 
expectations for what's inside those arrays.

Stan

---

## #62179 — Stan Vass — 2012-08-15T10:01:47+00:00

URL: https://externals.io/message/62136#62179 · In reply to: #62176

> But "variable" typehints
> don't serve any such purpose. Actually, one could even say that they
> don't serve *any* purpose, short of providing the IDE with type
> information, because your code would work just as well even without
> the type check. If the type were wrong, it would just throw a fatal
> error when trying to do something with it (like invoking a method that
> does not exist).

Just like with argument typehints.
Point me to an argument typehint that is required for your code to run.

You and Stas keep giving arguments against argument typehints, which is 
really awkward.

Stan

---

## #62180 — Nikita Popov — 2012-08-15T10:15:41+00:00

URL: https://externals.io/message/62136#62180 · In reply to: #62179

> Just like with argument typehints.
> Point me to an argument typehint that is required for your code to run.
>
> You and Stas keep giving arguments against argument typehints, which is
> really awkward.

As already pointed out repeatedly, argument typehints serve the
purpose of defining an interface. No, they are not required to run the
code, that's true. But they still serve an important purpose for
object oriented programming (and, just to make sure that you don't
miss it again: That purpose is defining the interface). Variable
typehints do not, as far as I can see.

> I gave an example validating an array of Foo instances, which the current system doesn't solve.

Yes, and your system doesn't solve it either, or does it? As the
validation does not happen through a parameter typehint it does not
help defining the public interface. It only helps the IDE know the
type (which doc comments can also do).

Nikita

---

## #62181 — Adam Harvey — 2012-08-15T10:28:55+00:00

URL: https://externals.io/message/62136#62181 · In reply to: #62180

> As already pointed out repeatedly, argument typehints serve the
> purpose of defining an interface. No, they are not required to run the
> code, that's true. But they still serve an important purpose for
> object oriented programming (and, just to make sure that you don't
> miss it again: That purpose is defining the interface). Variable
> typehints do not, as far as I can see.

I was most of the way through writing a much longer e-mail responding
to the original post, but you and Stas have summed it up well, really.
Type hints actually have a use in the object model of PHP in terms of
interface definition. The only uses I can see for these variable hints
are:

1. An informative use for IDEs, as previously noted, which is already
filled adequately by @var documentation.

2. An assertive use in development: effectively, a different way of
writing assert($var instanceof ClassName) to verify your assumptions
on variable types.

Personally, I don't think either of those justify the addition of the feature.

The thing is that even ignoring type hints' interface definition
functionality and treating them as pure syntactic sugar, type hints
have another benefit: if you have several parameters to a function,
type hints allow you to verify their classes in one hit, rather than
having to make several calls to a verification function or implement
something like zpp for objects in userspace. That leads to neater,
shorter code. This feature doesn't have that quality: you can only
hint one variable at a time, so there's not even a significant saving
in time/typing for the developer between (to pick the only version of
the syntax I don't find completely objectionable) "ClassName $var =
$object;" and "$var = isType($object, 'ClassName');".

In summary, I guess I'm -1 on the feature, and -10⁹ on any version of
the feature that looks like a typecast. :)

Adam

---

## #62188 — Sebastian Krebs — 2012-08-15T11:23:55+00:00

URL: https://externals.io/message/62136#62188 · In reply to: #62179

2012/8/15 Stan Vass <sv_forums@fmethod.com>

> But "variable" typehints
> > […]
>
> Just like with argument typehints.
> Point me to an argument typehint that is required for your code to run.
>

Hi,

Point me to an argument inerfaces are required. Or boolean (would could use
0/1 instead). Or abstract methods. Or function/methods parameters (we could
use `func_get_args()`). Or default parameters. Or [insert random feature
here].

Or: Point me to an argument, why the array of "Foo" shouldn't be a
specialised class, that implements 'Iteratable'. With this your foreach
"problem" simply disappear and everything, what remains, is something to
make IDEs happy (with one line less to write...).

My opinion

Regards,
Sebastian


>
> You and Stas keep giving arguments against argument typehints, which is
> really awkward.


>
> Stan

---

## #62190 — Anthony Ferrara — 2012-08-15T11:48:51+00:00

URL: https://externals.io/message/62136#62190 · In reply to: #62164

Stan,



> Hi!
> > […]
>
> The discussion is starting to drift very far from my original proposal.
>
> Instead of trying to guess what I mean, can't people just refer to my very
> simple definitive proposed behavior?
>

My point was that what I posted was the only way that I can see for the
original proposal to be useful.

Anthony

---

Next page: https://externals.io/message/62136.md?page=2