I both like and dislike the fact that PHP is so loosely typed. It makes
it very easy, which I like, however it is sometimes not strict enough,
allowing for undetected errors, which of course I don't like.
I think the ideal solution here is to make it a hybrid type of language,
where typing is dynamic, but still controllable using type hinting. You
can use whichever you want where you want. Functions can have 3
parameters, two hinted and one not.
Keep in mind this is not strict typing. Key word: "hinting".
If all is 100% optional, your application can take advantage of the
flexibility of dynamic typing in places where it's needed, and also take
advantage of the control that type hinting gives you where it's
appropriate. Most languages either allow you to do whatever you want,
making some code chaotic and some bugs harder to detect, whereas some
are the complete opposite, imposing very strict limits on your
variables, and severely limiting your flexibility. PHP could be the
middle ground, with maximum flexibility, but also maximum control.
I'm currently using my type hinting patch with PHP 5.3 for an
application I'm working on with about 10,000 lines of code and hundreds
of functions, big and small. I'm using type hinting in most of the
functions, but not all. It's been very helpful so far, especially with
the "scalar" and "number" type hints.
On Sun, 2007-11-18 at 21:50 -0500, David Coallier wrote:
> On Nov 18, 2007 7:24 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> > On Nov 19, 2007 12:13 AM, David Coallier <[EMAIL PROTECTED]> wrote:
> > > I was thinking at something along the lines of objects also for instance:
> > >
> > > $i = new Integer(33);
> > >
> > > function foo(Integer $var) {
> > > }
> > >
> > > foo ($i); else it emits a fatal error. But also if you do
> > >
> > > $i = "Name"; that would emit a fatal error because the value is
> > > suposed to be an int. This might look a bit too much like java, but as
> > > an extension it could be something quite interesting I believe.
> > >
> > > String, Object, Integer, Scalar, Float and what else.
> > >
> > > So thinking of something like
> > >
> > > $string = new String("Foo");
> > > $string = "bar" or $string->setValue("Bar"); would do
> > >
> > > $float = new Float(4.242);
> > > $float->setValue('foobar'); // That emits an error
> > > $float->setValue(3.14159);
> > >
> > > echo $float; (__toString) or echo $float->getValue; to echo it's
> > > content/value
> > >
> > > and so on.
> >
> > That has got to be the worst idea I've heard on internals for over a month.
> > Besides, you can do this in userland already anyway:
> >
>
> haha :) Yes, you can do many things in userland.
>
> > <?php
> > class InvalidTypeException extends Exception {}
> > class UnknownTypeException extends Exception {}
> >
> > class Types {
> > const INTEGER = 1;
> > const FLOAT = 2;
> > const STRING = 3;
> > const OBJECT = 4;
> > const BOOLEAN = 5;
> >
> > private $val, $type;
> >
> > public function __construct($val, $type) {
> > $this->type = $type;
> > $this->setValue($val);
> > }
> > public function setValue($val) {
> > switch($this->type) {
> > case self::INTEGER:
> > if (!is_int($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::FLOAT:
> > if (!is_float($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::STRING:
> > if (!is_string($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::OBJECT:
> > if (!is_object($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > case self::BOOLEAN:
> > if (!is_bool($val)) {
> > throw new InvalidTypeException;
> > }
> > break;
> >
> > default:
> > throw new UnknownTypeException;
> >
> > }
> > $this->val = $val;
> > }
> > public function getValue() {
> > return $this->val;
> > }
> > public function __toString() {
> > return (string)$this->getValue();
> > }
> > }
> >
> > class Integer extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::INTEGER);
> > }
> > }
> > class String extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::STRING);
> > }
> > }
> > class Float extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::FLOAT);
> > }
> > }
> > class Object extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::OBJECT);
> > }
> > }
> > class Boolean extends Types {
> > public function __construct($val) {
> > parent::__construct($val, Types::BOOLEAN);
> > }
> > }
> > function type_hint_integer(Integer $val) {
> > echo $val, "\n";
> > }
> > function type_hint_string(String $val) {
> > echo $val, "\n";
> > }
> > function type_hint_float(Float $val) {
> > echo $val, "\n";
> > }
> >
> >
> >
> > type_hint_integer(new Integer(123));
> > type_hint_string(new String("string"));
> > type_hint_float(new Float(0.25));
> >
>
> Nice implementation, so ? Still more code to include in your code.
> Anyways, the "Optional" part in the subject means ... optional. Which
> means that it does not *have* to be used and that the default hinting
> will still be loose.
>
> That gives the chance to anyone to use either strongly-typed code or
> loosely-typed code. You know as much as I do that it's quite easy to
> do (implement - like you just did), but if it's not in by default,
> people won't care about doing it or implementing it.
>
> On the other hand, if it's there, some people might be tempted to use
> it, and will. But hey.. php's a loosely typed language and it'll
> definitely stay that way. But only giving the choice to someone to use
> what he feels like is quite interesting in my opinion.
>
> Anyways, no need to get all grumpy, you can just say you don't like
> the idea, that'll do just as well. Anyways, that was a thought, it's
> quite easy to implement as an extension and would be light and simple
> for anyone to either use or ignore it.
>
>
> > -Hannes
> >
>
>
>
> --
> 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
