On Jan 7, 2008 1:34 PM, Sam Barrow <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
> > On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
> > > Sam Barrow schrieb:
> > > > Keep in mind that your "do_whatever" would actually be a trigger error
> > > > with an error message including the name of the function and parameter
> > > > number.
> > >
> > > I did not make the point of my code clear enough. do_whatever is not the
> > > code that triggers the error, but the code that handles the error.
> > >
> > > My point is that I think people will start checking parameters before
> > > they call a function to avoid a fatal error. This is more code and
> > > uglier, because you'll have to repeat it for every function call,
> > > instead of once in the function body.
> > >
> > > Even if they put an explicit typecast into a function call, like
> > > foo((int) $something) error handling code would have to be provided in
> > > case the cast was not possible.
> >
> > This is an optional feature. It's MY library, why can I not force
> > consumers of the API to use it how I, the developer, think it should be
> > used?
> >
> > The onus should be on consumers of my API to use it properly, not on me
> > to jump through hoops to make sure they gave me the correct data at
> > every step of the way. I stopped holding hands in grade 3 or so.
>
> True. It would also keep the APIs more tightly integrated, and
> interaction less prone to type errors.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I believe the cleanest solution that we could implement would be using
the type casting with "Type" objects.
Just like java, php could have internally something as follow:
$int = new Integer(3);
$string = new String("3");
$double = new Double(3.231);
That way, we could easily do such:
class Foo
{
public function fooString(String $stringValue)
{
// wan wan... we want an int now...
return $string->parseInt();
}
public function fooInteger(Integer $intValue)
{
// Wan wannnn we want a string back!
return $int->toString();
}
// ...
}
This is of course very easily implementable in user land code,
however, if we would put it internally, it would give the ability to
anyone who wants to use it to use it correctly to use it (broad usage)
The mentioned method would be used only by people who need type
hinting and they would be using ONLY the good types in their functions
since the only thing they could pass is an instantiation of the
desired data type.
Since people seem to be very scared about not being able to convert
this and that, we could provide methods as such as
$int->toString();
$string->parseInt();
etc.
This would not differentiate from using it as
(int)$int;
(string)$string;
But it would give much flexibility and OO Behaviors.
People would do not want to use it just don't use it, and people who
wish to use it could.
I remember Hannes posted a simple implementation for userland on this
very same internals list, I think it was clean and simple to use.
Performance wise.. hey, if one has a dying wish of using OOP concepts,
he's probably willing to loose a bit of performance to maintainability
and strictness-ity? and having strong typed applications.
$0.02...
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
