Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

I believe it was Ada Lovelace who famously said "I think I can safely say that nobody understands PHP equality."

# ? Aug 11, 2011 05:51

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 11:52

No Safe Word: Feb 26, 2005

Doc Hawkins posted:

I believe it was Ada Lovelace who famously said "I think I can safely say that nobody understands PHP equality."

# ? Aug 11, 2011 05:59

NotShadowStar: Sep 20, 2000

You can't even reliably use === like Javscript because lots of PHP is so loving retarded you have to do a loose comparison or a whole chain of if ( (something === else) || (something === dickfart) )

# ? Aug 11, 2011 14:24

qntm: Jun 17, 2009

NotShadowStar posted:

You can't even reliably use === like Javscript because lots of PHP is so loving retarded you have to do a loose comparison or a whole chain of if ( (something === else) || (something === dickfart) )

php:

<?
class Object { }
$a = new Object();
$b = new Object();

print($a === $b ? "true" : "false"); // "false"
$b =& $a;
print($a === $b ? "true" : "false"); // "true"
?>

# ? Aug 11, 2011 14:40

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

qntm posted:

php:

<?
class Object { }
$a = new Object();
$b = new Object();

print($a === $b ? "true" : "false"); // "false"
$b =& $a;
print($a === $b ? "true" : "false"); // "true"
?>

Wait, what's the horror?

Two entirely separate objects are nonequal, that's fine. Do a reference assignment so that both are referencing the same object, and then they're equal (as they should be)?

PHP has enough horrors as it is, you don't really need to make up more.

# ? Aug 11, 2011 15:08

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Jabor posted:

Wait, what's the horror?

Two entirely separate objects are nonequal, that's fine.

I can see why you would say it's fine if you're making a special case of objects. But if you wrote

code:

$a = 5;
$b = 5;
echo $a === $b ? 'true' : 'false';

you would expect PHP to echo "true". So it is really only fine if, as I said, you anticipate it being very difficult to test whether two objects are equal, so you resort to saying that objects aren't in general equal and they should only test equal if they refer to the same thing.

But it is clear to a reader that those two things are equal. You could impose the rule that the data members of the objects are checked and if they are the same, the objects are equal. Better, though, would be to let the developer define a way to test whether two objects of a given class are equal. Unfortunately PHP doesn't do that.

# ? Aug 11, 2011 17:07

ninjeff: Jan 19, 2004

Hammerite posted:

I can see why you would say it's fine if you're making a special case of objects. But if you wrote
code:
$a = 5;
$b = 5;
echo $a === $b ? 'true' : 'false';
you would expect PHP to echo "true". So it is really only fine if, as I said, you anticipate it being very difficult to test whether two objects are equal, so you resort to saying that objects aren't in general equal and they should only test equal if they refer to the same thing.

No, it's "fine" for reference comparison to be the definition of equality for objects because it has a clear semantic meaning: two objects are equal if they are the same object. Implementation difficulty has nothing to do with it.

# ? Aug 11, 2011 17:21

baquerd: Jul 2, 2007; by FactsAreUseless

Hammerite posted:

You could impose the rule that the data members of the objects are checked and if they are the same, the objects are equal. Better, though, would be to let the developer define a way to test whether two objects of a given class are equal. Unfortunately PHP doesn't do that.

http://php.net/manual/en/language.oop5.object-comparison.php

# ? Aug 11, 2011 17:24

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

baquerd posted:

http://php.net/manual/en/language.oop5.object-comparison.php

ninjeff posted:

No, it's "fine" for reference comparison to be the definition of equality for objects because it has a clear semantic meaning: two objects are equal if they are the same object. Implementation difficulty has nothing to do with it.

Then presumably it would be fine for reference comparison to be the definition of equality for non-objects as well, because that too has "a clear semantic meaning"?

So if PHP instead worked in such a way that the code I posted would echo 'false', I trust you'd have no problem with that?

# ? Aug 11, 2011 17:46

baquerd: Jul 2, 2007; by FactsAreUseless

Hammerite posted:

Then presumably it would be fine for reference comparison to be the definition of equality for non-objects as well, because that too has "a clear semantic meaning"?

That's not equality you're testing, it's identity in PHP parlance, and sure I'd tolerate identity working that way for non-objects but then all you're really doing is shortcutting reference equality.

# ? Aug 11, 2011 17:54

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

Hammerite posted:

I can see why you would say it's fine if you're making a special case of objects. But if you wrote
code:
$a = 5;
$b = 5;
echo $a === $b ? 'true' : 'false';
you would expect PHP to echo "true". So it is really only fine if, as I said, you anticipate it being very difficult to test whether two objects are equal, so you resort to saying that objects aren't in general equal and they should only test equal if they refer to the same thing.

