> Ok. Well the array type hint ensures that it is an array. This just does
> the opposite then, I don't see a problem with that. I like to be able to
> protected my code from having arrays/objects accidentally inserted into
> databases or outputted.
I completely understand you want to create (easier) more solid code;
However the feature is missing and I think scalar is the wrong
supplement for this missing feature IMO.
> Who wants to do print_r((array) "foobar")?
> I've never seen array type casting, it's pointless. You're proving my
> point here.
// accepts array of ids, or a single id
function notPointless($mixed) {
$ids = (Array) $mixed;
// do $ids stuff
}
notPointless(Array(13,41,81));
notPointless(31);
> This is not casting at all, it's a completely different concept with a
> completely different purpose.
Quote: "I understand type hinting is not type casting (duh)"
> Why is a scalar type hint not acceptable if an array type hint is?
> That's what I really want to know.
In my opinion have type hinting, or don't. I've found use for array
type hinting, to bad we have no other type hinting to go along with
it. So it's basically a half feature. Sam, I think your points of
creating a more string PHP API using type hinting are fine, but doing
it using Array or Scalar is wrong. It should Be Int, Bool, Resource,
String, etc, it just makes more sense _TO_ME_. That is, if you do it
at all, because type hinting all together I do understand goes against
a lot of the php dynamic type philosophy bla bla. But in my opinion if
it makes the language stronger and more attractive and it DOES NOT
break B/C then its probably a good idea. PHP6 is suppose to be a
improvement right?
On Feb 6, 2008 6:37 AM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-02-06 at 06:30 -0700, Chris Stockton wrote:
> > To me it does not make sense to have a scalar type hint. For the
> > simple reason it's inconsistent with PHP, and it adds no value other
> > then the fact you then know the value is not on array (or maybe not a
>
> Ok. Well the array type hint ensures that it is an array. This just does
> the opposite then, I don't see a problem with that. I like to be able to
> protected my code from having arrays/objects accidentally inserted into
> databases or outputted.
>
> > resource?). It's also inconsistent with PHP, array type hinting, is
> > complemented by array type-casting like print_r((array) "foobar"), you
>
> Who wants to do print_r((array) "foobar")?
> I've never seen array type casting, it's pointless. You're proving my
> point here.
>
> > can not echo (scalar) Array('FooBar'); for obvious reasons. I
> > understand type hinting is not type casting (duh) but I think they
> > should correlate more then they do, it just makes sense.
>
> This is not casting at all, it's a completely different concept with a
> completely different purpose. A scalar type cast is useless you're
> right, but a scalar type hint is completely different.
>
> > I have no idea the technicals behind not being able to add stricter
> > type hints, like; float int string, etc. But that would make a lot
> > more sense then the proposed scalar type hint. Do it right, or don't
> > add a hack is my opinion.
>
> Why is a scalar type hint not acceptable if an array type hint is?
> That's what I really want to know.
>
>
> > -Chris
> >
> > On Feb 6, 2008 6:20 AM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > > On Wed, 6 Feb 2008, Sam Barrow wrote:
> > >
> > > > On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
> > > > >
> > > > > I still we should add simple static typehints (ie. just the types that
> > > > > we use in the manual) - and they should behave in the same way as the
> > > > > other type hints that we laready have.
> > > >
> > > > True, but we have to consider the fact that we don't have enough support
> > > > on that side.
> > >
> > > This is not some election campaign were you change what you believe in
> > > just to go get followers. So no, I will not take that into
> > > consideration.
> > >
> > > Derick
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
