| SitePoint Sponsor |
I disagree.No it doesn't. Presumably they would be static methods in the class, so they are just as much in the global namespace as a function.
Static methods might be in the global scope, but they do not share the global namespace.
No namespace collisions...Code:class Test{ function doSomething(); } function doSomething();
Cheers,
Alex
The only constant in software is change itself
And how exactly is doSomething() static...Originally Posted by PCSpectra
I disagree.
Static methods might be in the global scope, but they do not share the global namespace.
No namespace collisions...Code:class Test{ function doSomething(); } function doSomething();
Cheers,
Alex
Creativity knows no other restraint than the
confines of a small mind. - Me
Geekly Humor
Oh baby! Check out the design patterns on that framework!
Well that is THE number one benefit of Sotware Architecture. If you work alone or on a small project it may not matter so much but when working with a corporate team on a big project organization does matter or it will become a mess.
Except that your function doesn't check that something is empty. empty will return false on an unset variable, your custom isempty will trigger a warning. So really - what your function is doing is to cast the variable to a boolean and then negate it. It is exactly the same as sticking a ! in front of whatever you're checking. I fail to see how wrapping not in a non-standard replacement improves readability.
I personally dislike the use of if($var) and if(!$var) for variable types other than boolean. I find it's too ambiguous. If you jump into a project and are trying to hunt down a bug, running across a line like if(!$list) probably will mean nothing to you. It could mean if the array $list is empty or if the filename pointing to a list, $list, is an empty string or if the integer length, $list, of the list is 0 or if we should provide a list, as indicated by the boolean $list... and so on.
I like Stormrider's idea of isempty(), although it obviously is not a valid replacement for empty(). I frequently have sections of code like this:
I also use two functions, issetor() and emptyor(), which provide a quicker way to write isset($var) ? $var : $string. These also don't handle unset variables quite right. The variables are passed by reference, which will set the variables to null or an empty string or something if they're not set. (I can't remember how exactly, but they set the unset.) This is documented, though, and I just live with it. Now I'm thinking about adding an isemptyor().PHP Code:$var = $something->returnSomething(); // argh@empty
if(!empty($var))
{
// ...
In response to the original question, I sort of do both, but there's normally a semi-valid reason to create the class (like the Response class that houses redirect(), etc.).
If if(!$var) doesn't mean anything to you, I would suggest revisiting the documentation because its meaning should have no ambiguity.I personally dislike the use of if($var) and if(!$var) for variable types other than boolean. I find it's too ambiguous. If you jump into a project and are trying to hunt down a bug, running across a line like if(!$list) probably will mean nothing to you. It could mean if the array $list is empty or if the filename pointing to a list, $list, is an empty string or if the integer length, $list, of the list is 0 or if we should provide a list, as indicated by the boolean $list... and so on.
I like Stormrider's idea of isempty(), although it obviously is not a valid replacement for empty(). I frequently have sections of code like this:
I also use two functions, issetor() and emptyor(), which provide a quicker way to write isset($var) ? $var : $string. These also don't handle unset variables quite right. The variables are passed by reference, which will set the variables to null or an empty string or something if they're not set. (I can't remember how exactly, but they set the unset.) This is documented, though, and I just live with it. Now I'm thinking about adding an isemptyor().PHP Code:$var = $something->returnSomething(); // argh@empty
if(!empty($var))
{
// ...
In response to the original question, I sort of do both, but there's normally a semi-valid reason to create the class (like the Response class that houses redirect(), etc.).
Creativity knows no other restraint than the
confines of a small mind. - Me
Geekly Humor
Oh baby! Check out the design patterns on that framework!
Right. If you read the documentation, you'll know that if the method or function returns either the integer 0, an empty string '', or the boolean false, a ! negate this into the boolean value true.
You're right: ! $var and ! functioncall should mean something to every php developer. The only problem with using ! is that it can mean that the function returned on of the things noted above. For example: preg_match may return false when complication of your regular expression has failed, for example because you forgot to preg_quote a value.
It may also return 0, as in "no matches". Using only the !, you will not know which of the situations have occured. In short, using the "!" to typejuggle to a boolean and negating it isn't something you shouldn't use, but if you do use it, you'll have to be aware of the possible return values from the method you've called or the content of the variable.
Or, that's what I think
So don't create functions that can return mixed types. Its a bad design, if your function can both return an empty string and a boolean. Notwithstanding that the core php api contains plenty of examples of this. In those cases, I would explicitly check on the type (strict comparison).
Bad example. preg_match will raise a warning in that case.
Well, I surely wouldn't create a function that behaves that way, nor do I see the need to create a function with that behaviour.
My point exactly: it's not my functions I'm worried about, it's those that are written by others (in some cases, functions from the php core). It's just that I disagree with the comment by imaginethis, because using a ! to negate can result in things you might not expect.
That brings me to my conclusion: usage of negating a boolean on a non-boolean is not a bad thing, per se, but you should be aware the functions' possible return values before using it blindly as it may result in some hard to trace bugs.
I knew I would get comments on that. It's the first function that came up in my mind without checking the manual
Surely. But inventing nonstandard functions such as isempty, is a really bad idea. It's bound to cause confusion for any php developer that reads it. On the other hand, you should safely be able to assume that a php developer knows the difference between == and ===, since that's part of the language.
strpos is a classic. You can deal with this by using strict comparison. No need to reinvent basic language features for that.I knew I would get comments on that. It's the first function that came up in my mind without checking the manual
I think you can reduce all this to: If you're interested in the value of a function, check for the value - If you're interested in the type of the value, check on that. Most of the time, the latter doesn't matter, since this is a loosely typed language, but if you need it, that's exactly why strict comparison is there.
Obviously. Introducing a function which introduces confusion, but no added benefit would go under "really bad idea" in my book
We're on the same page here. The only reason I replied was that I simply wanted to point out that using the "!" on a function which may return multiple different types might cause bugs.
Ah, that's a much better example.
I agree with you on this point. In some language like Java, purety of Object paragdim has become so extreme that everything has to be boxed into a class whereas there maybe no need to do so.
Well on this point, I may not totally agree: pollution is a problem when you cope with a group of people you may not even know. The access to the Global Name Space should be protected that is accessible only when you explicitely declare it to be so or even more harshly controlled by some adminitrative rights. In Rebol there is some feature like that. I would like PHP to be able to do so also and not become completely objectized like in Java.
Eh? The symbol has global scope. There is a different scope for floating functions and for classes, but they are both global.
No, because they are in different scopes.No namespace collisions...
No collision there either, but that's besides the point.PHP Code:$foo = 42;
function foo() {
}
defined('foo', 42);
class Foo {}
The problem of nameclash is that developer A might choose the same symbol as developer B, but to mean different things. If there is just one global scope to declare symbols in, the only way to prevent it, is by picking a unique name. With static methods, the full name consists of the classname + the method name, while for floating functions the full name is just the name of the function. So let's calculate the uniqueness of your example:
For a floating function, you could get the same level of uniqueness, using a name with the same number of characters:Code:class Test{ function doSomething(); } strlen("Test") + strlen("doSomething") => 15
(OK, the underscore means we're off by one, but that's a bit irrelevant to the point).Code:function Test_doSomething() {}
Namespaces are something different from adding uniqueness to names. It's a mechanism that allows code to use local scope for static symbols, without the risk of colliding with other code that may use the same names. The thing that makes namespaces practical, is that you can import the namespace into your current scope. So instead of having to write the full name, you can use the local name. Classes don't give you this; To address your function above, you must use the full name Test::doSomething(). In that sense, it doesn't add anything over using Test_doSomething().
I think we have a different understanding of what is meant by 'namespace'.Eh? The symbol has global scope. There is a different scope for floating functions and for classes, but they are both global.
While a static method is globally accessible, you must provide the class context, like so:
From the wiki:Code:MyClass:doSomething();
Class provides 'context' and while literally (as of PHP 5.3???) they are not 'namespaces' technically they both (namespace and class) provide a context to whatever methods and/or members they encapsulate.In general, a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces).
Scope is the level of visibility to which an variable/function is made available. So like I said, a static method might be globally available but you MUST prefix it with the context/namespace of the class which encapsulates it so it does not collide with global namespace.No, because they are in different scopes.
I realize there is a difference between a class and a namespace but the term 'namespace' does not nessecarily mean 'namespace' as PHP understands it.
Cheers,
Alex
The only constant in software is change itself
I know perfectly fine what if(!$var) does. The problem is that it can be evaluated as true under several sets of circumstances. In what way is that not ambiguous?
Granted, empty() returns true under a variety of circumstances too, but who uses empty() to test if a known boolean is true or false? I find that using if(!$var) for booleans and if(empty($var)) for other data types reduces confusion substantially.
Yes, but what's the difference between foo_bar() and Foo::bar() in terms of uniqueness? The chance of two developers picking the same classname or the same function prefix, is the same.
Yes it does. Foo::bar() doesn't collide with bar(), but that's comparing apples to oranges. Foo::bar() is still global - If you make a class Foo and I make a class Foo, we would have a collision.
I personally agree with you. For me, ! is strictly for converting booleans. Don't know why, that's just the way I am.
That's why I'd prefer to use:
OverPHP Code:if(count($Array) < 1){
ButPHP Code:if(!$Array){
Makes perfect sense.PHP Code:if(!$Bool){
I think the reason is that I also use alot of Java and C#, which is strict when it comes to typing; I like to keep consistent throughout all of my programming.
Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
You would have a collision either way regardless of any method in either class being declared static. PHP would tell you that you cannot re-declare the class "foo" would it not? It would stop at the class declaration and wouldn't try to determine if the body of the two classes were different. Hence official namespaces, which can also experience naming collisions if not named uniquely enough.
That's fine if you are dealing with known values, but as I pointed out, web applications are loaded with un-known values from user input, URL's and automated sources outside of your control. Most of those values, regardless of their content, present themselves as type string.
Most of the time it can be more efficient to determine if input is what it is supposed to be, rather than the multitude of things that it should not be. Other times, the list of what that input should be, is longer or harder to determine than what it shouldn't be.
If for instance you are receiving a database record id from a URL to enable the script in question to update a database, there are four things that it cannot be. Zero, an empty string, null or not set at all. If you use a MySQL auto-increment id, then it has to be an integer, but if you aren't, then there is little else you can do without an extra query, to determine if it's a valid record id.
I wasn't implying that you didn't, I meant it in general.
Its a small set of circumstances and inference can be made based on context. So ambiguity shouldn't be an issue. But this is one of those preferential issues related to a programmers individual styles.
Creativity knows no other restraint than the
confines of a small mind. - Me
Geekly Humor
Oh baby! Check out the design patterns on that framework!
As others have said, it's all personal preference. I like to use empty(), and I prefer to read that than comparing something to false, because I find it easier to work out why I was doing something when looking at the code later on. I never use it on an unset variable anyway (usually checking with (isset() && isempty()) if I wanted to do that anyway), so the fact that it doesn't replicate empty()'s behaviour in that respect isn't an issue to me. Anyone else looking at my code could easily find the function and see what it does themselves, so I hardly think it's a problem for other people reading my code either. The benefits outweigh the cons for me.
I think it's just the way it reads. "Not true" and "not false" make sense, where "not 'asdf'" and "not array(5)..." don't as much.
I agree with the way !$var works in PHP. After all, PHP is not the language that's going to bark at you for throwing it invalid types. I just prefer to use empty() for non-booleans as it reads better and is less ambiguous. (All my preference, of course.)
I think people who don't use strict type setting are missing the complete point of logical developing. Think of it, if your application expects variables A, B, C and A should be of type BOOLEAN and B should be type UNSIGNED and C should be type STRING. Then one should at application initialization CAST them to the type that they should be, and if a variable is not set, set it to its predefined TYPE. That way you don't have to do silly things that have nothing to do with the ultimate objective of your application. Yes the variable VALUE is very important, but variable TYPE should never determine an applications logical control, as that should be handled before the applications logical control is even initiated.
If using classes as glorified namespaces is a crime, then I am afraid I am guilty of the occasional crime.
I don't, however, think it's a crime. In the absense of other methods to achieve the same separation of naming spaces, it's a convenient and relatively clean way of grouping functions together and not worrying about each individual function name's effect on the global namespace (just the class name, unfortunately). Even though it does not achieve what namespaces does, it doesn't hurt either. mylibrary::myfunction() is no worse than mylibrary_myfunction() - IMO they are different approaches and it is ok to favour the former.
[mmj] My magic jigsaw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Bit Depth Blog · Twitter · Contact me
Neon Javascript Framework Jokes
Well you are always going to have some sort of name in the global namespace, even if PHP supported packages.
I appreciate those here who try to enforce best practices on things that have direct impact on important issues such as code readability, maintainability and runtime efficiency, but realistically, I don't think that using the occasional static class for this purpose is really going to destroy a project, or cause anyone any undue work understanding the code.
Posting Permissions
Bookmarks