But it is clear to a reader that those two things are equal. You could impose the rule that the data members of the objects are checked and if they are the same, the objects are equal. Better, though, would be to let the developer define a way to test whether two objects of a given class are equal. Unfortunately PHP doesn't do that.

Wait, am I misunderstanding your argument? Because the code you provided echoes "true".

# ? Aug 11, 2011 18:25

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

DaTroof posted:

Wait, am I misunderstanding your argument?

I think so. I'm aware that that code echoes "true", as it should. I'm saying that by analogy, it's not unreasonable (though it could be thought naive) to expect the earlier code involving objects to echo "true", as well.

# ? Aug 11, 2011 18:38

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

Hammerite posted:

I think so. I'm aware that that code echoes "true", as it should. I'm saying that by analogy, it's not unreasonable (though it could be thought naive) to expect the earlier code involving objects to echo "true", as well.

Ah, I see what you mean now. An easy misunderstanding, but not a coding horror, imo.

# ? Aug 11, 2011 18:50

NotShadowStar: Sep 20, 2000

Would be drat nice if PHP allowed designation of operators on instances since == and === can be very undefined in that case.

But we're talking about PHP, it's only been within the last couple years that it has an object system that's actually usable.

# ? Aug 11, 2011 20:40

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

code:

peter@megatron:~ echo '<? if (TRUE == "php" && "php" == 0 && 0 == FALSE) echo "TRUE"; else echo "FALSE"; ?>' | php
TRUE

# ? Aug 11, 2011 20:58

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

TRex EaterofCars posted:

code:

peter@megatron:~ echo '<? if (TRUE == "php" && "php" == 0 && 0 == FALSE) echo "TRUE"; else echo "FALSE"; ?>' | php
TRUE

As someone who has never done a lick of web development, this is the most compelling evidence I've seen that PHP is as horrible as its reputation.

# ? Aug 11, 2011 21:09

tef: May 30, 2004; -> some l-system crap ->

don't forget that leading whitespace, newlines and zeros are not counted when implicitly converting a string to a numerical value.

it is also nice to see that exact value comparison (===) is the same as object identity, and causal equivalence (==) doesn't do any implicit casting :q:

i mean, this way you have to use == to compare objects and === to compare things of the same type if they're not an object. assuming that is you don't have have transient fields.

the idea that php has a usable object model is laughable. a genuine object model has an associated meta object protocol that allows you to define new behaviours. like for equality.

# ? Aug 11, 2011 21:14

No Safe Word: Feb 26, 2005

Eggnogium posted:

As someone who has never done a lick of web development, this is the most compelling evidence I've seen that PHP is as horrible as its reputation.

You could make it worse just by chaining the really weird/outlandish TRUE results from my chart at the top of the page..

# ? Aug 11, 2011 21:15

tef: May 30, 2004; -> some l-system crap ->

php in a nutshell: 'I don't understand the language or the semantics but I can copy paste enough to write trivially exploitable cgi scripts'

# ? Aug 11, 2011 21:20

NotShadowStar: Sep 20, 2000

I've been working with Drupal a hell of a lot the last six months. The core developers behind it seem like reasonably intelligent people and understand PHP is a wretched language and keep it to the very basics: arrays, functions, very basic objects and it works okay-ish, if not excessively verbose. Unfortunately when I have to delve into PHP land I remember how god awful it its. It took me an entire afternoon to parse a CSV file because neither str_getcsv or fgetcsv could figure out new lines properly so it always just split CSV files into one gigantic flat array. Something that would take minutes to do in any other language.

Presenting the PHP global function namespace

e: HOW FAR DOWN THE HOLE DO YOU WANT TO GO

NotShadowStar fucked around with this message at 22:15 on Aug 11, 2011

# ? Aug 11, 2011 22:12

1337JiveTurkey: Feb 17, 2005

The == PHP operator really encourages what I feel is the dark side of dynamically typed programming languages. There's a big difference between a string of characters and whatever number it can be parsed as. The ability to make these sorts of conversions automatically can be a big timesaver but it's semantically sloppy or outright nonsensical.

A related problem is that identity is not the same as equality so the "safe" alternative isn't really. The only time it's really safe to assume that is when there's tightly controlled instantiation. Language-enforced singletons or OS handles for instance. But in the general case (especially with mutable state) it's at best an approximation.

# ? Aug 11, 2011 23:15

qntm: Jun 17, 2009

tef posted:

php in a nutshell: 'I don't understand the language or the semantics but I can copy paste enough to write trivially exploitable cgi scripts'

The biggest horror in PHP is the absence of a mysql_prepare() function in the basic MySQL library, resulting in an entire generation of web application developers with no idea what a prepared statement even is.

# ? Aug 11, 2011 23:22

