Comment On Operator Overloading Overload

Anonymous:

I'm sorry but this WTF is too obscure and dense to parse.  Where exactly are the WTFs?

Anonymous:

It's python, which is actually the bastard child of Java and Perl.

Anonymous:

Ok, I'll bite and defend this one.

The general idea isn't too bad.  If they get rid of __getattr__ and replace __add__ with __div__, they get a program where operator overloading actually makes some sense.  At the very least, it makes paths more readable:


a = path("a");
b = path("b");
c = a/b;


Been done before by others... I would just use the standard path manipulators myself.

assuming c would equal "a/b" or a simpler example

a=path("/inittech");

b=path("superprogram")

c=a/b

c would then equal  "/inittech/superprogram"

I see your point with the / operator, but it really would confuse the hell out of a new programmer reading the code for the first time.  Unless the consumer of the class has access to the code I would probably avoid using operator overloading like that.

Anonymous:

Maybe the guy was a Perl programmer, and wanted MTOWTDI.



Ding ding ding ding ding!

zephc:

(Aside: Notice that literals can have methods called upon them)

zephc:

Hah, i like how s/he used os.path.join() in the
constructor. Maybe the guy was a Perl programmer, and wanted MTOWTDI. I
also like how that class was only used a few times in the project,
further invalidating the time spent on it.
Operator overloading definitely has its advantages, but this is just
silly.
6/10 on the WTF meter, IMO.

Anonymous:

In C and C++, you can actually use i[SomeArray].



Try it!

Anonymous:

In C and C++, you can actually use i[SomeArray].

Anonymous:

(Aside: Notice that literals can have methods called upon them)

And of course we can combine these so that

"ABCD"[2] == 2["ABCD"] == 'C'

path("project")a.b.c.super() -> "project/a/b/c/super"

God help the unix person with no python skills who is thinking

"project/a.b.c.super"

Of for that matter someone who is thinking a that this is violating
abstraction by going down a long chain of member classes to call
c.super()

zephc:

Maybe the guy was a Perl programmer, and wanted MTOWTDI.

Err, unlikely. No Perl programmer would use overloading to begin with. And any self-respecting Perl programmer relies on File::Spec, which Python’s os.path roughly corresponds to.

Larry’s own corollary to TMTOWTDI is “but not all ways are created equal.” The multiple options exist so you can pick the one which most clearly conveys intent, not to make your code more varied and exciting. If you don’t trust your restraint and sense of style, then not having options will obvious be desirable and Perl is not for you.

This WTF smells like a C++ programmer’s doing to me.

loneprogrammer:

The only language that matters is binary
code.  Everything else is just shorthand for it.

Xepol:

Uh, for those wondering where the wtf is, its because path("project", "super")() is probably longer to type than "project/super", makes you wonder, in fact, there does not appear to be ANY circumstances where this reduces typing, simplifies code or avoids bugs.

Err. Try again. On Windows, that would be project\super. And MacOS Classic, it would be projects:super. That is what os.path.join is all about: system-independent filename manipulation. The WTF is that he writes an elaborate bunch of crap to be able to say path("project")["super"] where it should be simply os.path.join("project","super").

Aristotle Pagaltzis:

Xepol:

Uh, for those wondering where the wtf is, its because path("project", "super")() is probably longer to type than "project/super", makes you wonder, in fact, there does not appear to be ANY circumstances where this reduces typing, simplifies code or avoids bugs.

Err. Try again. On Windows, that would be project\super. And MacOS Classic, it would be projects:super. That is what os.path.join is all about: system-independent filename manipulation. The WTF is that he writes an elaborate bunch of crap to be able to say path("project")["super"] where it should be simply os.path.join("project","super").

What gets me is the fact that he actually uses os.path.join in the code...

phelyan:

Aristotle Pagaltzis:

Xepol:

Uh, for those wondering where the wtf is, its because path("project", "super")() is probably longer to type than "project/super", makes you wonder, in fact, there does not appear to be ANY circumstances where this reduces typing, simplifies code or avoids bugs.

