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

[448191]

Class mapping relies on class naming convention. Using PEAR naming convention, CLASS_PREFIX might be "Foo_Storage_", and "Foo_Storage_MySql" and siblings would indeed share an interface. Indeed it would be better to check against an upper bound type, but as you may notice the example would not even run and shouldn't be considered much more than pseudo code.

 

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

 

This requires some clarification. Commenting out things? More control by using an enum? First things that spring to mind are "why/what" and "how so" respectively, but maybe if you elaborate I will see your point.

 

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

 

I honestly don't see the point in this. Maybe a code example would help?

[corbin]

In response to

 

 

$myvar1 = 'foo';

$myvar2 = null;

 

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

 

 

What would $myvar2 be expected to put there?  Have you ever echo'd null before?  It's nothing....  Hence, that wouldn't make sense for a MySQL query.  Class wrappers for primitives aren't needed to avoid that, in my opinion.

 

 

 

Or, maybe you copied that from the book.  Don't know if that was your thought or theirs.

[alexweber15]

Replying to corbin:

 

In response to

 

 

$myvar1 = 'foo';

$myvar2 = null;

 

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

 

 

What would $myvar2 be expected to put there?  Have you ever echo'd null before?  It's nothing....  Hence, that wouldn't make sense for a MySQL query.  Class wrappers for primitives aren't needed to avoid that, in my opinion.

 

 

 

Or, maybe you copied that from the book.  Don't know if that was your thought or theirs.

 

corbin, i copied my reply to a specific question posted in a google/usenet group (when i offered my solution - and in general on here too - i try to maintain as much of the original code as possible, so as not to confuse the person who asked the question) heres the link to the thread fyi: link

 

and yes i know that echoing null is nothing.  but you're missing the bigger picture.  assume a scenario:

 

a form with 3 required fields and 1 optional field:

(and a corresponding database table with the optional field set to allow NULL values)

 

- when POSTed the optional field will evaluate to an empty string (in the case of a text field for example)

- the user then adds all POST values directly into the database

 

= the optional database field will contain an empty string instead of NULL.

 

 

I agree that there are MANY flaws in this situation, but like i said, i usually try to solve problems in existing code, not rewrite the other person's code.

 

- first of all input should be validated and

- more importantly, if a NULL value is part of the data to be inserted then you should just omit it from the statement in the first place

 

so if after extracting POST you have:

// assume these are the variables that extract($_POST) creates
$myvar1 = 'foo';
$myvar2 = null;

$query = "INSERT INTO mytable (col1) VALUES ('$myvar1')";
// no need to insert the null value

 

as for Class Wrappers for primitive values, i agree that in this case its useless because its better to just avoid inserting the value in the first place like my above example

 

BUT, as i mentioned in the disclaimer i was merely quoting/translating ad-verbatim from a recent programming book.  i don't necessarily endorse any of this.  just thought i'd share.

[alexweber15]

(split the last 2 posts directed at me into individual replies to each author)

 

Replying to 448191:

 

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

 

This requires some clarification. Commenting out things? More control by using an enum? First things that spring to mind are "why/what" and "how so" respectively, but maybe if you elaborate I will see your point.

 

Ok you have a simple factory that relies on Constants to determine what Objects it can instantiate, ok?

Let's get creative:  It's an online bookstore that uses a SimpleBookFactory to creates FictionBook, NonFictionBook and ChildrenBook objects.  (dont get hung up on the mundane details of the example names, yes i realize children books would probably be filed under fiction )

ok?

Now, god forbid, imagine that the bookstore is forbidden from selling FictionBooks or author's strike or supply runs out or whatever but the bottom line is: the factory should no longer be allowed to instantiate FictionBook objects.

 

ok so we have to change something...

According to your example (whether or not its pseudocode), using the CLASS_PREFIX method, unless you actually deleted or renamed the FictionBook class file, you would have to implement additional checks to make sure that you in fact can't instantiate any FictionBooks.

 

