# Q on Primitives

- Thread: https://externals.io/message/42313
- Original archive: https://news-web.php.net/php.internals/42313
- Started by Nathan Rixham on 2008-12-17T22:57:34+00:00
- Messages: 18
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #42313 — Nathan Rixham — 2008-12-17T22:57:34+00:00

URL: https://externals.io/message/42313#42313

Don't want to take up much of you're time, just wondered if anybody 
could point me to the reason why some primitives aren't in php.

Would find it very very useful to have byte, short, long, float, double 
and char in php. (primarily byte and char).

while I'm here I may as well also ask about further adding type hinting 
for the existing scalars and array.

and finally different method signatures such as:

class Whatever {
   public function __construct(Bar b);
   public function __construct(Foo f);
   public function doSomething(Bar b);
   public function doSomething(Foo f);
}

Regards!

---

## #42314 — Graham Kelly — 2008-12-17T23:24:26+00:00

URL: https://externals.io/message/42313#42314 · In reply to: #42313

Hi,

I think the reason there aren't more primitive types in PHP is because of
the nature of the language. One of the main features of PHP over say, C (and
even Java), is that the memory managment is completely transparent to the
devloper. This means that it really shouldent matter to the devloper how an
integer is  implimented on the machine. Same with doubles and chars.
Granted, I can see some reasons why forcing the data to be of a specific
length or type would be handy, but I dont know if there would be a wide
enough requierment for this to actually impliment it as a language feature.
Plus, you usually can find a way around it anyway :). But basically, if your
interest in byte and char are for conserving memory then dont be worried...
PHP does a fairly good job with your memory and this wouldent actually
translate into a memory savings on the machine.

I too would love to see more type hinting :).

~Graham Kelly



> Don't want to take up much of you're time, just wondered if anybody could
> point me to the reason why some primitives aren't in php.
>
> Would find it very very useful to have byte, short, long, float, double and
> char in php. (primarily byte and char).
>
> while I'm here I may as well also ask about further adding type hinting for
> the existing scalars and array.
>
> and finally different method signatures such as:
>
> class Whatever {
>  public function __construct(Bar b);
>  public function __construct(Foo f);
>  public function doSomething(Bar b);
>  public function doSomething(Foo f);
> }
>
> Regards!

---

## #42315 — Nathan Rixham — 2008-12-18T00:02:49+00:00

URL: https://externals.io/message/42313#42315 · In reply to: #42314

Graham Kelly wrote:
> Hi,
> 
> I think the reason there aren't more primitive types in PHP is because of
> the nature of the language. One of the main features of PHP over say, C (and
> even Java), is that the memory managment is completely transparent to the
> devloper. This means that it really shouldent matter to the devloper how an
> integer is  implimented on the machine. Same with doubles and chars.
> Granted, I can see some reasons why forcing the data to be of a specific
> length or type would be handy, but I dont know if there would be a wide
> enough requierment for this to actually impliment it as a language feature.
> Plus, you usually can find a way around it anyway :). But basically, if your
> interest in byte and char are for conserving memory then dont be worried...
> PHP does a fairly good job with your memory and this wouldent actually
> translate into a memory savings on the machine.

mainly it was for the strictness and for the extra speed gained by 
having a primitive at php level, to implement using say class Byte 
(which I have done) is seriously heavy processor and memory wise for 
something so simple.. especially if you consider an implementation of 
ByteArray..

obviously there isn't much call otherwise this would have been 
implemented back at v4 or at least 5; however I for one would love to 
see this simple little bit of support added.

Would open up masses of avenues, including the ability to make some 
decent orm's for php (much easier to map "byte to byte" than "scalar 
might be a byte but is really an integer to byte" if you know what I mean.

regards!

---

## #42327 — Dave Ingram — 2008-12-18T11:59:14+00:00

URL: https://externals.io/message/42313#42327 · In reply to: #42313

Nathan Rixham wrote:
> [...]
>
> while I'm here I may as well also ask about further adding type
> hinting for the existing scalars and array.
+1, but I don't know what might have stopped it being implemented before
(time, parsing API changes, etc), so it would be interesting to look
into the history.

> and finally different method signatures such as:
>
> class Whatever {
>   public function __construct(Bar b);
>   public function __construct(Foo f);
>   public function doSomething(Bar b);
>   public function doSomething(Foo f);
> }
+1. Having overloaded function definitions like this would be very
useful, but I don't know how awkward it would be to implement - I don't
know how the function pointers are currently stored. I could imagine
adding information about the type signature to the internal method name,
and looking up based on that... but then I don't know how it's stored so
I might be talking rubbish!

Also, what about this case:

class MyTestClass {
  public function blah(Foo $f);
  public function blah(Bar $b);
  public function blah($v);
}

I would argue that the most specific function should be called, but how
costly would that be to determine? What if you have a "Baz" subclass of
Bar, but no corresponding method? What if Bar itself is a subclass of Foo?


Dave

---

## #42334 — Nathan Rixham — 2008-12-18T14:14:46+00:00

URL: https://externals.io/message/42313#42334 · In reply to: #42327

2008/12/18 Dave Ingram <dave@dmi.me.uk>

>
> Also, what about this case:
>
> class MyTestClass {
>  public function blah(Foo $f);
>  public function blah(Bar $b);
>  public function blah($v);
> }
>
> I would argue that the most specific function should be called, but how
> costly would that be to determine? What if you have a "Baz" subclass of
> Bar, but no corresponding method? What if Bar itself is a subclass of Foo?
>
>
Ideally a most specific first approach, failing that I'd suggest taking
doing it the nearest first way (like we do when catching exceptions) ?

---

## #42335 — Giorgio Sironi — 2008-12-18T19:26:12+00:00

URL: https://externals.io/message/42313#42335 · In reply to: #42327

2008/12/18 Dave Ingram <dave@dmi.me.uk>

> Nathan Rixham wrote:
> > […]
> +1, but I don't know what might have stopped it being implemented before
> (time, parsing API changes, etc), so it would be interesting to look
> into the history.
>

This is simple to achieve with
    assert('is_string($argument)');

class MyTestClass {
>  public function blah(Foo $f);
>  public function blah(Bar $b);
>  public function blah($v);
> }
>
> I would argue that the most specific function should be called, but how
> costly would that be to determine? What if you have a "Baz" subclass of
> Bar, but no corresponding method? What if Bar itself is a subclass of Foo?
>

I remember that multiple signatures was said to have a possible very
difficult implementation. However, a similar behaviour can be achieved by
some instanceof().

-- 
Giorgio Sironi
Piccolo Principe & Ossigeno Scripter
http://www.sourceforge.net/projects/ossigeno

---

## #42336 — crrodriguez@suse.de — 2008-12-18T21:25:44+00:00

URL: https://externals.io/message/42313#42336 · In reply to: #42327

Dave Ingram escribió:

> class MyTestClass {
>   public function blah(Foo $f);
>   public function blah(Bar $b);
>   public function blah($v);
> }

Looks like you are using the wrong language, you need JAVA instead.



-- 
"We have art in order not to die of the truth" - Friedrich Nietzsche

Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/

---

## #42337 — Dave Ingram — 2008-12-18T22:09:05+00:00

URL: https://externals.io/message/42313#42337 · In reply to: #42335

> I remember that multiple signatures was said to have a possible very
> difficult implementation. However, a similar behaviour can be achieved by
> some instanceof().
>   
I thought it probably would be awkward, but we do already have some type
hinting that can also be accomplished with instanceof() -- this is just
an extension of that idea. Although it's not my idea as such!


Dave

---

## #42339 — Nathan Rixham — 2008-12-18T22:22:05+00:00

URL: https://externals.io/message/42313#42339 · In reply to: #42337

Dave Ingram wrote:
> > […]
> I thought it probably would be awkward, but we do already have some type
> hinting that can also be accomplished with instanceof() -- this is just
> an extension of that idea. Although it's not my idea as such!
>
>   
instance of is handy however it isn't the cleanest; consider:

public static function parseByte( $var )
    {
        $testPassed = false;
        if( $var instanceof Number ) {
            $var = $var->byteValue();
            $testPassed = true;
        } if( $var instanceof String ) {
            $var = $var->__toString();
        }
        if( !$testPassed && is_numeric( $var ) ) {
            $var = 0 + $var;
            $testPassed = true;
        }
        if( $testPassed && Byte::MIN_VALUE <= $var && Byte::MAX_VALUE >= 
$var ) {
            return $var;
        }
        throw new NumberFormatException();
    }

could be:

public static function parseByte( Number $var )
    {
        return $var->byteValue();
    }

