all for adding function return values in PHP6 say "yay"

[alexweber15]

yet another rant about certain PHP inconsistencies that have been bugging me lately.

 

i realize that if i'm looking for a strongly-typed language (which im not) then PHP is not for me but consider this:

 

Type-Hinting was recently introduced right?  (ok its limited to arrays and objects but still it exists)

and its optional, so if you dont know about it or dont use it thats fine.

 

1) So why not take the next step and introduce function return values? (after presumably implementing type-hinting at for all types, excluding maybe pseudo-types)

 

it would be optional so again, if you dont know about it or chose not to use it thats fine, it would be just like today.

 

but it sure would make writing interfaces and programming by contract so much easier in my opinion...

 

2) oh and for the record, if no return statement is specified or if its just "return;" then null is returned right?

 

*puts on flame suit*

[DarkWater]

You could always just verify with like, is_int() and stuff.  Having strongly typed functions would completely break the loosely typed PHP as we know it. >_<

[keeB]

2) oh and for the record, if no return statement is specified or if its just "return;" then null is returned right?

 

*puts on flame suit*

 

Nothing is returned in either cases, yes.

 

So why not take the next step and introduce function return values? (after presumably implementing type-hinting at for all types, excluding maybe pseudo-types)

 

The argument (that I've heard) is it's better left to documentation since there isn't compilation in to bytecode. Strongly-typed languages rely on there being a 'compile' time. Imagine having to go through 'compile time' every time a script loads. That doesn't make much sense, does it?

[trq]

The argument (that I've heard) is it's better left to documentation since there isn't compilation in to bytecode.

 

Ah, but php6 will be I believe.

[keeB]

If it's similar to Python's then that's still not enough to implement this type of thing.

[trq]

If it's similar to Python's then that's still not enough to implement this type of thing.

 

Yeah, it will be similar to Pythons.

[genericnumber1]

From what I saw I thought they were already including type-hinted return values in php6?

[discomatt]

I'm not entirely sure why you'd want to type hint function return values... It wouldn't do any more than a comment above the function noting the return type. If anything, I like that a function I design could return an array or string, depending on the parameters I give it.

[alexweber15]

interesting reply KeeB I hadn't considered the compilation factor...

 

From what I saw I thought they were already including type-hinted return values in php6?

 

great news!  any links?

 

I'm not entirely sure why you'd want to type hint function return values... It wouldn't do any more than a comment above the function noting the return type. If anything, I like that a function I design could return an array or string, depending on the parameters I give it.

 

regarding not wanting to specify a return value that's what i meant by making it optional!!  if you dont want to use it then dont!   (also you could just specify "mixed" which if im not mistaken basically accepts any kind of type and pseudo-type (someone please correct me if im wrong)

 

as for why?  basically: programming/design by contract

 

i usually comment expected return values in interface method signatures but then i'd have to go and enforce this in the method's return value.

similarly to type-hinting, this is a powerful yet optional feature that can help produce more robust code and eliminate the need for so much type checking...

[genericnumber1]

From what I saw I thought they were already including type-hinted return values in php6?

 

great news!  any links?

 

http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values

[alexweber15]

thank you sir!

[DarkWater]

Based on those meeting notes, they will only support return types for objects.

[alexweber15]

Based on those meeting notes, they will only support return types for objects.

 

That's cool with me

 

I searched the meeting notes and couldn't find anything about it (except that classes won't be able to cast to primitive types) but I read elsewhere (and i'm not sure if this is contradictory or not but i dont think so) that they would also introduce Class Wrappers for primitive types (identical to what Java's been doing for years) so that's even cooler with me

 

And ENUMS too... boy PHP6 is sure become more java-like

 

as long as we dont have to compile anything and can still use all the loosely-typed goodness i'm happy with it (although sometimes its good to have features that other more strongly-typed lanaguages have)

[DarkWater]

Oh, really?  Enums are quite handy.  I bet it'll be a construct similar to arrays:

 

$enum = enum('red', 'blue', 'green');

[genericnumber1]

Oo I didn't see enums, I've been hankering for that for a long time. Hopefully they're pretty flexible.

[alexweber15]

Oh, really?  Enums are quite handy.  I bet it'll be a construct similar to arrays:

 

$enum = enum('red', 'blue', 'green');

 

After a bit of digging I found my source!

 

Translating from portuguese from the book "PHP Profissional", 1st published in 1997 and apparently revised or reprinted in 2008: (i apologize in advance for any poor english here I'm pretty much translating word-by-word with little regard to context):

 

A feature that's been promised for PHP6 (or even for a future 5.x build) is support for the concept of "Enumerations", which basically allow you to work with class constants in a more efficient way.

 

Another feature that's been promised for PHP6 are Object Wrappers for primitive types (similar to Java), making it easier to work with databases, since the best way to insert a value of NULL into a database is to insert an Object that represents NULL, as opposed to the primitive value itself.

 

This will all be made possible with the introduction of the class splType, which will be abstract and provide basic methods to achieve the aforementioned wrapper functionality.

 

He made an interesting point regarding storing NULL values in a database and this actually came up in a discussion today (on usenet: comp.lang.php):

 

Inserting the primitive type NULL into a mysql database can sometimes (maybe always im not sure) end up being stored as a blank string. 

* The correct implementation would be to actually NOT pass the PHP variable and to instead just pass the MySQL datatype NULL instead (notice the second parameter passed):

 

$myvar1 = 'foo';
$myvar2 = null;

$query = "INSERT INTO mytable (col1,col2) VALUES ('$myvar1', null)";

 

This actually works well, but in order to avoid depending on database-specific implementations I suppose passing a "NULL Object Wrapper" (SplNull?) would be a more versatile and future-proof alternative.

 

As far as ENUMs go, much to DarkWater's disappointment, the author gives the following code example of a PHP Enumeration (sic):

 

class WeekDays extends SplEnum{
    const Sunday = 0, Monday = 1, Tuesday = 2;
    const Wednesday = 3, Thursday = 4, Friday = 5;
    const Saturday = 6;
    const __default = WeekDays::Monday;
}

$dayObject = new WeekDays(WeekDays::Sunday);
// check if the created object corresponds to an existing constant
foreach(WeekDays::getConstList() as $key => $val){
    echo $key . ": " . ($dayObject == $val ? "yes" : "no");
}

 

Some more observations:

- notice the "const __default" feature

- notice the static method getConstList() which doesn't yet exist (according to the definition of get_defined_constants() it only works for constants defined by, you guessed it, define() but the top-most comment in the documentation suggests a workaround to get this working inside the Class Scope

 

and a BONUS for everyone: apparently if you do some scavenging you'll find that quite a few of the PHP6 or future PHP5 features are already listed in the API (albeit with scarce if any documentation): for example: SplTypes seems to have already been defined, along with SplFloat, SplBool, SplInt and, wait for it, SplEnum!   (no mention of SplNull though....)

 

*phew!* wow this post alone is worthy of its own thread lol, shame its hidden so deep in the middle of this thread 

 

*DISCLAIMER*

I'm merely translating directly from a PHP Book mentioned above and guarantee absolutely none of the quoted material so don't go flaming me if they implement it differently! 

[DarkWater]

Verrrry interesting.  Hopefully enums in PHP are as useful as I hope for them to be.

[keeB]

How do you plan to use them?

 

I don't see them as useful at all.

[Zane]

I guess it could be a little bit useful if they could just extend off of the is_object function to include a class name

for instance

 

Is Object of ClassName

is_object("ClassName", $var);

but really I'm sure there's already a work around for that anyway now, and the lack of type specifiers for functions hasn't really halted many projects as far as I can see.

[448191]

I don't see enums as all that useful either. Too often developers forget the enumeration itself needs to be constant, not just the enumerators. And how often does that really happen? Days in a week, months in a year, seasons in year, suits in a deck of cards? Not too much extra value IMO. SplEnum is even more useless, as it's not type safe.

 

PHP6 is definitely continuing the trend of moving towards Java.

[genericnumber1]

I don't see enums as all that useful either. Too often developers forget the enumeration itself needs to be constant, not just the enumerators. And how often does that really happen? Days in a week, months in a year, seasons in year, suits in a deck of cards? Not too much extra value IMO. SplEnum is even more useless, as it's not type safe.

 

PHP6 is definitely continuing the trend of moving towards Java.

 

other languages have enums too

[discomatt]

 

other languages have enums too

 

I don't think he was using enums as the only factor in his conclusion.

[alexweber15]

How do you plan to use them?

 

I don't see them as useful at all.

 

frankly, I'm personally disappointed regarding the alleged implementation I posted earlier (that's pretty much exactly what I do without the extends part and without the __default value)

 

 

I guess it could be a little bit useful if they could just extend off of the is_object function to include a class name

for instance

 

Is Object of ClassName

is_object("ClassName", $var);

but really I'm sure there's already a work around for that anyway now, and the lack of type specifiers for functions hasn't really halted many projects as far as I can see.

 

If I understand what you mean... it would be so much simpler if PHP used the same concept as Java (all objects inherit from a base 'object class', in this case StdClass) but this is not the case (and if it happens all the anti-strongly-typed PHPers might collectively commit suicide)

 

But come to think of it why don't you just use instanceof ?  (it allows both ClassNames, $variables and "strings") ^{lol at the stupid decoration used for each word}

 

if($var instanceof MyClass) { .. }

 

I don't see enums as all that useful either. Too often developers forget the enumeration itself needs to be constant, not just the enumerators. And how often does that really happen? Days in a week, months in a year, seasons in year, suits in a deck of cards? Not too much extra value IMO. SplEnum is even more useless, as it's not type safe.

 

ENUMS can be useful for a lot of things in my opinion.  For example in implementing SimpleFactories (instead of hard-coding the constants in the factory class you could reference an external Enum Class, preserving the open-closed principle for that particular factory class)

 

In my personal experience I've emulated ENUM functionality for possible Storage Types (again a factory context, for example have the following constants "XML", "JSON", "YAML" and "MySQL")

 

Hmmmm what else... well I guess mainly for factories and there's workarounds such as strict Type-Hinting or verification (instanceof) that also work.  I personally find ENUMs more elegant and the fact that you can have a separate Class with constants for factories is a plus because it reduces the probability of having to change the actual factory class every time you want to add a new 'product' (assuming the Enumerated types represent objects that implement a common interface or extend from the same base class - which is kind of implicit anyways in this context)

 

ok im rambling.  time to stop!

 

Alex

[448191]

In my personal experience I've emulated ENUM functionality for possible Storage Types (again a factory context, for example have the following constants "XML", "JSON", "YAML" and "MySQL") ... it reduces the probability of having to change the actual factory class every time you want to add a new 'product' (assuming the Enumerated types represent objects that implement a common interface or extend from the same base class - which is kind of implicit anyways in this context)

 

*buzzz*

 

This is exactly what I mean by "developers forget the enumeration itself needs to be constant". Doing something like this means you have to go in change the enum if you want to add a storage type. If indeed the interface is consistent among the Factory's subjects, why create a dependency on an enum, when some simple class name mapping would be all a factory needs?

 

eg.

 

public static function storageFactory($name)
{
    $className = self::CLASS_PREFIX . $name;

    if(!class_exists(className)
    {
          throw new RuntimeException('Class ' . $className . ' not found');
    }

    return new $className($whatever);
}

 

 

other languages have enums too

 

I don't think he was using enums as the only factor in his conclusion.

 

Indeed I did not. In fact enums in this way are very different from enums in Java.

[alexweber15]

448191,

 

If indeed the interface is consistent among the Factory's subjects, why create a dependency on an enum, when some simple class name mapping would be all a factory needs?

 

Duly noted on your observation, but I might have a counter-argument depending on a clarification in your code:

 

public static function storageFactory($name)
{
    $className = self::CLASS_PREFIX . $name;

    if(!class_exists(className)
    {
          throw new RuntimeException('Class ' . $className . ' not found');
    }

    return new $className($whatever);
}

 

The main point in my example of using enums for factories was not having to change the base class.  (which your example addresses perfectly).

 

Now another issue is control over what classes are allowed to be constructed...

- In your example you allow any class with the prefix "storageFactory" to be instantiated.

- I won't insult your intelligence (after all you have 10 more stars over your username than I do  ) so I'll assume that all classes with the prefix "storageFactory" would extend or implement a common class.

 

My argument for enums is that you could achieve control over class instantiation by for example commenting out constant declarations.

Also, due to its class structure, you could (although it wouldn't really make any tangible difference) specify the inheritance/implementation directly in the enum's declaration (since it appears to have standard class notation).... and having "const __default" is also nice

 

but either way, my "counter-arguments" have the intent of discussing possible alternatives to your solution, as opposed to of criticizing it or pointing out flaws/replacing it.

 

PS - at the risk of sounding dorky, I have to admit that I'm actually really enjoying reading and commenting this thread