tef: May 30, 2004; -> some l-system crap ->

1337JiveTurkey posted:

The == PHP operator really encourages what I feel is the dark side of dynamically typed programming languages. There's a big difference between a string of characters and whatever number it can be parsed as. The ability to make these sorts of conversions automatically can be a big timesaver but it's semantically sloppy or outright nonsensical.

A related problem is that identity is not the same as equality so the "safe" alternative isn't really. The only time it's really safe to assume that is when there's tightly controlled instantiation. Language-enforced singletons or OS handles for instance. But in the general case (especially with mutable state) it's at best an approximation.

implicit casts are a feature of weakly typed languages, not necessarily or exclusively within dynamic languages.

C has quite a few implicit casts

# ? Aug 12, 2011 02:17

Zhentar: Sep 28, 2003; Brilliant Master Genius

1337JiveTurkey posted:

The == PHP operator really encourages what I feel is the dark side of dynamically typed programming languages. There's a big difference between a string of characters and whatever number it can be parsed as. The ability to make these sorts of conversions automatically can be a big timesaver but it's semantically sloppy or outright nonsensical.

And yet many other such languages handle it far better, with reasonable, consistent behavior.

PHP: Making MUMPS look good in comparison.

# ? Aug 12, 2011 02:29

shrughes: Oct 11, 2008; (call/cc call/cc)

tef posted:

implicit casts are a feature of weakly typed languages, not necessarily or exclusively within dynamic languages.

C has quite a few implicit casts

Implicit casts are the same thing as inheritance.

# ? Aug 12, 2011 02:45

NotShadowStar: Sep 20, 2000

qntm posted:

The biggest horror in PHP is the absence of a mysql_prepare() function in the basic MySQL library, resulting in an entire generation of web application developers with no idea what a prepared statement even is.

You're actually supposed to use PDO in PHP >5.1, but the core PHP devs don't think it prudent to deprecate all of the old functions for anything ever. :derp:

# ? Aug 12, 2011 04:26

McGlockenshire: Dec 16, 2005; GOLLOCKS!

The PHP documentation team announced their intent to document the old mysql extension as deprecated once 5.4 is out the door, with the actual deprecation not occurring until the next major release.

We might actually see it gone before the end of the decade!

# ? Aug 12, 2011 04:53

1337JiveTurkey: Feb 17, 2005

tef posted:

implicit casts are a feature of weakly typed languages, not necessarily or exclusively within dynamic languages.

C has quite a few implicit casts

Dynamic languages tend to feature implicit casts on a broader scale than statically typed languages and with fewer compile-time sanity checks. The C type system is still too weak for my tastes but I feel it's in a different league from PHP. An implicit cast from one numeric type to a longer type is generally safe except for signedness issues and overflow. Honestly those two would be no problem if more languages took after Ada (no, really) and allowed trapping integer overflow or modular numeric types for where it's actually necessary.

shrughes posted:

Implicit casts are the same thing as inheritance.

Implicit casts are functions from one type to another. If I write foo = 2 + "2" or foo = "2" + 2 then depending on the language, foo might equal 4 or "22" (or both depending on the order of the operands). Either I'm terrible at math or that is the worst violation of the Liskov Substitution Principle I have ever seen.

# ? Aug 12, 2011 04:58

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

1337JiveTurkey posted:

Implicit casts are functions from one type to another. If I write foo = 2 + "2" or foo = "2" + 2 then depending on the language, foo might equal 4 or "22" (or both depending on the order of the operands). Either I'm terrible at math or that is the worst violation of the Liskov Substitution Principle I have ever seen.

If it's consistent within a language, then there's no problem?

Unless you were wanting to talk about the principle of Least Surprise instead of LSP, I guess.

Alternatively you could use a language that doesn't use the exact same operator for two completely different operations.

# ? Aug 12, 2011 06:30

NotShadowStar: Sep 20, 2000

PHP an Javascript are both from the same era when Perl showed everybody 'Hey guys check this out a language where you never need to worry about type ever _{except when you want to ensure that this data is an integer or a float or oh god how do i am not good with}' Luckily Ruby and Python are both from the same era and managed to escape that bit of insanity.

# ? Aug 12, 2011 06:31

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Jabor posted:

Alternatively you could use a language that doesn't use the exact same operator for two completely different operations.

Not many languages pass that test; for example, concatenation and addition are just as different, yet "a" + "b" isn't a type error.

# ? Aug 12, 2011 06:37

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Janin posted:

Not many languages pass that test; for example, concatenation and addition are just as different, yet "a" + "b" isn't a type error.

Depends on the language - Perl wouldn't be doing a string concatenation there, for example.

When it comes to strongly-typed languages "based on the type of the left-hand operand" is a perfectly fine solution - but for a loosely typed language, overloading a single operator for two conceptually different things is a bad idea.

