The Official Status Thread
-
Status: spent 5 minutes reading six one-liner posts because quoting is apparently too hard for trolleybus elite and forcing readers to trace the conversation manually across pages is much better!
And that whole argument was extremely stupid. Everyone knows the canonical spelling is Hawaje.
-
@Gąska Goddamn United Fruit lackey! (draws swords)
-
@Gąska I don't speak Polish but in English we say Harambe
-
@e4tmyl33t said in The Official Status Thread:
@Tsaukpaetra said in The Official Status Thread:
@Luhmann said in The Official Status Thread:
@Tsaukpaetra said in The Official Status Thread:
fresh blood mods
are you proposing vampirism?
Now else can we infuse life into the forums?
I'm pretty sure I can get ahold of a lich...
(Ok, ok, that'd be UNlife, but it counts! Zombies are people too!)
Oh, well, we have plenty of dead people here so...
-
Status: I want to go home and play a Digimon RPG on Vita instead of working. I didn't feel that way about Octopath Traveler at all.
-
-
Status: Trying to teach my circular buffer how to not eat itself when full...
So far so good...
Fuck.... The ingestion threw up...
-
@Magus said in The Official Status Thread:
@Rhywden Oh the incredible joy of you of all people talking about others losing gaskets. Exquisite.
Oh, please, don't act as if you're the paragon of virtue here.
-
@Rhywden Of course not, I wouldn't want to steal your job.
-
@Magus said in The Official Status Thread:
@Rhywden Of course not, I wouldn't want to steal your job.
While that may be a fun quip, it doesn't exactly show that you're capable of a cogent thought :)
-
@Rhywden Sorry old chap, I think you've rather underestimated me at this point. Why, you should know that I, unlike the poor, pathetic denizens of this site am a German chemistry teacher, an absolute paragon of virtue and intelligence. None shall ever surpass my great and glorious moral superiority! After all, it is well known that Germans are superior, is it not?
-
@Tsaukpaetra said in The Official Status Thread:
Fuck.... The ingestion threw up...
Okay, that's fixed, and in theory so is the starting offset logic...
Now for testing!
-
@Rhywden said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Rhywden Because you'd give an answer inconsistent with your previous statements.
You may not remember it but it was you after all who blew a gasket over an apostrophe. Now quit whining and being such a snowflake.
What does any of this have to do with @Gąska? And > .
-
status:
C:\Program Files> dir -recurse -force | ?{ ($_ | get-ntfsowner).owner -eq 'Everyone' } | set-ntfsowner -account 'NT SERVICE\TrustedInstaller' C:\Program Files> cd 'C:\Program Files (x86)' C:\Program Files (x86)> dir -recurse -force | ?{ ($_ | get-ntfsowner).owner -eq 'Everyone' } | set-ntfsowner -account 'NT SERVICE\TrustedInstaller' C:\Program Files (x86)> cd ~ C:\Users\Adam> dir -recurse -force | ?{ ($_ | get-ntfsowner).owner -eq 'Everyone' } | set-ntfsowner -account 'DESKTOP-S4ACATL\Adam'
it's been a fun day
C:\Users\Adam> get-ntfsowner $env:windir Item Owner ---- ----- C:\WINDOWS Everyone
so fun
-
@pie_flavor That seems... insanely bad.
-
@Magus I will in fact be filing a formal complaint with Microsoft Support.
-
@Magus said in The Official Status Thread:
Status: I want to go home and play
a Digimon RPG on Vitajust about anything instead of working.FTFM
-
@pie_flavor Good. They should never have told you to do any of that.
-
@HardwareGeek That would be the case in winter. But I don't have AC.
-
Remember when I complained about the no good very bad Twitch Premieres, and how it slowly changed which set of bugs were active over the course of months? YouTube has decided to literally make the exact same feature with the same name but without bugs: https://www.youtube.com/watch?v=JXdCTn1KutA
-
@pie_flavor said in The Official Status Thread:
Status: Well, the summer class has concluded, with absolutely zero of the work I was supposed to be doing getting turned in. Blame the administrators. Aaand I got a B. For one paper, one blog post, and one two minute play, for three credits. You know? I don't think I'm going to argue with that.
Status: I really really regret having sent an email a few days ago that tipped her off to this occurring.
-
This post is deleted!
-
@sockpuppet7 Since the websocket is having troubles actually web-socketing, I can reply!
Yes, Java. That is all.
-
Status: Circular buffer code pushed. Let's pray I don't run into any weird issues.... XD
-
status: phone dropped. I think it was the 14th time ever. Screen cracked from three foot fall. Well then....
-
@tsaukpaetra said in The Official Status Thread:
Well then....
Huh, have I really had this phone for three years? Hot damn it still works well for that age...
-
Status: Thanks Java, of course if I call
toString()
on an array I'd expect it just to use the baseObject.toString()
Couldn't you at least stub it out and throw a
UnsupportedOperationException
? Or just implement the sodding thing.[C@feca15a1ad
-
@Cursorkeys Arrays.toString
-
@pie_flavor said in The Official Status Thread:
@Cursorkeys Arrays.toString
Thanks, that's what I'm using now. The situation is still retarded though.
-
Status: Had some McDonald's for lunch as I did some hard work in throwing away the sofa I got with the house. Damn, that thing reeked of decades of tobacco smoke. Thankfully all gone now. Also, Big Mac sauce still doesn't taste good, even if it's not on a Big Mac. Also, apropos of McD:
-
This post is deleted!
-
@Cursorkeys said in The Official Status Thread:
Status: Thanks Java, of course if I call
toString()
on an array I'd expect it just to use the baseObject.toString()
The whole idea of the base class for everything having a method that makes no sense for most objects is retarded. Of course, it's mostly for historical reasons, but they should've deprecated it and replaced with
interface ToString
or something. Same forclone()
,equals()
andhashCode()
.
-
@Gąska It's useful for debugging. If you implement your own descriptive .toString, great, but if not, it's a decent way for the language to give some unique* string representation of any object.
-
@hungrier said in The Official Status Thread:
@Gąska It's useful for debugging. If you implement your own descriptive .toString, great, but if not, it's a decent way for the language to give some unique* string representation of any object.
<Object 0527283682XBQ> is not of much help :/. Maybe I'm doing this whole OOP thing wrong.
-
@hungrier said in The Official Status Thread:
@Gąska It's useful for debugging.
Then it should be used for debugging, and nothing else. Alas, this is the official way to convert many classes to their canonical string representation - for example,
StringBuffer
.@hungrier said in The Official Status Thread:
some unique* string
Each and every class in the entire Java ecosystem has its own rules on how unique the
toString()
of two separate instances are, and how long it stays the same for the same object. It's bad for identification, it's bad for serialization, it's bad for user-readable output. There is no good reason to ever use it in production code for anything, except when the library author made it the only way to access very important data, which is the case with half of standard library.
-
@stillwater It's not a particularly meaningful representation, but it helps if something weird is happening, and you see a log that looks like:
12:34:12 PM - .fiddle() - foo = FiddleTarget@123456af 12:34:13 PM - about to start fiddling - foo = FiddleTarget@123456af 12:34:22 PM - fiddling partially complete - foo = FiddleTarget@123456af 12:34:25 PM - done fiddling - foo = FiddleTarget@987fde21
@Gąska said in The Official Status Thread:
There is no good reason to ever use it in production code for anything
Unless you override it with something that's more useful than
Class@somewhere
; you could of course define your own.userFacingStringRepresentation()
but since you already have a method for that by design, you can override it and you get compatibility with everything that assumes.toString
for free. The base Object one is a bare minimum fallback that's marginally more useful than Javascript's [Object object], and of course should be overridden for any serious use.
-
@hungrier Wouldn't hashcode solve the same problem?
-
@stillwater It solves a similar problem, but also requires that you implement it for whatever particular class you're writing. Java doesn't automatically know about all your member vars and how one object of your class can be different from another. But it gives you
Class@somewhere
orSubClass@somewhereelse
for free.
-
@hungrier said in The Official Status Thread:
@stillwater It's not a particularly meaningful representation, but it helps if something weird is happening, and you see a log that looks like:
12:34:12 PM - .fiddle() - foo = FiddleTarget@123456af 12:34:13 PM - about to start fiddling - foo = FiddleTarget@123456af 12:34:22 PM - fiddling partially complete - foo = FiddleTarget@123456af 12:34:25 PM - done fiddling - foo = FiddleTarget@987fde21
@Gąska said in The Official Status Thread:
There is no good reason to ever use it in production code for anything
Unless you override it with something that's more useful than
Class@somewhere
;No - if you want to make something more useful than "return undefined string that somehow relates to class content (or not)", then create a new damn method. Don't use a method for returning undefined strings for anything other than returning undefined strings. That's bad design and breaks several rules of proper OOP.
you could of course define your own
.userFacingStringRepresentation()
but since you already have a method for that by designYou don't.
toString()
isn't designed to be user-facing string representation.you get compatibility with everything that assumes
.toString
for free.Often in surprising ways because the library has a slightly different idea what
.toString()
is for than you. For example, they might assume two different data object always return different strings, and base their core logic off that assumption. Another library might assume the string representation doesn't change for the entire lifetime of the object (which is true statement for most classes).toString()
is like liberalism - it has so many meanings that it's become useless for communication.
-
@Gąska said in The Official Status Thread:
No - if you want to make something more useful than "return undefined string that somehow relates to class content (or not)", then create a new damn method. Don't use a method for returning undefined strings for anything other than returning undefined strings. That's bad design and breaks several rules of proper OOP.
But that's not what it is.
toString
doesn't return "a random looking useless string representation", it returns a "string representation", with the default one being "something that looks like Class@memory address". It doesn't have to stay that way, and if you're using it for anything, it should be overridden by something useful. Contrary to what you said, it's actually good OO design: a method that's guaranteed to be there (by virtue of inheriting from Object), that can be left alone if you don't need it (Class@wherever, still marginally useful for debugging but not much else) or overridden with something useful (StringBuffer.toString).@Gąska said in The Official Status Thread:
You don't. toString() isn't designed to be user-facing string representation.
It's designed to be any string representation. If you want to make it something user-facing for convenience (e.g. Customer.toString returns their name), you can do so, or you can use something different (Customer.fullName()).
@Gąska said in The Official Status Thread:
For example, they might assume two different data object always return different strings, and base their core logic off that assumption. Another library might assume the string representation doesn't change for the entire lifetime of the object (which is true statement for most classes).
Without .toString, libraries with brain-dead idiot design would still find other ways to be brain-dead.
-
@hungrier said in The Official Status Thread:
@Gąska said in The Official Status Thread:
No - if you want to make something more useful than "return undefined string that somehow relates to class content (or not)", then create a new damn method. Don't use a method for returning undefined strings for anything other than returning undefined strings. That's bad design and breaks several rules of proper OOP.
But that's not what it is.
toString
doesn't return "a random looking useless string representation", it returns a "string representation"If it returns "string representation" without any other rules or constraints on what this string should be, it might as well return something random.
with the default one being "something that looks like Class@memory address".
Which solves the self-created problem of "classes which shouldn't have toString() implementation don't have toString() implementation required by root of typesystem", but creates another problem of "classes have instance-unique immutable toString() by default, and some libraries started relying on that".
It doesn't have to stay that way, and if you're using it for anything, it should be overridden by something useful.
Overloading methods with new meanings is bad design. Different meaning - different method.
Contrary to what you said, it's actually good OO design: a method that's guaranteed to be there
But it's not guaranteed to do anything useful. Also, you can't differentiate types with useful toString() from types with useless toString(). Moreover, you can't differentiate between various kinds of useful toString() behaviors (serialization, user representation, identifier, whatever other string conversions people come up with).
that can be left alone if you don't need it
And you're left with a useless method in your class's public interface. Great design 5/5.
or overridden with something useful (StringBuffer.toString).
Or, you know, I could make new method. One that cannot be confused for anything else.
@Gąska said in The Official Status Thread:
You don't. toString() isn't designed to be user-facing string representation.
It's designed to be any string representation.
Exactly. Because it can be anything, you don't know what it actually is, which makes it useless for any purpose where you actually need to know what the string means. It's like declaring every variable as
Object
type - sure, you can do it, sure, you can assign any object to it and it works, but you can't call any of its methods.If you want to make it something user-facing for convenience (e.g. Customer.toString returns their name), you can do so, or you can use something different (Customer.fullName()).
The problem isn't that I can't do that. The problem is that I can't know what the author did, and can't rely on it behaving consistently across different objects. There's literally zero benefit of there being
toString
inObject
class.@Gąska said in The Official Status Thread:
For example, they might assume two different data object always return different strings, and base their core logic off that assumption. Another library might assume the string representation doesn't change for the entire lifetime of the object (which is true statement for most classes).
Without .toString, libraries with brain-dead idiot design would still find other ways to be brain-dead.
But they'd have one way less to do it. The problem isn't that
toString
does something bad. It's that it doesn't do anything good, so there's no reason for it to exist at all.
-
@stillwater said in The Official Status Thread:
@hungrier said in The Official Status Thread:
@Gąska It's useful for debugging. If you implement your own descriptive .toString, great, but if not, it's a decent way for the language to give some unique* string representation of any object.
<Object 0527283682XBQ> is not of much help :/. Maybe I'm doing this whole OOP thing wrong.
You can use it to correlate which debug prints are about the same object.
-
@stillwater said in The Official Status Thread:
Wouldn't hashcode solve the same problem?
The default
toString()
just takes the object's class name and concatenates it with@
and the hashcode, which in turn defaults to the result ofSystem.identityHashCode()
(and is the address of the object, but you're supposed to not “know” that).
-
This downvote above bothers me more than it should. Maybe I'd feel better if at least I knew what I've got it for.
-
@Gąska FWIW it wasn't me
-
@Cursorkeys said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Cursorkeys Arrays.toString
Thanks, that's what I'm using now. The situation is still retarded though.
Welcome to Java.
-
@pie_flavor said in The Official Status Thread:
@Cursorkeys said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Cursorkeys Arrays.toString
Thanks, that's what I'm using now. The situation is still retarded though.
Welcome to
JavaIT.FTFY
-
@hungrier said in The Official Status Thread:
But that's not what it is. toString doesn't return "a random looking useless string representation", it returns a "string representation",
It's allowed to return "Steve" for any object, provided that object is formally or informally known as Steve.
-
@anonymous234 or contains something that might be called Steve, directly or indirectly.
-
@anonymous234 said in The Official Status Thread:
@hungrier said in The Official Status Thread:
But that's not what it is. toString doesn't return "a random looking useless string representation", it returns a "string representation",
It's allowed to return "Steve" for any object, provided that object is formally or informally known as Steve.
The variable formerly known as
A coding-style so dirty only Prince would sing about?