Search Amazon.com:
Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«641 »
  • Post
  • Reply
Doc Hawkins
Jun 15, 2010

Dashing, you say? 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."

Adbot
ADBOT LOVES YOU

No Safe Word
Feb 26, 2005

I sure do love holding onto the rock!

Doc Hawkins posted:

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

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) )

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"
?>

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.

Hammerite
Mar 9, 2007

And you don't remember what I said here, either, but it was pompous and stupid.

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.

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.

baquerd
Jul 2, 2007

Oh God! to hear the Insect on the leaf pronouncing on the too much life among his hungry brothers in the dust!

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.o...-comparison.php

Hammerite
Mar 9, 2007

And you don't remember what I said here, either, but it was pompous and stupid.




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?

baquerd
Jul 2, 2007

Oh God! to hear the Insect on the leaf pronouncing on the too much life among his hungry brothers in the dust!

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.

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".

Hammerite
Mar 9, 2007

And you don't remember what I said here, either, but it was pompous and stupid.

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.

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.

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.

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

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.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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

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.

No Safe Word
Feb 26, 2005

I sure do love holding onto the rock!

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..

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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'

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 Aug 11, 2011 around 21:15

1337JiveTurkey
Feb 17, 2005

Baby, I'm hot, just like your oven...

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.

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.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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

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.

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.

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.

McGlockenshire
Dec 16, 2005



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!

1337JiveTurkey
Feb 17, 2005

Baby, I'm hot, just like your oven...

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.

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.

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.

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.

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.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


shrughes posted:

Implicit casts are the same thing as inheritance.

no


(although fwiw I can see why you say that)

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.

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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

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

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

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.

Otto Skorzeny
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


http://www.youtube.com/watch?v=KlujizeNNQM#t=130s

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

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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

Adbot
ADBOT LOVES YOU

tef
May 30, 2004

Avoid Symmetry, Allow Complexity, Introduce Terror


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.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«641 »