According to my example, the BookFactory relies on a BookTypes enumeration which has the 3 aforementioned book types as constants to aid the constructor.  So to prevent FictionBook instantiation you could just open the BookTypes enumeration and comment out the line where the FictionBook const is defined.  So when BookFactory instantiates an object its now not even aware of the existence of FictionBooks because the constant 'no longer exists'.

 

Finally, traditionally SimpleFactories use constants to determine what Objects it can create.

And these are also traditionally hard-coded into the Factory class.

 

I suggested that by removing the constants mentioned in the above class from the Factory class to a new enumeration class, you would adhere a bit more strictly to the open-closed principle, seeing as there would be no reason to ever edit the SimpleFactory class.  (you could even tarball it!)

One could argue that this merely transfers the "open-closed principle flaw" from the SimpleFactory class to the enumeration class.  No arguments there.  But I personally feel that:

 

1) this particular principle is a bit too utopic for most cases

2) its 'safer' and even 'more elegant' to, if you must edit a class mid-production for whatever reason, edit an enumeration rather than a factory.  based on the relative complexity and responsibility of each class.

 

My bad if i was vague before, maybe you still think I'm terribly wrong, but did I get my point across better now?

 

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

 

I honestly don't see the point in this. Maybe a code example would help?

 

The fact that I said "it wouldn't really make any tangible difference" agrees that there is little point to this!

and as i tried to whip out an example of moving the implements declaration to the enumeration class rather than the base class i realized its flawed and a dumb idea so scratch that.

 

const __default is still convenient, though! 

 

[corbin]

Just of curiosity, what would the advantages of class wrappers for primitive types be?  I don't see an upside.  In a strict language I see the use (I <3 the prim wrappers in Java), but in PHP, why bother?

[keeB]

To be more like Java of course!

 

[448191]

According to your example (whether or not its pseudocode), using the CLASS_PREFIX method, unless you actually deleted or renamed the FictionBook class file, you would have to implement additional checks to make sure that you in fact can't instantiate any FictionBooks.

 

True. And this is a good thing. If, per your example, the reason for restricting construction of a certain type would be out of stock or otherwise temporarily unavailable, a check should be made for this. Likely this is a possible recurring event, and in your scenario, you would have to "hack" the code each time such an event occurs. If it's not recurring, delete the class or mark it as obsolete, throwing an exception upon construction. This keeps the restriction with the subject, not the Factory.

[alexweber15]

Just of curiosity, what would the advantages of class wrappers for primitive types be?  I don't see an upside.  In a strict language I see the use (I <3 the prim wrappers in Java), but in PHP, why bother?

 

only reason I can come up with off the top of my head is for Type Hinting and (if they implement it) specifying return values for functions.

 

(as far as i know both of these features can only be enforced upon Objects, hence the current state of type hinting; which supports only Objects and arrays - which are treated like primitives but are actually objects if i recall correctly) 

 

disclaimer: sometimes i mix up Java theory though...      and on that note, big props for PHP for actually making strings a primitive type and abolishing the char type 

[alexweber15]

According to your example (whether or not its pseudocode), using the CLASS_PREFIX method, unless you actually deleted or renamed the FictionBook class file, you would have to implement additional checks to make sure that you in fact can't instantiate any FictionBooks.

 

True. And this is a good thing. If, per your example, the reason for restricting construction of a certain type would be out of stock or otherwise temporarily unavailable, a check should be made for this. Likely this is a possible recurring event, and in your scenario, you would have to "hack" the code each time such an event occurs. If it's not recurring, delete the class or mark it as obsolete, throwing an exception upon construction. This keeps the restriction with the subject, not the Factory.

 

good point, hadn't seen that angle (i was just thinking in the "normal" scenario with all products available, that eliminating the need for additional checks would reduce code size, that kinda stuff).

 

but all in all, i stand corrected!  i like your method better