# ? Aug 12, 2011 06:47

tef: May 30, 2004; -> some l-system crap ->

shrughes posted:

Implicit casts are the same thing as inheritance.

no

(although fwiw I can see why you say that)

# ? Aug 12, 2011 08:19

shrughes: Oct 11, 2008; (call/cc call/cc)

tef posted:

no

Actually you're a bad person, the author's wrong, and that paper has a signal:noise ratio of 0, and I'm right.

I'm right because the notion "A inherits from B" is indistinguishable from the notion "a conversion from type A to type B exists," and because that's what I said.

The author's wrong because the notion "A inherits from B" is indistinguishable from the notion "a conversion from type A to type B exists," yet he spent the time to write a 37-page paper about irrelevant aspects of inheritance, like how it's used to define functions and types, and minutia about how it's slightly different in different languages, and completely useless notions about the politically correct way to describe the relationship between the parent and child.

You see how there are cute little quotations at the beginning of each section? Like one from Devo, another from a Congolese proverb, and one from Aristotle? They're big flags waving to the reader saying that the paper is stupid. You see how he wants to find the essence of inheritance? If only we concentrate hard enough, we'll look at inheritance from just the right angle, and be ENLIGHTENED! No. The essence of inheritance is that it defines a conversion function from one type to another, but you couldn't write a 37-page paper about something simple like that. Instead you've gotta make things complicated and nuanced and talk about sharing and combination and incremental modification mechanisisms in the presence of late-bound self-reference.

(The author is also wrong because the mechanism of inheritance is merely a hack around the lack of existential types, and the question of which hack one chooses to use is Not Interesting.)

You're a bad person because you fell for a CS paper written by a researcher working in Nokia's humanities department.

So let's review:

1. T inheriting from U just means there exists a function Convert: T -> U, usually in the form of an implicit conversion. Sometimes there's also a Unconvert: U -> Maybe<T>.

2. All the mechanisms of inheritance are just hacks around lack of existential types, or in dynamic languages it's all just syntactic sugar and some hints for the JIT.

3. The author of that paper hopefully lost his job in one of Nokia's layoffs.

# ? Aug 12, 2011 09:40

tef: May 30, 2004; -> some l-system crap ->

I disagree. (entirely)

If you read the paper you would see that there is a notion of inheritance for subtyping and inheritance for code reuse. Traditionally in languages inheritance falls into the former camp with no way for the latter.

the existence of a conversion function does not mean that it is implictly casted from one to another. you can use inheritance without creating a subtype relation, thus no implicit casts.

i.e you're full of poo poo go back to your monads and cry :3:

or you can redefine words for your own entertainment, either way.

tef fucked around with this message at 11:25 on Aug 12, 2011

# ? Aug 12, 2011 11:18

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

shrughes posted:

The essence of inheritance is that it defines a conversion function from one type to another

No, the essence of inheritance is that SubClass is a BaseClass. The conversion is done by pointer offsets or other aliasing methods, not conversion functions. You are high.

# ? Aug 12, 2011 14:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

https://www.youtube.com/watch?v=KlujizeNNQM&t=130s

# ? Aug 12, 2011 14:53

TasteMyHouse: Dec 21, 2006

this stupid program I'm trying to write a plug in for has a "settings" table. when it generates the table, for some reason it is generating a field for a property that really shouldn't be in a table like that... and since my device isn't connected yet when it attempts to read the property, my device throws an exception with a useful message as to what went wrong. The program then populates the field with said exception message. cool

# ? Aug 12, 2011 15:02

tef: May 30, 2004; -> some l-system crap ->

wellwhoopdedooo posted:

No, the essence of inheritance is that SubClass is a BaseClass. The conversion is done by pointer offsets or other aliasing methods, not conversion functions. You are high.

High on Haskell :weed:

# ? Aug 12, 2011 15:30

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 11:52

tef: May 30, 2004; -> some l-system crap ->

wellwhoopdedooo posted:

No, the essence of inheritance is that SubClass is a BaseClass. The conversion is done by pointer offsets or other aliasing methods, not conversion functions. You are high.

Actually if you read my post you would find that I am saying that the essence of inheritance is not that. The key part of my argument is that inheritance can be used without expressing a subclassing relationship (in some languages) so does not fall easily into existential classes.

So I don't think he is correct in making a bold accusation that all inheritance is a hack around existential types, although he'll probably find some technicality and janin his way out of it. But I don't think you are right either.

(There is also some argument about oop vs adt styles here too)

shrughes is right in that subclassing inheritance can be expressed with existential types, but his haskell blinkers make him think that his way is somehow the canonical methodology.

# ? Aug 12, 2011 15:37

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »