General Discussions

**Learning Newbie** · 02-05-2008, 07:44 PM

Just thought it would be a fun question, and the kind where you're asking a little more than you really let on.

**serandfae** · 02-05-2008, 08:22 PM

I wish that there was such a key as the equal sign with a slash through it, as has been standard in mathematics for centuries.

**ADAM Web Design** · 02-05-2008, 09:43 PM

As do I, but for programming purposes I prefer <> (less than or greater than.)

**NullPointer** · 02-05-2008, 10:11 PM

I think != is a bit more obvious that <>, for an experienced programmer it wouldn't make a difference, but for someone else... imagine someone reading if(x <> y) as if x is diamond y.

That being said I always use !=... but I think anyone that takes a look at the C++ syntax for pointers will agree that using <> instead isn't that big of a deal.

**ForrestCroce** · 02-05-2008, 10:52 PM

They both make sense to me. I'd guess if you learned through VB you'll prefer <> and if you used a C variant, != is more comfortable. But like NullPointer said, a lot of us have encountered both. SQL Server will accept either. <> means great than or less than, ie not equal,. ! means not, so !false is true and !true is false, !somevariable means and != means not equal.

**ADAM Web Design** · 02-05-2008, 11:02 PM

The problem I have with != is that it looks like "REALLY equal to" or that the equal to is of special importance. I know what it means, but that's not what it looks like. So, at the risk of being the only person with my opinion (yeah, like that's never happened before), I must disagree.

Mind you, as NullPointer suggested, a good programmer really doesn't care and can work with either. I can work with either, and I'm kind of sort of okay at web knowledge.

**ForrestCroce** · 02-05-2008, 11:15 PM

C has a terse, sometimes bizarre syntax. = means assigning a value and == means does one equal the other as a boolean. Unless you overload the operators; then they mean whatever code you write for them to mean.

I've been using Basic since DOS, when it was QuickBasic, and I was in middle or high school. And I've seen it through asp, asp.net, vb.net, embedded within Access ... it's helped me much. But I don't think you can write code like

Dim test as boolean
test = Result_Of_Some_Function()

If test Then Response.Write ... Else Response.Redirect ...

In C, it would be

bool test = Result_Of_Some_Function();
if(test) Response.Write("..."); else Response.Redirect("...");

It's assumed in the if blocks that you mean if(test == true). But an if works on any boolean value, even constants. So if(true) is valid code. In VB, I think you'd have to use If true = true Then.

Not trying to start a language war; I'm just trying to give some background on the funny syntax. In Seattle right now, anyone with C# on their resume can get two interviews a day without trying ... my experience in that language isn't quite as much as with Basic in all its flavors, but it's growing.

**newneo** · 02-06-2008, 10:39 AM

The second variant is mine.

**tripy** · 02-06-2008, 11:13 AM

I would go the !== syntax.

As I work mainly in PHP and javascript, and that they are so loosely typed, the triple operator syntax force the language to NOT cast the values.
Meaning that

Code:

1 !== '1'

is true where

Code:

1!='1'

is false

Quote:

if(test) Response.Write

As far as I know, this is a shorthand.
Most of programmation languages consider TRUE to be a "default value", and thus, this syntax is a shorthand to

Code:

if(test==true) Response.Write

**Learning Newbie** · 02-06-2008, 12:49 PM

Quote:

Originally Posted by tripy

As I work mainly in PHP and javascript, and that they are so loosely typed, the triple operator syntax force the language to NOT cast the values.

1!='1'

Don't you think implicit type conversions are a bad thing? 1 doesn't equal 1.0 let alone "1" or '1', right?

**tripy** · 02-06-2008, 01:37 PM

Quote:

Don't you think implicit type conversions are a bad thing?

Not always, no.
But they tend to let developer get lazy.
They develop an ability to let the engine work for themselves, and forget about the most basic steps to avoid injection, and mind alone exception handling....
That's why I love XSL...
It don't forgive you. You make a small syntax error, you think badly of your page layout?
Bam.... An XSL parser error.
It forces you to think before you code, or you are doomed, and you will curse it soooo much that you'll quit your job.
It's like a natural selection...

In PHP and javascript, I try to keep a specific syntax, determining itself the type of the variable, but I work mostly alone. This helps.
I think that the fact that I developed in languages that where strongly typed (C, C++ and a very little bit of Java) before helped me a lot here.
When you have to declare every variables before using them, including their type and the size of them, it forces you to think before you code.

The problem with loosely typed language, is that they tend to favor a "code first, debug later" approach.
Which is the cause of the bad reputation of PHP, in my mind.
The language itself is not to blame, but as it attract a lot of new developers who will not go the enterprise way.
They will probably never hear of unit testing, design patterns, test driven development, let alone "agile" development or XP.
I don't blame them, I never even thought of them three years ago.

Now, I see things differently, but it's because I had the chance to work as a developer in an enterprise, and to work with peoples who shoved me how much you can improve yourself simply by adhering to some simple principles.

But I have to admit than being able to mix the functions return types between boolean (false) and a string (for example) or a numeric value is something really nice.

Very error prone, but nice...

**cbwm** · 02:03 PM

Quote:

Originally Posted by ForrestCroce

Dim test as boolean
test = Result_Of_Some_Function()

If test Then Response.Write ... Else Response.Redirect ...

In C, it would be

bool test = Result_Of_Some_Function();
if(test) Response.Write("..."); else Response.Redirect("...");

I've optimized it for you

Result_Of_Some_Function()?Response.Write("..."):Re sponse.Redirect("...");

