On Tue, 2008-01-08 at 16:03 +0200, Tomi Kaistila wrote:
> > I believe the cleanest solution that we could implement would be using
> > the type casting with "Type" objects.
> I experimented with this for a couple of months, a couple of weeks ago. In
> opinion, it does not work well. I am guessing developers at java also figured
> the same since they still also have primitive types. Aside from the mentioned
> performance cost, it results in ugly and clumsy code. Not to mention you need
> to cast the objects into primitive types if you wish to use the variables
> with PHP functions.
>
> function random(Integer $max, Integer $min)
> {
> $n = rand($min->getInteger(), $max->getInteger());
> return $n;
> }
>
> Implementing the __toString() method in the classes helps a little but not
> much.
But the syntax is longer ("$a = 5" vs "$a = new Integer(5)"), and if you
have a large application with hundreds of integers it starts to add up.
Performance is also much worse when using objects for every variable.
> And really, if you think about it, just adding support to scalar type hinting
> solves the hold issue, thus making this sort of solution pointless and a pit
> hole wasted energy and time.
>
> > Is there any reason we can't at least add "scalar" and
> > "resource" (and possibly "object" for generic objects) to typehints?
> This sounds like, at least, a partial victory to adding proper type hinting
> to
> PHP but in my mind it is not enough. I have counted that about a quarter of
> all type hints that I would make is about matching the argument's type to
> scalar. The rest are about separating specific scalars from each other. In
> most cases integer and boolean.
Better than nothing.
> I would probably end up not using type hinting at all, just to save the users
> of my API from the confusion and just do the type checks myself inside my
> methods.
>
> > Thinking about this, simply because we all know PHP __CAN__ type
> > juggle, there is no need for any errors/warnings/notices on scalar
> > types. It will be up to the API developer to make sure appropriate
> > values are supplied (if necessary), so this reduces the type checking.
> In other words, it is not "in the spirit of PHP" to enable strict type
> hinting. I can understand this argument, but I still disagree heavily with
> this approach.
>
> 1) It is not consistent with the way that Array and Object type hinting
> works.
> While you might make the argument that it is not an issue because you cannot
> implicitly cast those types, it does create an annoying (yet another) magic
> behavior thing in PHP that people need to learn and remember. If anything, it
> will confuse new users, which I believe a lot of people were concerned about.
>
> Essentially, if it is necessary (and most of the time it is) to validate the
> value beyond just the type, you might as well do the casting at the same time
> as you validate.
>
> 2) The reason people are asking for type hinting for scalars is specifically
> to move some of the responsibility from the API developer to the user of the
> API and it is not an unreasonable request. After all, if person A has a
> program that asks for user input, the best place for validation is not in the
> class that person B wrote. The values should be validated in the program that
> asked for the input. Since the validation is necessary, person A can easily
> cast the type of the input at the end of the process, before he passes it to
> the class.
>
> E.g.
>
> function validate($input)
> {
> // validate the input
> // return false if it was not valid
> // otherwise return a properly cast value
> }
>
> $input = $_GET['var1'];
> $input = validate($input)
>
> if(! empty($input)) {
> doSomething($input);
> }
>
> This seems like a perfectly logical division of labor. The validator
> validates
> and casts and the library class acts on the proper input.
>
> Tomi Kaistila
> PHP Developer
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