Err. Try again. On Windows, that would be project\super. And MacOS Classic, it would be projects:super. That is what os.path.join is all about: system-independent filename manipulation. The WTF is that he writes an elaborate bunch of crap to be able to say path("project")["super"] where it should be simply os.path.join("project","super").

What gets me is the fact that he actually uses os.path.join in the code...

Anonymous:

Ok, I'll bite and defend this one.



Been done before by others... I would just use the standard path manipulators myself.

Indeed. The path
Python module is a good example.

Ytram:

I'm dying to know what language this is.  It looks like the bastard child that would come from an unholy union of C++ and VB

People seem to ask this every time. How about including which language it is in the post description for each WTF?

Anonymous:

You know, I forgot about that i[SomeArray]...



can anyone explain to me again why this works in c/c++?



index[SomeArray]

it seems like it should ONLY work as SomeArray[index]



What's going on behind the scenes?

Actually, I think that index[some_array] only works if sizeof(*some_array) == 1.

some_array[index] is the same as *(some_array + index * sizeof(*some_array)), not *(some_array + index). Implicitly casting a non-pointer to a pointer gets you a void *, so sizeof(*not_a_pointer) is the same as saying sizeof(void). This doesn't make sense, so is generally taken to be 1 as a fallback.

So, index[some_array] is good for obfuscating access to your char *s, but not much else.

Irrelevant:

Actually, I think that index[some_array] only works if sizeof(*some_array) == 1.

Nope.  This correctly prints "3.0000":

int main(int argc, char* argv[])
{
      float arr[5] = {1.0,2.0,3.0,4.0,5.0};
      printf ("%f", 2[arr]);
      return 0;
}

Irrelevant:

Actually, I think that index[some_array] only works if sizeof(*some_array) == 1.

some_array[index] is the same as *(some_array + index * sizeof(*some_array)), not *(some_array + index). Implicitly casting a non-pointer to a pointer gets you a void *, so sizeof(*not_a_pointer) is the same as saying sizeof(void). This doesn't make sense, so is generally taken to be 1 as a fallback.

So, index[some_array] is good for obfuscating access to your char *s, but not much else.

A question about this wonderful C++ code...

I understand why array[index] works...

But why does index[array] not end up taking the pointer to index and adding the pointer to array, leading to a very random place in memory? How does it know not to dereference index, while in the first case it does dereference array... Or am I just confused this early on Monday morning??

Drak

Drak:

A question about this wonderful C++ code...

I understand why array[index] works...

But why does index[array] not end up taking the pointer to index and
adding the pointer to array, leading to a very random place in memory?
How does it know not to dereference index, while in the first case it
does dereference array... Or am I just confused this early on Monday
morning??

witch:

Because it doesn't dereference the pointer array in the first place! Array is the name of the address of array, so naming it already specifies the address, no need to reference or 'get-address-of' here!

It's confusing at first, but when you get used to it.... you use it as little as possible.

Christ

hmm, ok I think I understand.. so the 'value' of array is actually it's address in memory...

Drak

This is Python, sweet glorious python
and until you get in and do it, you won't realize what a beautiful and
powerful language it is.


The syntax is a breeze and quite readable as a general rule.

Anonymous:

Ytram:

I'm dying to know what language this is.  It looks like the bastard child that would come from an unholy union of C++ and VB

People seem to ask this every time. How about including which language it is in the post description for each WTF?

People are just too lazy to go and find out. And this was an easy one, for there's a link to http://docs.python.org/lib/module-os.path.html [:D]

Sometimes the Java/C# confusion comes along. I usually set them apart by methodName (Java) instead of MethodName (.NET), when possible.

Anonymous:

phelyan:

What gets me is the fact that he actually uses os.path.join in the code...

That would be because he can't assume that he needs to use "/".

Anonymous:

Anonymous:

phelyan:

What gets me is the fact that he actually uses os.path.join in the code...

That would be because he can't assume that he needs to use "/".

*sigh* os.path.join() is os independent.... which means that you use it exactly when you can't assume how you'll be creating paths..... did you miss the post that said that?

um... Whom are you talking to?  You are just repeating the same point Anonymous just made......