Loosely typed languages are convenient to use and produce extremely nasty and difficult to track down bugs. Compiled languages normally prevent these types of bugs at compile time.

**NullPointer** · 02-06-2008, 02:29 PM

Quote:

Originally Posted by tripy

But I have to admit than being able to mix the functions return types between boolean (false) and a string (for example) or a numeric value is something really nice.

Very error prone, but nice...

If one of my professors ever caught me doing something like that (if it were possible) they would throw a text book at me. Generally if you run into a situation where there are cases where you want to return a string and cases where you want to return a numeric value you should probably either re-think your design or build an object to handle your problem.

That being said its pretty handy when it comes time to hack something together real quick

**Learning Newbie** · 02-06-2008, 02:43 PM

Quote:

Originally Posted by cbwm

Loosely typed languages are convenient to use and produce extremely nasty and difficult to track down bugs. Compiled languages normally prevent these types of bugs at compile time.

Exactly! Loose typing and late binding are like magic made out of popsicle sticks and duct tape. A compiler is like a comprehensive junior level tester.

Modern languages don't even let you create a function with a return value, if it has any code path (through if statemetns, etc) that can return without a value unless that code path throws an exception to exit normal program flow. In other words, if you're expecting a value, you'll get one, or your program won't compile. That can mean it takes a little more work before you have something that half works, but the goal isn't really to make sloppy applications. It's to make good, robust, debuggable code, and that kind of stuff is like the windshield on a car instead of a big metal plate.

**tripy** · 02-06-2008, 02:58 PM

Quote:

If one of my professors ever caught me doing something like that (if it were possible) they would throw a text book at me.

You see, that's why I never felt at my place in a university. Too much violence up there.

No, seriously, I know it's not necessarily a good design, but I lastly used it when I wanted to transform an XML feed in HTML.

What did I do?
When I start the method for it, I check if the specified style sheet is there.
If not, I record an event in the log, and return FALSE.
If I could find the style sheet, I returned the transformed HTML.

It's plain simple, and works very well

PHP Code:


			
$html=transform($feedUrl);
if($html!==false){
  echo $html
}

It's clean, and I personally see the burden of having several versions of the method just to handle several case more of a burden.

True, I could have gone the way of the throw/catch exception, but it brings a performance overhead that I don't need.
Beside, if the problem is located in the XSL style sheet, I will not be able to catch the error, as PHP die with a fatal error.

So, as XP have teached me, why take a complicated road when a simpler is in front of you ? What will the complexity bring to your code ? In which way will my code be stronger by using the exception throws ?
As I could not honestly counter those assertions, I went on the mixed return type way.

It's not necessarily what I would have done elsewhere, but there, it had a meaning.

**NullPointer** · 02-06-2008, 03:04 PM

If I were doing that in Java or C++, rather than returning false I would throw an exception, but that kind of practice seems to be more acceptable in PHP

**Learning Newbie** · 02-06-2008, 03:46 PM

You can use strong typing and reflection to accomplish exactly this without breaking any best practices.

object o = class.Transform(source);
if(o as string != null)
echo (o.ToString());
else
echo ("Sorry - there's been a fatal error");

I don't know how that PHP stuff works, but we still have inheritance and polymorphism in strongly typed systems. This is why we still have explicit casting.

If an object can be refered to as an instance of its parent or itself, and all objects inherit at some level from System.Object, then you can store anything as an instance of object. You loose access to all the type specific members and what not. But you still have your pointer. And from there you can determine whether it's a pointer of a given type. So, if it's not a string, there's some kind of error, else give that string to the client. That brings you down the path to tight coupling because now all callers to a method have to know what possible return types to expect, but that's better than if you try to perform an illegal or potentially dangerous type cast on the fly.

**tripy** · 02-06-2008, 04:47 PM

Quote:

Originally Posted by NullPointer

If I were doing that in Java or C++, rather than returning false I would throw an exception, but that kind of practice seems to be more acceptable in PHP

True, in both case.
I still use the exception throw in a lot of places, but not everywhere.
In that particular case, I admit that I don't care to know what went wrong.

I let my script die, and that's all.
I would not let it go that way in a full packaged application...

**CSS4Life** · 02-06-2008, 05:41 PM

I prefer <> but I think I'll start using != now as it's fairly standard in PHP programming - from the scripts I've seen anyway, it's used more than <>.

It would be better if there was an overall standard for this - used everywhere in programming. Instead, there are these 2 options and probably several others.

**Learning Newbie** · 02-06-2008, 07:58 PM

You know, I actually don't know of any other standard methods of comparing whether two variables are the same or not.

I can think of a few non standard ones, like if you compare the hash values two produce, or if you run String.Compare("xyz", "abc", OrdinalCompare.CaseInsensative) it will return -1 if "xyz" < "abc" or 1 if "abc" < "xyz" or 0 if they're not. We're encouraged to do this with string comparisons in .NET because when your application is deployed to an operating system set to run in a different language than the one you wrote it in, String.Compare is or at least can be faster than <> or !=. You could also test whether the memory locations are the same, but that compares instances and not values.

1 standard would be better than 2, but 2 not equals syntaxes is better than the number of different SQL dialects we have to deal with. A friend is working on a project and wants to start in Access and "run the Upsize Wizard" if he needs to move it into SQL Server. I've been explaining how Access doens't have stored procedures that run more than one statement, so that's really not a viable option once he starts coding the application. And Access to SQL Server is so Microsoft they have a wizard. Try SQL Server to Oracle or Access to MySQL. Or PHP to ASP.NET.