public static function parseByte( String $var )
    {
        if( is_numeric( $var = $var->__toString() ) ) {
          $var = 0 + $var;
          if( Byte::MIN_VALUE <= $var && Byte::MAX_VALUE >= $var ) {
            return $var;
          }
        }
        throw new NumberFormatException();
    }

mini-use-case but shows how useful it would be..

---

## #42342 — Kalle Sommer Nielsen — 2008-12-19T02:23:26+00:00

URL: https://externals.io/message/42313#42342

2008/12/18 Nathan Rixham <nrixham@gmail.com>:
> Nathan Rixham wrote:
>
> and strongly typed returns.. nearly forgot
>
> public static function parseByte( Number $var ):bool {
> or
> public static function bool parseByte( Number $var ) {
>
> or such like
>

Theres already an RFC for this:
http://wiki.php.net/rfc/typehint




-- 
Kalle Sommer Nielsen

---

## #42345 — Robin Burchell — 2008-12-19T13:38:36+00:00

URL: https://externals.io/message/42313#42345 · In reply to: #42342

Just a random thought I have from reading over that:

Would it not be more 'natural' to change 'function' to indicate a
method with a variant return type, and allow e.g.

'int somefunc()' instead of 'function (int) somefunc()' to indicate an
int return?

It would be a bit more in fitting with traditional languages, and
definitely less typing.. it may require some parser modification,
though..?

(I'd also like to throw my +1 in for scalar type hints, and optional
type coercion for return values - this is something I have run into
annoyances with and blogged about in the past)

Thanks,
Robin Burchell


> 2008/12/18 Nathan Rixham <nrixham@gmail.com>:
> > […]
>
> Theres already an RFC for this:
> http://wiki.php.net/rfc/typehint
>
>
>
>
> --
> Kalle Sommer Nielsen

---

## #42346 — Nathan Rixham — 2008-12-19T14:31:40+00:00

URL: https://externals.io/message/42313#42346 · In reply to: #42345

Robin Burchell wrote:
> Just a random thought I have from reading over that:
> 
> Would it not be more 'natural' to change 'function' to indicate a
> method with a variant return type, and allow e.g.
> 
> 'int somefunc()' instead of 'function (int) somefunc()' to indicate an
> int return?
> 

it would break all php code existing so far; the only real way to 
implement return value types would be as such

public static function somefunc():int {

this would allow the return type to be optional and leave all existing 
code functional; likewise it could be implemented for any style of 
php'ing, thus:

#php4 style class method or normal procedural function
function dosumit():int {

type hints are all ready there so adding primitives /should/ be possible 
without any bc issues

---

## #42348 — Robin Burchell — 2008-12-19T14:37:44+00:00

URL: https://externals.io/message/42313#42348 · In reply to: #42346

Hmm. How would it break it?

By leaving 'function' to mean variant, it's only adding new
functionality by overriding types to replace 'function', which should
have no issue with older code, surely?

To clarify:

current method declaration:
function foo()
public static function foo()
public function foo()

.. and so on

new method declaration could stay the same, if the author didn't care
about return type, or:
int foo()
public int foo()

.. etc.

The only possible issue I can see is where e.g. there is a class named
'static', which, IIRC is already impossible.

If I'm missing something, please let me know :)


> Robin Burchell wrote:
> > […]
>
> it would break all php code existing so far; the only real way to implement
> return value types would be as such
>
> public static function somefunc():int {
>
> this would allow the return type to be optional and leave all existing code
> functional; likewise it could be implemented for any style of php'ing, thus:
>
> #php4 style class method or normal procedural function
> function dosumit():int {
>
> type hints are all ready there so adding primitives /should/ be possible
> without any bc issues

---

## #42349 — troels knak-nielsen — 2008-12-19T14:40:39+00:00

URL: https://externals.io/message/42313#42349 · In reply to: #42346

> type hints are all ready there so adding primitives /should/ be possible
> without any bc issues

PHP is loosely typed. Adding typehints to primitives would change
this. The only reason that it is working with object types, is because
you can't automatically coerce object types anyway.

--
troels

---

## #42350 — Robin Burchell — 2008-12-19T14:50:40+00:00

URL: https://externals.io/message/42313#42350 · In reply to: #42349

> PHP is loosely typed. Adding typehints to primitives would change
> this. The only reason that it is working with object types, is because
> you can't automatically coerce object types anyway.
>
> --
> troels

I'm not sure what you are getting at here, really: the suggested
functionality is optional, and a new addition mean that it indeed will
not have an effect on backwards compatibility. What was the purpose of
your mail?

I cannot furthermore see why providing the choice for people to
strong-type when it suits their purposes as well as allowing weak
typing when useful is such a bad thing. Indeed, I'd quite love for
this mixture :)

I agree that typing *can* be accomplished in other ways, e.g.
instanceof and various other hacks, but they are then not enforcing it
in a uniform and controlled manner as type hinting does, plus they are
less elegant than providing it as an optional first class language
feature.

---

## #42351 — Nathan Rixham — 2008-12-19T15:09:40+00:00

URL: https://externals.io/message/42313#42351 · In reply to: #42348

Robin Burchell wrote:
> Hmm. How would it break it?
>
> By leaving 'function' to mean variant, it's only adding new
> functionality by overriding types to replace 'function', which should
> have no issue with older code, surely?
>
> To clarify:
>
> current method declaration:
> function foo()
> public static function foo()
> public function foo()
>
>   
because all of those current declarations would no longer work on the 
new version of php which implemented such change..? and I'm assuming it 
would be a much bigger change to the php internals than adding in an 
optional type after the method params..?

I do like the "type method()" syntax though, but don't think it's a php 
thing..?

---

## #42352 — Robin Burchell — 2008-12-19T15:39:27+00:00

URL: https://externals.io/message/42313#42352

Ugh. Apparantly I forgot to CC the list on those last two mails..
Sorry. Pasted so others stay in on the conversation:


> <snip>
That's an interesting mail, expresses a viewpoint I hadn't considered,
so, thanks for that.

However: If PHP provides such a set in stone opinion on how things
should be done, then why does it support, for example, provide class
vs functional programming paradigms - both to a first degree level?
(the mysqli extension is a very good example of what I mean here).

As I have seen it, PHP is one of the best of all tools: it provides
the features that many different programmers wish to use, and allows
them to use it. It doesn't restrict itself to any single spectrum of
programming, and I think that robustness is one reason it has
flourished, and continues to do so well into the future.

I see this as just another logical extension of that philosophy: you
see this as being "not the PHP way", whilst I see it as the polar
opposite: enabling programmers to do things as they wish, which I have
always thought was very much the PHP way :)


------------




> because all of those current declarations would no longer work on the new
> version of php which implemented such change..? and I'm assuming it would be
> a much bigger change to the php internals than adding in an optional type
> after the method params..?

They would continue to work, because (you seem to be missing this
point of what I am suggesting) - 'function' would just mean a return
of a variant type (i.e. the current behaviour of not caring what it
is, and not touching it in any way

Whether or not it is a large change I am not qualified to suggest; I
haven't yet done too extensive a digging into the internals.

---

## #42353 — Ionut Gabriel Stan — 2008-12-19T15:50:06+00:00

URL: https://externals.io/message/42313#42353 · In reply to: #42352

> Ugh. Apparantly I forgot to CC the list on those last two mails..
> Sorry. Pasted so others stay in on the conversation:
>
> 
> > […]
> That's an interesting mail, expresses a viewpoint I hadn't considered,
> so, thanks for that.
>
> However: If PHP provides such a set in stone opinion on how things
> should be done, then why does it support, for example, provide class
> vs functional programming paradigms - both to a first degree level?
> (the mysqli extension is a very good example of what I mean here).
>
> As I have seen it, PHP is one of the best of all tools: it provides
> the features that many different programmers wish to use, and allows
> them to use it. It doesn't restrict itself to any single spectrum of
> programming, and I think that robustness is one reason it has
> flourished, and continues to do so well into the future.
>
> I see this as just another logical extension of that philosophy: you
> see this as being "not the PHP way", whilst I see it as the polar
> opposite: enabling programmers to do things as they wish, which I have
> always thought was very much the PHP way :)
>
>
> ------------
>
>
>
> 
> > […]
>
> They would continue to work, because (you seem to be missing this
> point of what I am suggesting) - 'function' would just mean a return
> of a variant type (i.e. the current behaviour of not caring what it
> is, and not touching it in any way
>
> Whether or not it is a large change I am not qualified to suggest; I
> haven't yet done too extensive a digging into the internals.
>

Actually functional programming [1] is a different beast than what you
are referring to, which is called procedural programming [2]. In that
regard, a database interface like mysqli is hardly functional.

Sorry if I've hijacked the discussion somehow.


[1] http://en.wikipedia.org/wiki/Functional_programming
[2] http://en.wikipedia.org/wiki/Procedural_programming