( resending with correct formatting, and missing context while at it, sorry
about that )
On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote:
(...)
Another aspect here is that there is no reasonable syntax for this
feature, at least I can't think of one:
* The syntax `$foo = (InterfaceName)
On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote:
On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig
kris.cr...@gmail.commailto:kris.cr...@gmail.com wrote:
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara
ircmax...@gmail.commailto:ircmax...@gmail.comwrote:
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan
Hi,
after reading this mail: Is it just me or is a userspace implementation
really that trivial?
function ensure($object, $class) {
if ($object instanceof $class) {
return $object;
}
throw new InvalidArgumentException(sprintf('Object is not of type %s',
$class));
}
And then
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
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).
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
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
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
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
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass sv_for...@fmethod.com wrote:
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
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
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass sv_for...@fmethod.com wrote:
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
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
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
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
On Wed, Aug 15, 2012 at 11:17 AM, Stan Vass sv_for...@fmethod.com wrote:
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
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,
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
On Wed, Aug 15, 2012 at 12:01 PM, Stan Vass sv_for...@fmethod.com wrote:
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
On 15 August 2012 18:15, Nikita Popov nikita@gmail.com wrote:
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
2012/8/15 Stan Vass sv_for...@fmethod.com
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
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote:
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
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara ircmax...@gmail.comwrote:
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote:
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
On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig kris.cr...@gmail.com wrote:
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara ircmax...@gmail.comwrote:
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote:
Hi!
I agree with you. The one case where this syntax may be
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
On Tue, Aug 14, 2012 at 12:46 AM, Stan Vass sv_for...@fmethod.com wrote:
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
On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass sv_for...@fmethod.com wrote:
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?
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
Levi,
On Tue, Aug 14, 2012 at 9:51 AM, Levi Morrison morrison.l...@gmail.comwrote:
On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass sv_for...@fmethod.com wrote:
I've felt the need for this for some time.
Proposed syntax:
-
$x = (InterfaceName) $container-service;
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
30 matches
Mail list logo
